RFC: Textpattern 5 ideas & feature requests

Bloke · 2024-08-21 13:25:37

bici wrote #337689:

a shell script command to update Textpattern via the command line on the server.
eg. php txpcli.php update

Paging @gaekwad. Thoughts?

gaekwad · 2024-08-21 13:50:35

Bloke wrote #337694:

Paging @gaekwad. Thoughts?

I thought I felt my ears burning…

Interesting idea. The auto-installer is a solved problem and battle-tested, but there’s a whole level of other complexity with an upgrade script, including:

Less than 100% visibility on what level of shell access is available
Less than 100% visibility on what apps are available (rsync might be limited, for example)
Less than 100% visibility on ownership permissions
Less than 100% visibility on what assets (files, directories) are to be kept (especially if someone is using /textpattern/some-custom-directory/etc/
Responsibility for backups

It might be easier if we have a much more modular & predictable file + directory structure with v5, but right now it scares me to even try undertaking this on a third-party site.

That said…Wordpress can do the whole thing from the admin-side, so it’s not beyond the realms of possibility. No shell stuff required.

gaekwad · 2024-08-21 13:54:01

This is a v5 preflight thing I’ve been thinking on, could be applied to v4.8 to help us out with upgrading.

A function to export site content to an archive, which can be imported into a v5 site, should we decide that we’re gonna run with scissors and break backwards compatibility to that extent.

Some or all of: files, images, articles, scaffolding (categories & sections), database, and anything else I’ve forgotten.

Edit: I forgot themes.

Last edited by gaekwad (2024-08-21 13:55:55)

Bloke · 2024-08-21 14:29:01

Yes, upgrades are tough not only because we rely on admins uploading files, but also because not all of those files are required or even desired in a live installation. That’s why I asked @bici about what his expectations were.

Is it the intention to run a single command in a live installation, have it know where to get the source files (github release?) and pull them down, unpack them in a temp location, apply only the ones it needs, without trampling anything the user might have customised, then run the upgrade script (if we expose it to cli use, as it will currently only run via the web server, or introduce a parallel script that can run from the cli) to update the database and set the version, then check for updates to plugins/themes and ask for those to be upgraded too?

Or is it simply enough to have the user manually upload the relevant files and have the cli kick off the upgrade? And then rely on the admin to manually update the plugins and themes afterwards.

There are so many facets of an upgrade vs an installation. It’s relatively easy to do it in a semi-controlled web server environment; way more difficult in the wild west of the command line. Not saying it’s impossible, but it would need some carefully considered and refactored code to separate out the various bits.

For example, in some respects it would be easier if the upgrade database commands were bundled into a separate file and could be executed by the web browser upgrade path (via logging into Txp, as we do now) OR some CLI process by directly logging into the DB (credentials taken from config.php) and applying them. But filesystem changes are often interleaved with the DB alterations and need to be done in particular orders, so it’s tricky to segregate them. And sometimes we need to use the power of our safe_*() commands to execute stuff in loops, which is tedious or impossible to do directly in SQL.

Lots to think about. So if we are going to consider this – perhaps alongside broader changes such as boosting our import/export capabilities to include files and images – then we need to define the scope of what “do upgrade” really means.

EDIT: I think I would rather initially put the effort into giving the Diagnostics panel’s “new version is available” the ability to “click here to install it” and have it go through the process of fetching and unpacking source files, then kicking off the /update scripts to apply database and filesystem changes. Although we recommend logging out during upgrades, that’s primarily because logging in again is a more deterministic starting point to trigger upgrade scripts. We’ve relaxed that requirement in recent versions (4.7+ or 4.8+, I forget which) with more robust checks on every admin page load to see if an upgrade is required and kick it off if so.

Perhaps as a by-product of allowing the application to download and unpack itself, that unlocks the ability for a shell script to do likewise.

Last edited by Bloke (2024-08-21 14:35:47)

bici · 2024-08-21 17:26:39

gaekwad wrote #337695:

I thought I felt my ears burning…

Interesting idea. The auto-installer is a solved problem and battle-tested, but there’s a whole level of other complexity with an upgrade script, including:

Less than 100% visibility on what level of shell access is available

Less than 100% visibility on what apps are available (rsync might be limited, for example)

Less than 100% visibility on ownership permissions

Less than 100% visibility on what assets (files, directories) are to be kept (especially if someone is using /textpattern/some-custom-directory/etc/

Responsibility for backups

It might be easier if we have a much more modular & predictable file + directory structure with v5, but right now it scares me to even try undertaking this on a third-party site.

That said…Wordpress can do the whole thing from the admin-side, so it’s not beyond the realms of possibility. No shell stuff required.

It was just a thought, albeit not a well thought out one.
All these years of updating have been fairly pain free and always successful. And the ones time I had to roll back that was also successful due to the manual process and backing up of the DB PRIOR to updating. Please set aside for now. Best to concentrate on all the other goodness that the devs are working on. Hope for the Future.

gaekwad · 2024-08-27 11:48:49

Manage admin themes in a similar way to front-side themes.

phiw13 wrote #337727:

Meanwhile, you can hide it in a custom.css inside the admin theme in use:

This would be straightforward enough with a front-side theme, but admin themes are a different beast.

jakob · 2024-08-27 22:04:55

gaekwad wrote #337734:

Manage admin themes in a similar way to front-side themes.

This would be straightforward enough with a front-side theme, but admin themes are a different beast.

Actually it is as simple as that for the admin themes. You just have to remember not to accidentally overwrite your custom.css when updating textpattern. If /admin-themes and other user-supplied data were to removed from /textpattern folder (as discussed on GitHub), that risk would be much reduced.

phiw13 · 2024-08-27 23:58:23

jakob wrote #337736:

Actually it is as simple as that for the admin themes. You just have to remember not to accidentally overwrite your custom.css when updating textpattern. If /admin-themes and other user-supplied data were to removed from /textpattern folder (as discussed on GitHub), that risk would be much reduced.

Well, not completely as easy as for a front-end theme as you need sFTP access to edit that stylesheet. But then one could argue that modifying the admin-theme in use is something only a more high-level user would be doing / allowed to do.

That said, yes moving admin-themes/ out of /textpattern/ would be a good-thing-to-do. It is already possible for /textpattern/plugins/ as a user configuration.

Textpattern CMS

Textpattern CMS support forum

#13 2024-08-21 13:25:37

Re: RFC: Textpattern 5 ideas & feature requests

bici wrote #337689:

#14 2024-08-21 13:50:35

Re: RFC: Textpattern 5 ideas & feature requests

Bloke wrote #337694:

#15 2024-08-21 13:54:01

Re: RFC: Textpattern 5 ideas & feature requests

#16 2024-08-21 14:29:01

Re: RFC: Textpattern 5 ideas & feature requests

#17 2024-08-21 17:26:39

Re: RFC: Textpattern 5 ideas & feature requests

gaekwad wrote #337695:

#18 2024-08-27 11:48:49

Re: RFC: Textpattern 5 ideas & feature requests

phiw13 wrote #337727:

#19 2024-08-27 22:04:55

Re: RFC: Textpattern 5 ideas & feature requests

gaekwad wrote #337734:

#20 2024-08-27 23:58:23

Re: RFC: Textpattern 5 ideas & feature requests

jakob wrote #337736:

Board footer