Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#13 2016-09-13 15:16:10

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: 4.6 upgrade compatible?

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.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#14 2016-09-13 16:47:34

maverick
Member
From: Southeastern Michigan, USA
Registered: 2005-01-14
Posts: 976
Website

Re: 4.6 upgrade compatible?

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.

Offline

#15 2016-09-13 17:04:46

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: 4.6 upgrade compatible?

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.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#16 2016-09-13 18:06:10

colak
Admin
From: Cyprus
Registered: 2004-11-20
Posts: 9,007
Website GitHub Mastodon Twitter

Re: 4.6 upgrade compatible?

There is the consideration that some sites might have a lot of plugins installed but only some, might be active. A reminder of the plugins which are about to be deactivated by the installer should print somewhere on the screen with a possible continue button.


Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.

Offline

#17 2016-09-13 18:15:26

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: 4.6 upgrade compatible?

colak wrote #301424:

A reminder of the plugins which are about to be deactivated by the installer should print somewhere on the screen with a possible continue button.

Yes, though rather than “about to be disabled” I was thinking more “have been disabled”. No option to bypass it. If we permitted the continue button to perform the action, we’d run the risk of people not using it or clicking elsewhere in the header to open a different panel.

I was thinking along the lines of the Firefox upgrade process. “Checking your add-ons for compatibility… oh, sorry, these ones aren’t going to work so we’ve disabled them.”

The Continue button would then carry on to display your default panel.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#18 2016-09-13 18:25:32

hcgtv
Plugin Author
From: Key Largo, Florida
Registered: 2005-11-29
Posts: 2,722
Website

Re: 4.6 upgrade compatible?

Bloke wrote #301423:

Perhaps some better feedback is something we can strive towards.

Wouldn’t it be just admin-side plugins freaking out, not front-of-site plugins?

If so, can’t you detect admin-side plugins and just turn them off? Let the end user get a functioning admin, “Welcome to 4.6.0!”, and then they can start turning on plugins and see if they work, preferably one by one.

Offline

#19 2016-09-13 18:48:10

maverick
Member
From: Southeastern Michigan, USA
Registered: 2005-01-14
Posts: 976
Website

Re: 4.6 upgrade compatible?

hcgtv wrote #301426:

Wouldn’t it be just admin-side plugins freaking out, not front-of-site plugins?

I’m thinking of the “unregistered tag” error, or any plugin that might be trying to access the database using outdated protocols as examples that it could be front or admin side plugins.

It seems you never know what might break things after an upgrade.

Of course the backside is a panic moment, but a broken front side on a heavy use site could have a major issue. Thus my initial suggestion that the front side be automatically put into a maintenance mode pending verification on the administrator’s part that the plugins are working. That way no surprises/embarrassments.

I like Bloke’s idea of checking and automatically disabling only the trouble plugins ala Firefox.

Offline

#20 2016-09-13 19:58:43

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: 4.6 upgrade compatible?

hcgtv wrote #301426:

Wouldn’t it be just admin-side plugins freaking out, not front-of-site plugins?

Yes, they’re the ones we’re most interested in at upgrade time. Easy to tell the difference via the plugin’s type.

If so, can’t you detect admin-side plugins and just turn them off?

Yep. But admin-side plugins may have public tags registered so shutting them off needlessly is going to impact front-side usability. Of course, everyone tests their sites before going live so this should have been caught earlier and planned… uhhh, right?

maverick wrote #301427:

I’m thinking of the “unregistered tag” error

That’s a ‘soft error’ at the moment so I’m not too fussed, as it’s only thrown in testing/debug mode and doesn’t impact front-side functionality (yet). Nor does it affect the back-end so won’t affect upgrades. We’re not going to enforce registration in 4.7. Maybe 4.8 or 4.9, depending on timescales and plugin update rate.

or any plugin that might be trying to access the database using outdated protocols

That is a minor concern, yes. Plugins that use safe_*() calls are fine because the core shields them, but any plugin that uses mysql_*() calls directly (and there are some, because our API wasn’t as fully featured as it is now, so people often resorted to direct calls) and runs under PHP 7 will break the front side. Staging sites first should find these but, again, even if not, it won’t affect the upgrade process.

Of course the backside is a panic moment, but a broken front side on a heavy use site could have a major issue.

Hence we recommend a full backup and checking it over in a test environment first, especially for non-point release upgrades! When the visitor hits a page that uses a tag from a disabled plugin, who knows what’ll happen.

We can’t legislate for that. And shouldn’t be expected to do so. Caveat utilitor. Test, test, test, then deploy. Besides the plugin issues which affect just a narrow band of plugins, a lot of the issues we’re seeing here are people who have run the beta locally (with more lax permissions than a hosting environment) and then hit problems when the updater can’t delete files on the live site. That we can do something about. It probably wasn’t picked up in beta because most people, I suspect, test locally.

Maintenance mode built in? Maybe one day.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#21 2016-09-13 21:11:52

maverick
Member
From: Southeastern Michigan, USA
Registered: 2005-01-14
Posts: 976
Website

Re: 4.6 upgrade compatible?

Well noted. Test, test, test.

<cough> ‘Cause only crazy people run bleeding edge Dev installs and upgrade live. <cough>

I’ve actually been fortunate living on the edge with my own installs. So far it’s only been a few times I mucked it up by not taking precautions, and they were easily fixed. Which says so much more about how great Textpattern than anything positive about my bad habits. :D

Offline

Board footer

Powered by FluxBB