4.6 upgrade compatible?

MattD · 2016-09-13 03:44:10

Trying to upgrade but I get a white page after logging into the admin side, initially I got a 500 but seemed to be permissions related.

PHP version: 5.5.36
GD Graphics Library: bundled (2.1.0 compatible); supported formats: GIF, JPG, PNG.
MySQL: 5.5.51-MariaDB

Bloke · 2016-09-13 08:25:31

Odd. Anything in your Apache/PHP logs that might give us a clue what’s falling over?

gaekwad · 2016-09-13 10:21:36

I’ve had a 500 blank screen on a client site, turned out to be overloaded shared hosting and a refresh fixed it.

Bloke · 2016-09-13 12:23:12

gaekwad wrote #301405:

I’ve had a 500 blank screen on a client site, turned out to be overloaded shared hosting and a refresh fixed it.

That’ll be all the people scrambling to update Txp at the same time ;-)

MattD · 2016-09-13 13:45:02

[Tue Sep 13 09:43:41 2016] [error] [client removedip] PHP Fatal error: Call to a member function start() on a non-object in /home/removed/public_html/textpattern/lib/txplib_db.php on line 395, referer: http://mysite.com/textpattern/index.php?logout=1

gaekwad · 2016-09-13 13:48:26

MattD wrote #301412:

[Tue Sep 13 09:43:41 2016] [error] [client removedip] PHP Fatal error: Call to a member function start() on a non-object in /home/removed/public_html/textpattern/lib/txplib_db.php on line 395, referer: http://mysite.com/textpattern/index.php?logout=1

I think that’s plugin-related. Try disabling plugins.

Edit: yep, more info here forum.textpattern.com/viewtopic.php?id=46987

Last edited by gaekwad (2016-09-13 13:49:20)

Bloke · 2016-09-13 13:51:56

MattD wrote #301412:

Call to a member function start() on a non-object txplib_db.php on line 395, referer: http://mysite.com/textpattern/index.php?logout=1

Okay, thanks. So it’s a trace (debug) issue. To get you going, toggle your production status to live prior to upgrade, or do it via phpMyAdmin in the txp_prefs table and log in.

Edit: Pete’s/Oleg’s suggestion is equally valid, and perhaps better.

Last edited by Bloke (2016-09-13 13:53:18)

MattD · 2016-09-13 14:01:20

After switching to live via phpMyAdmin I see the following errors/warnings on the admin side:

Warning "unlink(/home/removed/public_html/textpattern/include/import/BloggerImportTemplate.txt): No such file or directory"
in /home/removed/public_html/textpattern/update/_to_4.6.0.php at line 151.

textpattern/lib/txplib_misc.php:1676 adminErrorHandler()
updateErrorHandler()
textpattern/update/_to_4.6.0.php:151 unlink()
textpattern/update/_update.php:84 include()
textpattern/index.php:180 include()

I have nothing in /home/removed/public_html/textpattern/include/import/

Last edited by MattD (2016-09-13 14:04:00)

Bloke · 2016-09-13 14:05:02

MattD wrote #301415:

Warning "unlink(/home/mattsdav/public_html/textpattern/include/import/BloggerImportTemplate.txt): No such file or directory"...

Dammit, you too

etc · 2016-09-13 14:16:52

Another plugin-related dammit in perspective.

MattD · 2016-09-13 14:27:28

Bloke wrote #301416:

Dammit, you too

I deleted /home/removed/public_html/textpattern/include/import/ but still get the same errors on the admin side. It won’t let me move past the update language page.

EDIT : I had to also delete txp_import.php. Then it let’s me pass and all looks well so far.

Last edited by MattD (2016-09-13 14:30:42)

maverick · 2016-09-13 14:38:18

Thinking about plugins . . .

As far as I recall, we have never officially asked plugins to be disabled prior to upgrading, though unofficially it has been recommended a number of times – either pre-upgrade or post upgrade when there are problems.

While it is an inconvenience (minor if you use wet_plugout) perhaps doing so would make upgrading more bullet proof?

Upgrades are a way of life in software – if nothing else, for security upgrades.

Perhaps the install script could throw up a upgrade in progress page, turn off all plugins prior to the install. Then an all off/on toggle could be added to the plugin admin panel to make it quick and painless to turn things back on, and if there are problems, it becomes a quick way to focus in on the plugins. . .

Bloke · 2016-09-13 15:16:10

maverick wrote #301420:

As far as I recall, we have never officially asked plugins to be disabled prior to upgrading… perhaps doing so would make upgrading more bullet proof? Perhaps the install script could … turn off all plugins prior to the install.

Interesting. Plugins aren’t loaded until after the update runs, but you’re right that no sanity check is performed to see if they’re going to bork the admin side. Turning them off seems a bit drastic, and difficult in plugin_cache environments (permissions issues, for starters).

But we know that an update is in progress so there’s nothing to stop us going through each installed plugin and just running it to see if it causes an error, and if it does, disable it (or in the case of plugin_cache plugins, try to rename its extension so it won’t run). It won’t necessarily catch any errors that might occur when you go and visit that plugin’s panel, but it’ll at least get you to an admin-side that works.

Will investigate and see if that’s possible at some point. Might be too tough, but I’m up for the challenge.

maverick · 2016-09-13 16:47:34

Bloke wrote #301421:

Might be too tough, but I’m up for the challenge.

I have not doubt of that! Though I didn’t mean to push you into a major project :D

I was more thinking aloud: that if one of the main sources for support requests in the upgrade process is from plugins breaking things, then maybe momentarily turning them off when you first log in following the upgrade might be a quick and easy way to know all was well with the core installation.

But something more sophisticate, and less drastic would likely be better received.

Bloke · 2016-09-13 17:04:46

Sure, anything’s better than breaking!

Alternatively, when it comes time to load_plugins(), we could detect if an upgrade has just been performed and simply not load them that first time. That would have the benefit of at least meaning you’d get a functional admin side…. initially at least.

The downside is that if you have an incompatible plugin in your arsenal, your next click to another tab or to update languages, is likely to give you the error and a broken admin side. So it’s not a fix, but does defer the issue for one click, which at least gives you the chance to then figure out that the upgrade was fine but a plugin might be the cause of your woes.

I’m not convinced that’s much better than simply dying on upgrade. I’d rather it didn’t die at all!

One other, related, thing that’s always bugged me about our upgrade process is that it just dumps you on the Languages panel. No notification. No thanks. No “that went well”. Nada.

I’d like to display a one-off dashboard of some sort, detailing what happened: even landing on the Diagnostics panel with some info at the top about the success of the upgrade would be more handy. That would then be an ideal place to test each plugin (if we can, using a try... catch block or something) and list any that are immediately going to break things, disabling them automatically if possible. As far as I can tell, the languages are always updated anyway by the upgrade script, so the practice of landing on the Languages panel seems of little value any more. But maybe I’ve missed some nuance of the upgrade process that might require a manual update of lang strings.

Perhaps some better feedback is something we can strive towards. It won’t help us today to get a less-annoying 4.6.1 out the door fairly soon, but it’ll help everyone in the long run.

Textpattern CMS

Textpattern CMS support forum

#1 2016-09-13 03:44:10