Feedback for: Textpattern CMS 4.8.2 released

gaekwad · 2020-07-30 05:09:05

Please provide any feedback here related to Textpattern 4.8.2 Released.

We appreciate all feedback. Please check the issue queue before raising a problem.

colak · 2020-07-30 05:35:05

nice! Thanks to all! Installed with no issues

jakob · 2020-07-30 07:34:11

👌

Pat64 · 2020-07-30 11:04:54

Just perfect (as always) ;)

zero · 2020-07-30 12:00:18

Thanks! All upgraded fine. Except one. I didn’t check to see what version it was before upgrading because I thought it was fairly recently upgraded. I’m sure it’s my fault (with outdated plugins) but I wondered is there a way to check what the previous version was, or is it too late?

gaekwad · 2020-07-30 14:01:03

zero wrote #324998:

[…] is there a way to check what the previous version was, or is it too late?

There’s a version string in the database – check the txp_prefs table, then look for the row where name column is version and the val column will give you a number. So, check your backup – should be listed there.

zero · 2020-07-30 15:06:41

gaekwad wrote #325010:

There’s a version string in the database – check the txp_prefs table, then look for the row where name column is version and the val column will give you a number. So, check your backup – should be listed there.

Thanks, Pete.

maverick · 2020-07-30 17:57:23

zero wrote #324998:

I’m sure it’s my fault (with outdated plugins)

Not so much 4.8.2 as upgrades in general

Zero’s comment has me thinking (I apologize in advance – always dangerous). There is another thread today where an upgrade was thrown because of an outdated plugin. I know over the years that outdated plugins are often the grief in upgrades.

Perhaps there is value (less grief, fewer support issues) if during the upgrade there was a way for all plugins to be automatically turned off, then once the upgrade was successful there was a friendly “one last step – enable all plugs” button.

Bonus if it only re-enabled compatible plugins based on the new plugin website.

Just thinking aloud. Again – often a dangerous tangential and unhelpful thing. :)

zero · 2020-07-30 18:14:23

maverick wrote #325016:

if during the upgrade there was a way for all plugins to be automatically turned off

In my case it was soo_if_frontpage which if turned off would be a mess. I updated it and it worked OK, so not much of a problem. Another problem was listform="snippet" which must have been the way back in the day. I don’t know when it was changed but form="snippet" worked fine. That’s what you get when you don’t update a site for years. It needs quite a few changes to be up to scratch, although it’s all working OK now.

giz · 2020-07-30 18:21:29

Bloke wrote #324600:

The new size attribute in <txp:images> to filter by size or aspect ratio. Try: size=

"landscape"

"portrait"

"square" (or "1")

"16:9" or "4:3" or "480:720" or something like that as a ratio

"1.33" or "0.89" or "0.75" or something like that as a decimal ratio (>1 = width greater than height. <1 = height greater than width)

"200:" to match images of exactly that width

":450" to match images of exactly that height

Fantastika!

gaekwad · 2020-07-30 18:40:56

I’m inclined to agree that we can tweak the upgrade instructions for the next release – especially with regard to plugins. One of the tweets I put out this morning refers to this, at least gently: twitter.com/textpattern/status/1288727766314221568

The snag I see with any upgrade instructions is you won’t cover all the bases, so it’s a best-effort attempt to at least keep some people interested. There will always be people who go the Bill O’Reilly “Do It Live” approach and to hell with the docs, and there are people who will read absolutely everything and still not be sure if they’re OK, and everyone in the middle.

I would propose something along the lines of:

make and check known-good backups
check the plugin status for current support info (this is the grind part)
be aware of the order that you need to do things in – disable plugins, upgrade them, whatever
upgrade as per the docs
go about your day

The old-old sites will always be tricky because the masses of plugins that were deployed. One client I had earlier this year had >30 plugins, that was a nightmare to work with. After the upgrade was done, there were about 5, and some of those weren’t really actively used.

So yeah, some words and advice on plugins is definitely a smart idea, from my point of view.

Bloke · 2020-07-30 19:38:56

Without trying to derail the thread, the way plugins are handled is going to change in 4.9. We’ll be offering upgrades from the Plugins panel directly and build compatibility checks in, as well as some other niceties that are already partly built.

This could open the door to doing something like maverick suggests, although without an in-site Txp upgrade procedure this might be tricky. The problem is we won’t know about compatibility issues in plugins until the admin-side is loaded for the first time, as that’s when the second half of the upgrade process occurs. So any plugins that are incompatible will do so before we get a chance to trap them.

The only way round it would be to do what you suggest and when an update is triggered, make a note of which ones are on, turn them off, do the upgrade, then perform a compatibility check per plugin (which is network-expensive unless we find a way to permit multiple queries in one request) and only turn on ones that are known compatible.

Finally, we’d need to somehow notify (maybe in the upgrade announce message at the bottom of the screen) that a new version is installed and, btw, your site’s likely to be broken because we’ve disabled such-and-such plugins, so go fix them now.

Not sure if that’s better or worse than a broken admin side or site. Probably better. Even so, we still can’t legislate for PHP issues. Some plugins just don’t work on newer PHP (>7) because they use direct MySQL calls, for example. Things like that are going to break the site whatever we do (though tagging such plugins as incompatible with a particular version of Txp might help).

In terms of upgrade preparation, I would be more inclined to do this:

On the Diagnostics panel alongside the ‘new version’ link add a ‘compatibility check’ link/button (or a new ‘compatibility check’ entry in the Detail dropdown if a new version is indicated as being available).
When initiated, that will perform a single network request to the plugins site for all active plugins in use. We can then comb through the returned set and indicate which ones are likely to be problematic. Perhaps link to their entries in the Plugins panel, individually or as a set (via a simple search) that shows all the incompatible plugins so you can quickly multi-edit to disable them.
Alternatively, find some way on the plugins panel itself to show which plugins are compatible, not with the currently installed Txp, but an arbitrary future version you pick from a list. At least then you could be prepared.

Dunno. Lots to think about and lots of things we could do to smooth the upgrade process. In the meantime, anyone who wants to tweak the upgrade documentation please be my guest to change it if you have commit rights or send in a PR.

Textpattern CMS

Textpattern CMS support forum

#1 2020-07-30 05:09:05