Wolfie

Okay so I downloaded the community package earlier and uploaded all the files (minus the conf global and Credits.txt files) and still having the issue. I deleted all cookies in use on my site, cleared the browser's cache, hard refresh, signed back in (dealing with the annoying two factor, but better safe than sorry in regards to that) and still not working. Tried it in another browser that I had never used on my site before and experiencing the issue there too.

Easier said than done.

It's the lowest cost alternative I could find to what I'm using now. My current host upped the price on me so I need to switch, and I looked at many options.

You mean the patch from Saturday morning? I already got that one. The ACP doesn't show any new available updates/patches.

If you're willing to edit your hosts file, I can give you the details to look at it directly. I went ahead and upgraded my live site, but the other upgrade that I was doing (and will be moving my site to) is still there for the moment, just not easily accessible without knowing the correct information (DNS records aren't pointing to it).

Theme seems to be permanently stuck on "Auto." When I try to change it to Dark, nothing happens. Anyone else having this issue?

I just had an issue where clicking the button to download the file wouldn't do anything. But once I added "&do=htaccess" to the URL bar, it worked. Using the 4-Slurpee version (4.7.11).

In my experience, the IPS staff tend to be very aware of the importance of quality and stability. But they are still human and will sometimes make a mistake despite their best efforts. It's something I keep in mind when I encounter an issue, as most issues tend to be minor and easy to fix. Most issues aren't big enough to warrant a rapid response, such as minor bugs that can wait until the next update. Then there are some that are more critical and a rapid response is needed. Look at the patch that was released in response to this issue. While it seems to not fix it for everyone, an effort was quickly and on the weekend. This is an example of trying to get something out to try to fix the issue ASAP, vs spending a day or two testing it to make sure it works. I prefer this when feasible as the sooner IPS gets feedback on it, the sooner they can work on it again if necessary. Be glad that the IPS team actually listens to its clients. There are some products where the company barely interacts with the community, much less pays much attention to feedback and issues (unless they are critical issues).

If you're so good, you should have known and offered to help. 🤪

The problem is that some hosting companies set the default to MyISAM and there's no way to select InnoDB as preferred, thus the suggestion. That way if it's supported but not default, it can still be chosen. Of course there could be a situation where someone would prefer to use MyISAM (not sure why) and this would allow that. I don't know the technical aspects between the two, only that InnoDB is supposed to be faster and more efficient. The fact that IPS recommends it is another reason I prefer it. They know what works best for the software, so I'll try to follow that when possible. Of course, an alternative is to add in an optional constant for preferring InnoDB when available, so it will do the above, but specifically look for InnoDB vs a user chosen engine.

I'm thinking something like this, though I'm sure one of the devs can tweak it to be cleaner/better. System\Db\Db.php public function defaultEngine() { $default = ""; $result = $this->forceQuery( "SHOW ENGINES" ); while( $engine = $result->fetch_assoc() ) { if( mb_strtoupper( $engine['Support'] ) == 'YES' and isset( $INFO ) and $engine['Engine'] == mb_strtoupper( $INFO['sql_engine'] ) ) { return $engine['Engine']; } if( mb_strtoupper( $engine['Support'] ) == 'DEFAULT' ) { $default = $engine['Engine']; } } return $default != "" ? $default : ( $this->_innoDbSupportsFulltextIndexes() ? 'InnoDB' : 'MyISAM' ); }

Why didn't you tell me this before I decided to quietly upgrade? 😁

During my upgrade from 3.4.6 to 4.7.11 (Slurpee time), I experienced a few issues. I encountered this same issue that @teraßyte provided a fix for. So when an array is expected, a similar thing should be done (when acceptable) so that if there isn't an array, one can be made. If an array is required, as in there has to be some sort of data for the process to continue properly, then obviously an error should happen but should be a friendly error that explains the problem enough to know that a workaround isn't a recommended solution. I also encountered situations where a table or row was expected but missing. Somewhere in the upgrade process, the tables/columns were assumed to have been created, which may be the case when upgrading from a more recent version but not from an older version. I think instead of checking for them, there is perhaps a version in the upgrade process that is skipping the part of adding the expected tables/columns when that version of the install adds them.

Seeing an error during the upgrade process can be frustrating enough. But not knowing what part of the process the upgrade is at makes it even more so. Therefore, when an error happens, the app and upgrade file in use when the error happened should be shown. Not only provides more information to the administrator performing the upgrade, but it's more information that can be provided when they are seeking assistance.

Current host has InnoDB as the default engine which is great. However, I'm looking to switch to a different hosting company and their default is MyISAM, which causes issues. I see in the code that the supported engines are checked and the "default" one is chosen as the default to be used. However, the administrator of the community should be able to specify the preferred engine that gets used (if it's supported, of course). If it's not supported, then go with the server's default engine. $INFO['sql_engine'] = (MyISAM or InnoDB).

Here's a couple of questions for everyone having the problem. It's probably nothing, but the best way to eliminate possibilities is to consider them. Who here has their community at https and who has it at http? (secure vs non-secure) Also, who is using (or not using) Cloudflare or some other proxy service? I was having the same issue (finally managed to get the upgrade to go through) and noticed that Chrome was saying the site wasn't secure. I looked at my conf file, changed it to be https and suddenly the issue went away. My site is also proxied via Cloudflare.

Error: Class "IPS\cms\Records1" not found (0) #0 /home/***/applications/core/sources/Setup/Upgrade.php(594): IPS\cms\setup\upg_104030\_Upgrade->step1() #1 /home/***/applications/core/sources/Setup/Upgrade.php(326): IPS\core\Setup\_Upgrade->step1() #2 /home/***/applications/core/modules/setup/upgrade/upgrade.php(47): IPS\core\Setup\_Upgrade->process() #3 /home/***/system/Helpers/MultipleRedirect/MultipleRedirect.php(93): IPS\core\modules\setup\upgrade\_upgrade->IPS\core\modules\setup\upgrade\{closure}() #4 /home/***/applications/core/modules/setup/upgrade/upgrade.php(32): IPS\Helpers\_MultipleRedirect->__construct() #5 /home/***/system/Dispatcher/Controller.php(118): IPS\core\modules\setup\upgrade\_upgrade->manage() #6 /home/***/system/Dispatcher/Setup.php(220): IPS\Dispatcher\_Controller->execute() #7 /home/***/admin/upgrade/index.php(34): IPS\Dispatcher\_Setup->run() #8 {main} Couldn't afford to do it sooner. Also, push come to shove, I can just ask you all to do it. 😉

Found this little fix... Now a 1054. Did retry and now...

Okay so I did an export of the table from a different test install (not an upgrade, just an install) and used that. Now have an EX0...

So looking at the list of tables from a couple of different backups, the table 'cms_page_widget_areas' doesn't exist and (from what I can see), didn't exist by or before v3.4.8. So there's a bug right there. So what should I do, dig up the schema for it and create the table myself?

You should never assume, even though you were right this time. 😁 I hope I don't have to do this again. That first screen gets annoying since I flip some of the options (convert friends to followers, bbCode, etc). I had actually edited some of the options files to default them to what I want from restarting the whole process over and over again. lol

The default engine is set to MyISAM and I've asked my provider to change it to InnoDB. What I've been doing is running a query to generate new queries that will do a search-and-destroy list of tables that are either MyISAM or not Dynamic, with the new queries altering those tables to be InnoDB/Dynamic. Had to run that a few times to get new queries in order to fix the issue. Now a new issue...

Okay, tables are InnoDB and all rows are dynamic. Getting this error now.

Thanks dude. I tried doing searches before but didn't find anything. Okay, so is there a query to run that will convert to dynamic or is that a hosting company thing? I also see "MyISAM" mentioned as a culprit, so will converting to InnoDB fix it?

Initially it was throwing me in a loop where it would tell me that some tables needed to be converted to UTF-8, only for the next screen to tell me that everything is fine and I can continue (and then repeat). I used the CLI convert process and after replacing the old tables with the converted ones, now this... Clicking "Retry?" or "Continue" presents me with the same thing. (Upgrading to 4.7.10) This might be a trial upgrade (if there are too many issues to fix first), or it might go live. I'll decide after I've managed to complete the process and see what the results are. But until then, need help on getting past this point.