checksum.php

phiw13 · 2025-10-23 07:04:12

Based on the latest code (this issue I think), the /textpattern/checksums.txt file doesn’t check for the admin themes, instead each amin theme has its own checksums.txt (in theory, see below). One benefit from that is I can now delete unwanted / unneeded core admin themes without having to edit the main checksums.txt file (something I have been doing for more than 18 month…). Yay, love it.

If I understand it well, any admin theme can now have a checksums.txt file. To generate it, one would need to run some checksums.php script (something on how to create plugins I guess ?).

Some questions:

Is this the relevant file: github.com/textpattern/textpattern-toolbelt/blob/main/release/checksums.php ?
I then download it locally and run php path/to/checksums.php path/to/admin-theme-name? Or does the admin-theme need to reside inside a Textpattern install – e.g path/to/textpattern admin-theme-name?
how does the script know where to find all relevant files – js/php – css doesn’t seem included ? Or does it just iterate over all files in the folder?

Any guidance or suggestion appreciated

Bloke · 2025-10-23 09:09:47

phiw13 wrote #340973:

One benefit from that is I can now delete unwanted / unneeded core admin themes without having to edit the main checksums.txt file (something I have been doing for more than 18 month…). Yay, love it.

Glad it’s useful.

If I understand it well, any admin theme can now have a checksums.txt file.

Correct.

To generate it, one would need to run some checksums.php script

Correct.

Is this the relevant file: github.com/textpattern/textpattern-toolbelt/blob/main/release/checksums.php ?

Yes (or the one in the main repo’s .github/txp-checksums.php, which is a clone).

The caveat, as you’ve found, is that it needs to be told where to find an actual instance of textpattern (because it uses txplib_misc.php, constants.php, etc to take advantage of some core functionality).

So the fastest route to market if you’re developing the theme in its own silo is to either copy it into a textpattern instance (it doesn’t have to be a working copy with database and everything set up; just the files will do) or create a symlink from the admin-themes directory to your theme’s repo.

Then you can just run:

php path/to/checksums.php path/to/your-instance/textpattern admin-themes

(note the space – it’s not a full path: the admin-themes is the script’s second argument, which I admit is a trifle confusing)

That will recalculate all admin theme checksums.txt files. We’ll probably extend the syntax so you can specify just one theme name at some point.

how does the script know where to find all relevant files – js/php – css doesn’t seem included?

It hunts for all files with .php and .js suffixes. That’s all. I’m not entirely sure why we don’t checksum .css files. Perhaps because it’s not executable, per se, so wasn’t deemed a threat(?)

It’s easy for us to change it if we want to include .css files or any others. There’s a $fpattern regex line near the top of the checksums.php script that determines what it searches for.

Last edited by Bloke (2025-10-23 09:11:01)

phiw13 · 2025-10-23 09:33:17

Bloke wrote #340979:

So the fastest route to market if you’re developing the theme in its own silo is to either copy it into a textpattern instance (it doesn’t have to be a working copy with database and everything set up; just the files will do) or create a symlink from the admin-themes directory to your theme’s repo.

Ok, I think I can set up something with a bit creative symlinking. Hopefully I can even squeeze it in my build Applescript.

(note the space – it’s not a full path: the admin-themes is the script’s second argument, which I admit is a trifle confusing)

Yes that tripped me when trying to understand it all. I get it now.

It hunts for all files with .php and .js suffixes. That’s all. I’m not entirely sure why we don’t checksum .css files. Perhaps because it’s not executable, per se, so wasn’t deemed a threat(?)

It’s easy for us to change it if we want to include .css files or any others. There’s a $fpattern regex line near the top of the checksums.php script that determines what it searches for.

I don’t think CSS is a thread anymore, very bright minds in the browser & web-security world have gone through it many times to neuter it. On the flip side, it can hurt to include it.

Last edited by phiw13 (2025-10-23 09:33:37)

phiw13 · Yesterday 09:05:57

First: I finally got some time to set it up. I do have it working more or less. I had hoped making a symlink inside /textpattern/admin-themes/ pointing to my working build folder, but that only created an empty checksums.txt. Anyway for testing I moved a copy of my build folder inside and ran the script successfully.

I have to think how I successfully integrate that in my applescript

Second, I did get some php warnings (deprecated…) for each theme checked (PHP 8.4.14):

Deprecated: Automatic conversion of false to array is deprecated in /Users/username/Documents/…path_to…/txp-4.9/textpattern/lib/txplib_admin.php on line 1859
Checksums updated in /Users/phiw13/Documents/TXP-dev 2025/txpAdmin themes/txp-4.9/textpattern/admin-themes/phw_sandspace
PHP Deprecated:  Automatic conversion of false to array is deprecated in /Users/phiw13/Documents/TXP-dev 2025/txpAdmin themes/txp-4.9/textpattern/lib/txplib_admin.php on line 1856

Deprecated: Automatic conversion of false to array is deprecated in /Users/username/Documents/…path_to…/txp-4.9//textpattern/lib/txplib_admin.php on line 1856
PHP Deprecated:  Automatic conversion of false to array is deprecated in /Users/username/Documents/…path_to…/txp-4.9//textpattern/lib/txplib_admin.php on line 1859

Deprecated: Automatic conversion of false to array is deprecated in /Users/username/Documents/…path_to…/txp-4.9/textpattern/lib/txplib_admin.php on line 1859
Checksums updated in/Users/username/Documents/…path_to…/txp-4.9/textpattern/admin-themes/phw_sandspace

On the next run I did not get those warning(s). That next run was in the same Terminal tab I ran it previously.

Third. Textpattern see the checksums.txt files (Diagnostics, high) and detect any missing asset. Good. As far as I can tell it does not complain if a registered file has been modified. I modified my phw_sandspace.php file (unimportant things, but still) but no errors flagged in diagnostics (as opposed to missing files flagged).

Bloke · Yesterday 09:34:07

Thanks for testing. It should have detected the changes to your theme file in Diagnostics so it’s probably not triggering properly. I’ll investigate today, and also squish those warnings.

I would have expected the symlink to work too. That’s annoying. Hmmm.

phiw13 · Yesterday 11:38:41

Bloke wrote #341252:

Thanks for testing. It should have detected the changes to your theme file in Diagnostics so it’s probably not triggering properly. I’ll investigate today, and also squish those warnings.

It is easy to reproduce. Open /hive/hive.php and find the call to darkmode.js (line 51 according to BBedit), comment it out. Save. Login to your site and access diagnostics. In my reading that edit should suffice to trigger an error.

But noting here. Only the PHP-in-pages warning.

Bloke · Yesterday 14:41:30

phiw13 wrote #341251:

As far as I can tell it does not complain if a registered file has been modified.

Ah, wait. This’ll probably be because it doesn’t verify checksums if you’re running a dev version of Textpattern. Otherwise it’s forever complaining.

What we could do is allow you to termporarily override that bypass, by adding a URL var, because sometimes it could be handy to check, prior to release, that your theme checksums are up-to-date.

Bloke · Yesterday 14:50:17

Bloke wrote #341255:

What we could do is allow you to temporarily override that bypass, by adding a URL var

Try that. Add &checksums=1 to your Diagnostics panel URL to trigger the checks.

Bloke · Today 00:03:28

Latest commit has hopefully resolved the symlink issue, so you should now be able to operate in a remote vcs-controlled environment and still be able to have the checksums generated.

This feature extends to checksums from the Diagnostics panel too, so you can have your themes remotely-housed and symlink them from the admin-themes directory, and still get checksum warnings if you make changes and permit them to show in dev installs by adding &checksums=1 to the URL.

Not sure I’ve managed to eradicate the warnings yet because I’m not entirely sure why they’re occurring, but if they still pop up I’ll take a deeper look.

phiw13 · Today 06:23:32

Bloke wrote #341255:

Ah, wait. This’ll probably be because it doesn’t verify checksums if you’re running a dev version of Textpattern. Otherwise it’s forever complaining.

I should have thought that, my bad…

Try that. Add &checksums=1 to your Diagnostics panel URL to trigger the checks.

But now with &checksums=1 to the URL it works well. Immediately Diagnostics showed me long list of modified files (modified theme files and all core files that have been modified since the checksums.txt was last updated…. ). Great work. And that is a nice way to check which core files have been recently modified.

Ref symlinks. Both the checksums.php and the diagnostics panel now handle those correctly. That is cool, both to integrate the checksums generation into the workflow and testing the theme before release.

PS – I felt adventurous… I checksummed the .css files as well. All work as expected.

Thank you for all that.

Textpattern CMS

Textpattern CMS support forum

#1 2025-10-23 07:04:12

checksum.php

#2 2025-10-23 09:09:47

Re: checksum.php

phiw13 wrote #340973:

#3 2025-10-23 09:33:17

Re: checksum.php

Bloke wrote #340979:

#4 Yesterday 09:05:57

Re: checksum.php

#5 Yesterday 09:34:07

Re: checksum.php

#6 Yesterday 11:38:41

Re: checksum.php

Bloke wrote #341252:

#7 Yesterday 14:41:30

Re: checksum.php

phiw13 wrote #341251:

#8 Yesterday 14:50:17

Re: checksum.php

Bloke wrote #341255:

#9 Today 00:03:28

Re: checksum.php

#10 Today 06:23:32

Re: checksum.php

Bloke wrote #341255:

Board footer