RFC: Textpattern 5 ideas & feature requests

phiw13 · 2025-12-19 23:21:28

mistersugar wrote #341832:

bici does this mean I also need to get AlnaLinux sith OpalStack (I’m on shared hosting there) in order to upgrade my Txp sites to 4.9.0?

You would benefit anyway of migrating to the Almalinux stack (modern Apache, modern OpenSSL, more modern Linux deep down, …). DB migrates to Percona Server (8.4.6-6) from MariaDB. No problems with that as far as Textpattern is concerned

I migrated back in August or so and it was smooth. Make sure you have a backup (DB, config.php, etc), but your sites in maintenance mode(smd_at_work), and the Opalstack people do the rest (basically run rsync, I think).

Oh, and Textpattern 4.9 runs very well with PHP 8.5.

mistersugar · 2025-12-22 19:03:57

phiw13 wrote #341847:

You would benefit anyway of migrating to the Almalinux stack (modern Apache, modern OpenSSL, more modern Linux deep down, …). DB migrates to Percona Server (8.4.6-6) from MariaDB. No problems with that as far as Textpattern is concerned

Thanks for confirming. Just so I’m clear: I should migrate first, then update Txp to the new 4.9, right?

gaekwad · 2025-12-22 19:21:40

mistersugar wrote #341952:

Thanks for confirming. Just so I’m clear: I should migrate first, then update Txp to the new 4.9, right?

What version(s) of PHP are available on the new server?

You’re essentially stuck with a PHP 8.2 glass ceiling with Textpattern 4.8, so anything beyond that will cause warnings / errors. If you upgrade to Textpatten 4.9 before you migrate, it will run just fine with the older PHP…then you can migrate to the new server knowing that Textpattern 4.9 is compliant with current PHP.

bici · 2025-12-22 20:41:51

mistersugar wrote #341952:

Thanks for confirming. Just so I’m clear: I should migrate first, then update Txp to the new 4.9, right?

I updated all sites to use PHP 8.3 , then I had Opalstack support migrate my server to AlmaLinux. Then accessed all my sites to ensure there were no issues. After migration I updated all my sites to 4.9 and then set my apps to use PHP 8.5 .
Opalstack wants you to update the password of the user that controls the Databases. I had one owner for all databases. So I had to only update that owner in the Opalstack user panel. You can simply change password and simply retuse the same password. I choose to actually change the password , and so I had to update the config.php file for each site to use the new password. Reach out to support if you have concerns.
PS they keep the old sites around for a week or so to make sure all is ok.

Last edited by bici (2025-12-22 21:32:30)

mistersugar · 2025-12-23 02:43:42

bici wrote #341955:

I updated all sites to use PHP 8.3 , then I had Opalstack support migrate my server to AlmaLinux. Then accessed all my sites to ensure there were no issues. After migration I updated all my sites to 4.9 and then set my apps to use PHP 8.5 .

Great. I’m all set on what I need to do. So much appreciate bici and gaekwad and all the devs and users who make this an inviting and helpful community. Thank you!

gaekwad · Yesterday 14:41:04

[I may have skipped the discussion that has already covered this, please let me know if it’s elsewhere. Thank you. In a similar vein, this may be completely impractical.]

Where editable text assets (e.g. styles, forms) are managed via the admin-side (i.e. not flat files / served with etc_flat or similar), calculate the sha256, sha384 and sha512 hashes for each asset on save, and store them in the appropriate row.

This can be done in-browser with existing tools, and that process may be liberate-able (license will need to checked, of course) for our own use. Examples:

emn178.github.io/online-tools/sha256.html
emn178.github.io/online-tools/sha384.html
emn178.github.io/online-tools/sha512.html

CSP Level 2 spec covers the above three algorithms, and it’s seemingly not computationally expensive for the write-rarely-read-frequently use case that styles and forms usually have. A sha256 hash is 64 characters, a sha384 hash is 96 characters, and a sha512 hash is 128 characters. Total hash burden in each style / form’s row would be 256 characters.

A tag attribute could retrieve the appropriate row cell for when e.g. the style is called, and the hash can be inlined.

Bloke · Yesterday 15:24:19

Nice idea. What would the tag extraction of he value do for us? Would it recompute the hash on load and refuse to display the resource if the hashes don’t match (and perhaps some security flag is toggled on in prefs)? Or is it just for informational purposes?

Also: live/dev lanes to consider and how the updates would work when pushing dev->live.

gaekwad · Yesterday 15:37:09

Bloke wrote #342117:

What would the tag extraction of he value do for us?

High level: populate the html integrity attribute where it’s used:

<link rel="stylesheet" href="main.css" integrity="sha256-abcdefg1234567hijklmnopqrstuvwxyz=" crossorigin="anonymous">

Something along the lines of:

<txp:css format="link" integrity="sha256" media="" />

Would it recompute the hash on load and refuse to display the resource if the hashes don’t match (and perhaps some security flag is toggled on in prefs)? Or is it just for informational purposes?

Top contour: depends on the CSP of the site, either something written to browser console, or a clattering halt where it won’t load.

Last edited by gaekwad (Yesterday 15:37:27)

Bloke · Yesterday 17:32:34

gaekwad wrote #342118:

High level: populate the html integrity attribute where it’s used

That works for me. What about media assets too? (I’m thinking downloads on .com here…)

gaekwad · Yesterday 17:46:43

Bloke wrote #342119:

That works for me. What about media assets too? (I’m thinking downloads on .com here…)

That might depend on external…erm…dependencies and system contstraints, unless we’re in hash_file territory for file system blobs. It’s likely to be expensive if the file is large, I would expect…at least compared to some stuff in a textarea.

Bloke · Yesterday 17:47:23

True dat.

Textpattern CMS

Textpattern CMS support forum

#133 2025-12-19 23:21:28

Re: RFC: Textpattern 5 ideas & feature requests

mistersugar wrote #341832:

#134 2025-12-22 19:03:57

Re: RFC: Textpattern 5 ideas & feature requests

phiw13 wrote #341847:

#135 2025-12-22 19:21:40

Re: RFC: Textpattern 5 ideas & feature requests

mistersugar wrote #341952:

#136 2025-12-22 20:41:51

Re: RFC: Textpattern 5 ideas & feature requests

mistersugar wrote #341952:

#137 2025-12-23 02:43:42

Re: RFC: Textpattern 5 ideas & feature requests

bici wrote #341955:

#138 Yesterday 14:41:04

Re: RFC: Textpattern 5 ideas & feature requests

#139 Yesterday 15:24:19

Re: RFC: Textpattern 5 ideas & feature requests

#140 Yesterday 15:37:09

Re: RFC: Textpattern 5 ideas & feature requests

Bloke wrote #342117:

#141 Yesterday 17:32:34

Re: RFC: Textpattern 5 ideas & feature requests

gaekwad wrote #342118:

#142 Yesterday 17:46:43

Re: RFC: Textpattern 5 ideas & feature requests

Bloke wrote #342119:

#143 Yesterday 17:47:23

Re: RFC: Textpattern 5 ideas & feature requests

Board footer