Invision Community 4: SEO, prepare for v5 and dormant account notifications By Matt Monday at 02:04 PM
Midnight Modding Posted September 28, 2018 Author Posted September 28, 2018 58 minutes ago, Adriano Faria said: Go to Dev Center -> Versions and you will see everything there. Every column or table change will be there. I clean them all in my apps. I can't. This exception is everywhere on the site. front end and admin end. I'd have to go through the trace of files and figure out where to prevent whatever check is triggering it updating things and edit their file (I assume catching this exception isn't good enough either). I already looked through versions.json at the column changes. Like I said, this is all related to a rename of a table, but the table is already renamed, and it happens due to developer sync, ie it's due to checks from in_dev. So, again, I am not running an upgrader. This just happens from browsing the site when in_dev is set to true. The user is going to backup his db and try the fresh install on his test site, though, since this should be totally unrelated to a fresh install on a non-in_dev site. But I obviously would like to figure this out, regardless, where I prevent it next time and be sure I haven't messed up in my order of actions in building the app's tar file, like maybe skipped some step or something.
Midnight Modding Posted September 28, 2018 Author Posted September 28, 2018 when I set in_dev to false, not only does the site work, but my app even seems to be fine. I thought I had to install it and it wouldn't work with in dev off? Did it get auto installed when I did the download and build app part? This is so puzzling. Could it be related to me selecting "build new version" from the form (remember, it's the download form, not the rebuild app form)?
Midnight Modding Posted September 29, 2018 Author Posted September 29, 2018 Great. Now a problem is my tar file is over 2mb, so sites that keep the max upload size at 2 mb wouldn't be able to install it in the acp. Surely some of IPS's apps' files are greater than 2MB, too. Do they just tell people either raise the limit or upload files manually? I should include both the tar and the files with the full folders/path also for manual uploading? Also, just realized in cpanel even though my php version is set to 7.0, it's only for the root directory! Anything below that directory it says 5.6 So cpanel makes you have to set the php version for each folder separately for hundreds of folders???
Midnight Modding Posted September 29, 2018 Author Posted September 29, 2018 Also, apparently there are no rebuild tools of any sort when not in dev... and I thought it uses Application.php on the fly, but it must only use it at the time of installing, because it's ignoring my rootTabs and never did anything with it at all. Is my site in some sort of limbo between installed app and dev app? And there's no rebuild tools of any sort when not in dev??? I realize this is a lot of posts, but this is a lot left to the person making the app to figure out the procedure on and as far as I can tell I did everything as is supposed to be done and now am stuck with this exception.
Midnight Modding Posted September 29, 2018 Author Posted September 29, 2018 I just went ahead and did what I said several times I assumed I should do... backed up my files and db, uninstalled the app, re-installed, everything is fixed now. It's a bug, in my opinion, though, because clicking the upload button should obviously not lead to an exception all over your site until you uninstall and re-install the app. Either way, I am still impressed with the system for creating apps, though. Now I guess my only question is related to the whole tar file over 2mb question, since some sites won't have ability to raise their php upload limit. Seems to me I should release apps with both the tar file and loose files for uploading manually, but that is still not perfect and I don't see how this issue hasn't come up for others. Or I could include only the tar file and instructions saying go to applications, create the app directory, then upload files. But this is all not great to be having members have to do.
bfarber Posted October 1, 2018 Posted October 1, 2018 With whatever route you added your content to your app, the dev syncing tool thought it needed to catch your app up, hence the attempted table renames. The easiest solution would have likely been to just edit the record in core_dev for your app to reset the version ID and last sync timestamp.
Midnight Modding Posted October 1, 2018 Author Posted October 1, 2018 1 hour ago, bfarber said: With whatever route you added your content to your app, the dev syncing tool thought it needed to catch your app up, hence the attempted table renames. The easiest solution would have likely been to just edit the record in core_dev for your app to resetThanks. if it happens again, I will know to do it that way. the version ID and last sync timestamp. Thanks. If it happens again, I will know to do it that way. I personally feel there's a bug somewhere, but I figured it would be too hard for someone to reproduce. I had always done the changes on the same pc, install, and in schema.
Midnight Modding Posted October 3, 2018 Author Posted October 3, 2018 On 9/28/2018 at 5:06 AM, Adriano Faria said: Welcome to the most boring step of your app. Maybe someone else has a more appropriate way to do this but that’s what I’ve done in upgrade for two resources I own: - TO MAKE THE UPGRADE ROUTINE: In the version you want to upgrade, add the upgrade.php and use one step for each table or conversion you need to do in upgrade.php. You will have to make a foreach select in your categories table, convert title and description to lang bits, etc. More: https://invisioncommunity.com/developers/docs/development/applications/versions-and-upgrading-your-application-r51/ - TO TEST THE UPGRADE ROUTINE: You have to uninstall the app and move the app folder from applications folder to your desktop, for example. Otherwise it will appear in apps not installed. Insert, via PHPMyAdmin, the entries in core_applications and permissions_index tables from your app/categories. Rebuild cache. Then it will appear as Outdated app. Above are general lines of how I did. You better take a look first in Forums app, for example. you're saying I add my upgrade folders and files in setup/ right? Or is there a separate place to put them when in dev and it creates that folder?
Adriano Faria Posted October 4, 2018 Posted October 4, 2018 You DO NOT add yourself. It creates automatically when you start the app/add a version.
Midnight Modding Posted October 4, 2018 Author Posted October 4, 2018 52 minutes ago, Adriano Faria said: You DO NOT add yourself. It creates automatically when you start the app/add a version. But I thought you said we edit an actual file, rather than the dev center way of doing it. In other words, I know there is a create upgrade.php button in acp, but doesn't it then create a physical file, rather than us doing the code in acp? If so, would it be creating a setup folder? For all IPS apps' dev folders in the dev files it has no upgrade.php.
Adriano Faria Posted October 4, 2018 Posted October 4, 2018 "Sometimes" you edit some .json to fix something here or there. They are created by Dev Center.
Midnight Modding Posted October 4, 2018 Author Posted October 4, 2018 1 minute ago, Adriano Faria said: "Sometimes" you edit some .json to fix something here or there. They are created by Dev Center. I edited the post some while you typed. But, anyway, I am sure once I start doing this, I will figure it out. Was just asking, just in case I do run into an issue, but probably will be simple. Looks like if I want to change the human version name/number I'll have to edit the file for that, as there is no edit button in acp. (wanted to change to like RC or something, not change the actual value, just human part)
Midnight Modding Posted October 10, 2018 Author Posted October 10, 2018 Eh, did IPS either originally import some tables into 4.x without coulumns that would have still been there on 3.x installs at that time? (or maybe they edited the schema file directly to remove them)? Reason I say this.... in the 4.x forums upgrade.php, they use dropColumn(), which I assume would mess up the schema if not for a workaround by not having those columns ever show up in schema to begin with. ps I have literally an hour or less of work before this app is finally 100% done, bug fixed, etc... I have done 5 steps and will have 1-3 more, depending on how I plan to handle something.
Midnight Modding Posted October 11, 2018 Author Posted October 11, 2018 In case I wasn't clear on that last post, what I am saying is if IPS imported the forums tables normally in 4.x, in their final 3.x state, then using dropColumn() in upgrade.php, which they did do, would leave the db schema still having those columns listed, since you must drop them in dev center to have it update the schema. So the only thing I can think of is IPS would have either had to edit schema.json and take those columns out manually or they imported the tables after they already manually took the columns out. More curious than anything else, because I am probably just going to do a new version for all of my drops, personally.
bfarber Posted October 11, 2018 Posted October 11, 2018 A lot of the original 4.x upgrade routines we had to rework manually. We likely used the developer center to adjust the schema as appropriate, but then later moved some of the adjustments to upgrade.php files to ensure things were worked in the order they needed to be worked in. 3.x to 4.x was a pretty big schema adjustment so we had manual work involved with the upgrade routines, yes.
Midnight Modding Posted October 11, 2018 Author Posted October 11, 2018 2 hours ago, bfarber said: A lot of the original 4.x upgrade routines we had to rework manually. We likely used the developer center to adjust the schema as appropriate, but then later moved some of the adjustments to upgrade.php files to ensure things were worked in the order they needed to be worked in. 3.x to 4.x was a pretty big schema adjustment so we had manual work involved with the upgrade routines, yes. ok thanks. I could get it to work either way, but I'm just going to use dropColumn() in the file for members table columns I am moving to my own table, as that won't affect the schema anyway, and then everything else I am going to simply build another version and drop via dev center. I did a bit of this awkwardly because of doing the upgrade.php stuff last, and had already renamed a lot of columns and tables, so to keep everything straight, I had to do upgrade.php stuff in a second version and just not have anyone ever use the actual first one on its own. It's still going to work all fine, though.
Midnight Modding Posted October 11, 2018 Author Posted October 11, 2018 One more thing... I am confused on version numbering and what needs to be included because for some reason core's versions file starts with 3.0.0, so why is nothing pre-3.0.0 in it? And forums doesn't have anything before 4.0, although maybe its updates are done in the core one? I got confused on that and think I messed up in numbering my version, too. In the past I always numbered versions with 5 digits. I then noticed the 4000 version number in forums and named this with 4 digits, but that is surely wrong for my case as it would be a lower number than the 5 digit ones. I also see IPS names some versions with 6 digits, some with 4, some with 5... Since I am going to have to uninstall and re-install on my test site, anyway, due to how I set up the upgrader, I might as well change it to 5 or 6 digits, right in the file.
bfarber Posted October 12, 2018 Posted October 12, 2018 I don't think we have any version numbers (the long number) with 4 digits. They are all 5 or 6. You cannot upgrade to 4.0 from a pre-3.0 version. If you are running a version less than 3.0 you must first use a copy of any 3.x version to upgrade, and then you can upgrade to 4 from there. This is why you don't see any version information from before 3.0 in the json files - it's not needed because this version won't use or understand it. When we originally released 4.0 we used 40000 and started handling all apps separately. Before this point, core+forums were always handled together in a single upgrade process and we did not change that when updating the code for 4.0 (we just changed our processes moving forward). We ran into some version oddities because Gallery was already on "version 5" when we released the 4.0 Suite, so we bumped up our version numbers to 6 digits to reset them and ensure everything worked in the right order. You're overthinking it though and worrying too much about insignificant details. The long version number is what the software looks at, and the biggest one is the most recent version. You then also supply a human version number which can be anything you want. It doesn't have to be any specific number of digits.
Midnight Modding Posted October 12, 2018 Author Posted October 12, 2018 ok, thanks. I did mess up, though (which I realized later), so am going to have to change my version number and upgrade folder name. I can either find where the currently installed version is stored in the db and edit that and my files or else will have to uninstall it and edit files. I just flat wasn't thinking when I numbered this version. I just noticed that 5 digit forums one and numbered mine with 4 digits, forgetting all of my past ones would then be higher numbers. lol.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.