Error when installing a plugin, last 4.7 dev

etc · 2017-12-07 12:32:01

Hmm, yes, 1 is a valid point, didn’t thought of it. As for 2, I meant update directory check, not remote.

What stops me from auto-config is the possibility that someone runs setup before you do.

phiw13 · 2017-12-07 12:32:23

jpdupont wrote #308155:

plugin upload: non active textarea and idem file upload zone.

See my latest post in the theme thread.

etc · 2017-12-07 12:36:28

Bloke wrote #308154:

Untested, but I suspect that will break people’s sites spectacularly ;-)

Too late :-) But why would it?

Bloke · 2017-12-07 12:41:11

jpdupont wrote #308155:

I had at the start the indication of a new version and sending to diagnostics.

So the upgrade script ran. Good…

My problems are still there: plugin upload: non active textarea and idem file upload zone.

… but perhaps not fully.

BTW, site not breaken …

Because your previous failed upgrade attempts may have left the database in a “half-updated” state.

During upgrade, we test certain things and make (probably foolish) assumptions. For example:

Does the textpack column exist in the database?
Yes, great!
No, add textpack and data columns, then modify the help column size.

See the problem there? It’s subtle. If during a previous upgrade run, the textpack column was added but the data and help changes weren’t (for some reason) then you’ll get errors or weird behaviour because the filesystem expects the database to contain those table changes.

If you re-run upgrade to ‘fix’ the problems, it looks for the textpack column, finds it, says to itself, “Great, that’s all been done” and carries on. Crucially, it bypasses the addition of the extra columns because they were tied to the check for the textpack column.

The safer – slower – way we should be doing upgrades is:

Does the textpack column exist in the database?
Yes, great!
No, add textpack column.
Does the data column exist in the database?
Yes, great!
No, add data column
Is the help column size what we expect?
Yes, great!
No, modify the help column size.

That way, we can guarantee that all changes are done even if a partial upgrade occurred. Historically, we haven’t done that, and the tradition continues in 4.7.0. Maybe we should adopt that methodology to help avoid situations like this?

Bloke · 2017-12-07 12:53:06

etc wrote #308159:

Too late :-) But why would it?

Without testing I’m not positive it wouldn’t work. If it does, great. But imagine this:

You upload files for new version.
You – or some other user – log in and your default panel is the Languages panel (you like that page, okay?!)
You land on that panel. There’s a message in the footer but you don’t see that. And even if you did: “New version available? So what, I’ll do that later.”
Your page is a bit haywire. The file system has asked to fetch available languages, which it does, but they have old key names.
You notice it says all your languages are out of date.
You click one to update it. Boom! It can’t find that file because the key it looks for (based on the lang column in the DB) is the 4.6.2 reference. The database upgrade hasn’t taken place which refactors all keys in the table. That will continue to be the case until you complete the upgrade process by visiting Diagnostics.

Potentially the same issue on any other page. The filesystem might expect columns to be there that aren’t. Or that have been renamed, resized, reindexed…

Bottom line: in our current system, after any filesystem update that changes the version, the corresponding DB updates MUST run immediately.

etc · 2017-12-07 13:05:38

What have I done! crazy… Well, what is the point of sending to Diagnostics pane? Let’s update, cleanup, post a message and leave the hand to events?

Bloke · 2017-12-07 14:13:05

etc wrote #308162:

Well, what is the point of sending to Diagnostics pane?

Traditionally we’ve landed on Languages. I’m intending to auto-update those during upgrade so we no longer need to land there as it’ll indicate they’re all up-to-date. A better place to indicate that an upgrade has taken place is Diagnostics, because any snafus that have occurred during the process can be shown there as part of the regular diagnostic checks.

Plus, it shows a “Welcome to Txp X.Y.Z” message there now. In theory…

In future, I was planning on introducing a ‘flash message’ – one time persistent message store. Like an array. Any actions that take place get added to that, one per row, with their severity marked. Then, on next page refresh the entire array is output and the Flash array is wiped.

We could use this during upgrade. Each action that’s done, add it to the flash message store and then – when everything’s done, dump it out beneath the ‘welcome’ message under a twisty so you can see the detailed results of what’s been done.

Longer term, there’s no reason we couldn’t do that for the regular messages too on every panel. Instead of relying on returning a single $msg string from actions, any exceptions or success messages get added to the Flash Message array. Plugins casn use it too. Then on page load, the message appears at the bottom of the screen and the Flash message array is wiped (just in case).

The beauty here is that the message area doesn’t have to be confined to one colour. It might have 2 actions that succeeded, one that failed. We could show three line items, green, green, red. Better traceability.

I have the class written – at least most of it – but haven’t got round to finishing it. Anyone who wants it, just holler and I’ll send it over.

Last edited by Bloke (2017-12-07 14:13:43)

etc · 2017-12-07 14:26:28

Then welcome to the future — the messages are merging now (had to do it for multiple files upload). The upgrade script (and anyone else) can add as many messages as it needs. The system is very basic and we’ll certainly push it further in some future future. :-)

Why redirecting is bad: imagine you have spent hours on huge file uploading, close to 100% and paf! — someone has uploaded new version meanwhile but not yet run the update script. I’m for making updates less intrusive.

jpdupont · 2017-12-07 14:54:19

Thanks Philippe ;-)

I just followed the advice of Philippe (Sand space) and as I was using a custom.css file in Sandspace and Hive, I replaced the admin themes files by their original version, without modification.

And currently, the above problems are solved :-))
Since my custom.css files have been running for over a year, there is probably something that has been changed in the last month in the page structure …

Bloke · 2017-12-07 15:08:27

etc wrote #308164:

the messages are merging now

Yes I spotted that, but didn’t see that they could handle different colours per message.

The system is very basic and we’ll certainly push it further in some future future. :-)

Yep.

Why redirecting is bad: imagine you have spent hours on huge file uploading, close to 100% and paf! — someone has uploaded new version meanwhile but not yet run the update script. I’m for making updates less intrusive.

Yes, that’s bad UX. But for an upgrade to successed for all users you really need downtime; albeit just a little. Anyone who’s logged in or using the site during upgrade will get some strange results as files are partially replaced / uploaded and DB wrangling is done.

Test: upload a huge file like taghandlers.php or txplib_misc.php via FTP and – mid upload – hit refresh in your browser. PHP blows up.

Like all systems, upgrades should be done at a mutually beneficial time during a scheduled maintenance window.

If we can make the whole process more seamless – and less of a two-step operation – I’d love that! “Click to download and install this version”. And if it can’t do it for permissions reasons, offer the step-by-step instructions to upload by hand and complete the process.

etc · 2017-12-07 15:22:26

Hehe, true dat, but we are a “small content management system”, so txp upload time is. If there are no new update messages planned for 4.7, I would submit a patch that makes it less obtrusive.

The merged messages statuses are currently marked with corresponding icons, replacing them with a color is just a UX question. But there is certainly room for improvement.

Bloke · 2017-12-07 15:36:26

etc wrote #308168:

The merged messages statuses are currently marked with corresponding icons, replacing them with a color is just a UX question. But there is certainly room for improvement.

I might look into using the multi-message thing for upgrades, as well as fix the upgrade process so it’s more reliable, with checks per action.

If there are no new update messages planned for 4.7, I would submit a patch that makes it less obtrusive.

We have themes to merge in yet, but if you have some improvement tweaks to streamline upgrades we could consider them. Branch away!

Textpattern CMS

Textpattern CMS support forum

#13 2017-12-07 12:32:01

Re: Error when installing a plugin, last 4.7 dev

#14 2017-12-07 12:32:23

Re: Error when installing a plugin, last 4.7 dev

jpdupont wrote #308155:

#15 2017-12-07 12:36:28

Re: Error when installing a plugin, last 4.7 dev

Bloke wrote #308154:

#16 2017-12-07 12:41:11

Re: Error when installing a plugin, last 4.7 dev

jpdupont wrote #308155:

#17 2017-12-07 12:53:06

Re: Error when installing a plugin, last 4.7 dev

etc wrote #308159:

#18 2017-12-07 13:05:38

Re: Error when installing a plugin, last 4.7 dev

#19 2017-12-07 14:13:05

Re: Error when installing a plugin, last 4.7 dev

etc wrote #308162:

#20 2017-12-07 14:26:28

Re: Error when installing a plugin, last 4.7 dev

#21 2017-12-07 14:54:19

Re: Error when installing a plugin, last 4.7 dev

#22 2017-12-07 15:08:27

Re: Error when installing a plugin, last 4.7 dev

etc wrote #308164:

#23 2017-12-07 15:22:26

Re: Error when installing a plugin, last 4.7 dev

#24 2017-12-07 15:36:26

Re: Error when installing a plugin, last 4.7 dev

etc wrote #308168:

Board footer