Hello all! Is there a way to "reverse program" the control panel based on a manually modified BT_config? I need a way to paste a manually edited BT_config somewhere and have the app in the control panel to modify itself according to the edited JSON content in the new BT_config. I have a situation created by the bug where "currentMode = Live" is not honored, and the app was published in the Apple app store but yet registering as though it's in Design mode. This is further complicated by the fact that I was doing image filenames in a way that is not acceptable to Android, and I really need (due to client handoff) to have both the iOS and Android versions of the app to be driven by the same app in my self-hosted control panel. So I needed to create a new version of the app, using all new, corrected image names, and hardcoding "currentMode = Live" to get around the bug, all without making existing app users suddenly lose all their icons because of changing the image names in the control panel to new names that did not match the images compiled into their original version of the app. I have created that newer version, but now I need to have it go live in the Apple app store, and as soon as possible after that, have the control panel version of the app changed to match the sweeping changes in that newer version (all images names edited). This is a bit of a "hairy" process. My scheme thus far will work, I think, so long as I can get users to update to the newer version of the app. One issue I still face is that changing even a single one of the filenames in the control panel will trigger an update to all the installs that are registered in Design mode. I'd like to get all those sweeping changes made quickly rather than piecemeal. Plus, if I can update the control panel based on the new, manually-edited BT_Config, then it will save me quite a bit of work. Anyone know of a way?

Well, Chris1 has an app creator that would allow you to import an app using a BT_config.txt, as long as the json is valid, it wouldn't matter 'where' it came from. https://www.buzztouch.com/plugins/plugin.php?pid=93D709C2D88A587EEBC4A5C only self hosted works. Hope this might help. Cheers! -- Smug

Couple of ideas, none of them quite pleasant if you haven't done that kind of thing before. 1) You can dive into the database on your BT server and change everything manually. Extremely dangerous, backup the database before even starting to look at it. 2) You can use the dataURL field in your menu screens to read php files. The PHP files need to create the JSON the screens expect, together with all other parameters. Not exactly elegant, but works and most of my apps are using that facility in one way or another. In an extreme case, I have a couple of apps that read even the main menu from a remote PHP file. This is possible to do once you get the first PHP file going. A bonus is that using PHP files to generate screens has nothing to do with Design or Live settings, but you do need your users to refresh the app so that the dataURLs are read in again. 3) >need (due to client handoff) to have both the iOS and Android versions of the app to be driven by the same app in my self-hosted control panel This may be more difficult than it seems at first glance. Recently, working for a client, I had the following situation: on the Android side, he put external links from his app to his site, where he is selling digital copies of his books. Apple did not allow that, so I added a small squeeze page for users to leave email address if interested to learn more. The app was finally approved by Apple after three months of submitting and resubmitting. The app is seemingly generated from the same BT source, but internally, I had to rewrite several plugins. This may be an option for you, if you can code, obviously. 4) > all without making existing app users suddenly lose all their icons because of changing the image names in the control panel to new names that did not match the images compiled into their original version of the app. This may not be such a problem. In most plugins you will be able to switch from reading local images to downloading remote image files, they will be downloaded once and then cached and that is something your users can leave with. There you go, a couple of ideas to stretch you out and get out of an unpleasant situation.

Are we sure that the BT_Config file is read and then populates the control panel? Because my understanding is that the config file is created by the setting in the control panel, and I'm not sure code exists to do the reverse. Will be watching this thread to see how it plays out! For sure, this can't be done at BT.com...a solution would only work for self-hosted. Mark

@Smug That's an idea: to use the App Copier plugin. I already have and had used the plugin. Couple thoughts and one important question: The plugin creates a new app, with (as I understand it) its own unique IDs and so forth. What crucial IDs numbers from the old app would need replaced in the new app, to make it correspond to the installs out there that were based on the old app? And can you steer me to where in the self-hosted database to find the field(s) (i.e. what table) to replace those IDs? I can find my way around a database pretty well, but if it is super complex help may be needful. The plugin does not copy everything. It leaves out some core details and details such as theme. I think the assumption is those things would need attention on a new app, therefore they are not copied. But it still might be less work to revisit those areas than to have to rework all those image names. Probably is less work. Thanks for the idea!

@Dusko Thanks! Re: 3) >need (due to client handoff) to have both the iOS and Android versions of the app to be driven by the same app in my self-hosted control panel "This may be more difficult than it seems at first glance. Recently, working for a client, I had the following situation: on the Android side, he put external links from his app to his site, where he is selling digital copies of his books. Apple did not allow that, so I added a small squeeze page for users to leave email address if interested to learn more. The app was finally approved by Apple after three months of submitting and resubmitting." Thanks for the heads up! My first app (which was for our church) was approved, even though it has an icon that points to an online store on our website, that sells digital product (in this case MP3s), so I don't know if they granted us a leniency or if the type of product affects the situation. However, since the iOS approval hurdle is already past, I think we are OK on this. Re: 4) > all without making existing app users suddenly lose all their icons because of changing the image names in the control panel to new names that did not match the images compiled into their original version of the app. "This may not be such a problem. In most plugins you will be able to switch from reading local images to downloading remote image files, they will be downloaded once and then cached and that is something your users can leave with." This is an idea worth consideration! With some extra work I can make it so the user never gets without icons. If I am reading you right, phase 1 with remote URL for images (for the original app), then phase 2 with compiled images again (for the revised app)... am I following you right? Thanks again.

@Mark (GoNorthWest) Thanks! Are you referring to Smug's post? In that case it does read a config file to create a new app, which is technically the reverse of what normally happens, although it does not copy everything. Some elements get left out. However, this conversation has gotten me to thinking about the possibility of creating a different version of the App Copier plugin that: 1. Would allow one to paste in the BT_config file instead of a data URL. 2. Would copy everything, down to the app ID number, etc. For its "safety" features to be robust, it could look to see if there is already an app with the given ID number etc, and offer to either overwrite or change to a new ID number, thus either updating an existing app or creating a new one. Have never looked at the code of the app copier plugin, but wheels are turning. Still, in the end I only need to do this process twice (once for two clients), so it may not be worth going to that length. Thank you for spurring thought!

I'm not sure if it's the 'best' solution, but here is something to chew on. 1) Create a location on your self hosted server. for instance 'www.yourserver.com/myappspot' 2) In the 'myappspot' directory, provide your 'custom' BT_config.txt file that has what you want. 3) use this as the 'Configuration Data URL' for the app in distribution. 4) Make your changes, do your thing, try something new. And when you're finished, update (manually) the BT_config.txt file at 'myappspot'. Effectively what we're doing is pulling 'updates' away from the BT Self Hosted server, and putting in a 'file location'. Now you just need to update the file as needed. Make sense? Does that work? Granted, it may not work for a project currently released in the wild, but for any updates, or any new releases, it may be an alternative. Cheers! -- Smug

@Sumg Yes, that is a very doable solution. Thank you!

Just some thoughts on Chris' app copier. And not actually owning a copy, what I'm really doing is listing out a few thoughts on how BT works, with respect to the apps, old, new, and otherwise. 1) When you create a new app, the BT infrastructure creates an 'appId' that is unique. You cannot duplicate an app, and keep the same appId. Things would get confusing really really fast. 2) When you 'add' a new plugin to your control panel (not your app, but to your 'system'). It creates a plugin itemId. This is also unique. You have the BT_screen_map, I have the BT_screen_map. But in my self hosted system, the itemId is different than your itemId in your system. Because they are created when they are added. You cannot have two of the same plugin. And if I gave you a copy of my BT_config.txt for an app, it wouldn't work for you (without modification) because even if we have the same components, the reference ids are different. 3) When you create an app, each 'component' (be it a screen, an action, a splash, a menu, whatever...) is given an unique itemId. This ID is unique to the app, and will not reflect the same guid as the source it came from. If you have 4 'htmlDoc' plugins in your app, each will have a different itemId, so that each can have a different configuration. You cannot (and should not) duplicate any itemIds at this level (or any level, really) So what's happening here, is that each 'piece of the puzzle' is given a unique identifier (itemId, guid, AppGuid, etc...) to differentiate it from another similar object. And each app is just a MySQL table of ids, that pulls from other tables of ids, that are all connected by the ids... it's a little convoluted, and looks like a spider web if you tried to draw it all out. You sort of have to imagine a huge 'cascade' of ids, to see how they all tie together. But it works, and it works well. I'm not sure if I have a point to make here, lol! I guess what I'm thinking is, the more you understand how the system works, the better decisions you can make regarding the creation and ongoing maintenance of the app. Not sure if this actually 'helps' anything, but hoping it explains a little bit of the BT backend. If you get bored sometime, login to your hosting providers 'phpMyAdmin' or whatever you use to administrate your MySQL databases, and snoop (without saving anything) your BT database. It's actually kind of interesting to see how David organized everything. It doesn't make a lot of sense at first, but when it does, it's pretty neat. Cheers! -- Smug

I realise I've arrived a bit late to the party, but i just wanted to throw in my 4 pennth. If I have understood you correctly, this is more of a logic problem than a technology issue. You have version A of your app released and you have already put inthe effort and built a completely independent new release of your app (I think) - call it version B, which includes all your corrections. Pesumably all the renamed images sit in the builds. If you release version B to the app store, your Control panel for Version B manages that. Version A users will be invited to take the new release. You will have an audience looking at both A and B for a while, but most will transition quickly from A to B. Keep the control panel for version A going for a week or two, then, kill it off or just stop updating it. I've done this myself, it worked for me, would that work for you? Or have I missed something? Alan

@Smug Thanks! Very helpful info. @Alan You got most of it, except, and I may not have explained it well, but my self-hosted app control panel has only one instance of the app, and on my hard drive for iOS development, I have two copies of the app: the old with uncorrected image names, and the new with corrected image names. So, there would need to come a moment when the control panel switches from controlling the old and to controlling the new. Thanks for taking time to notice the situation!

Well, here is another bit of lateral thinking. Put your old images and new images into the revised build. Submit that, so the control panel still works for the old build, then you can change the names of the images from your control panel after the new build gets installed?

@Alan That's a workable idea! Lateral thinking indeed. Thank you!