nbcommunication

Hi @ai_slop, Just wanted to confirm that PageimageSource is built specifically to work with Pageimage. I'm not 100% sure about your example above, but if the gist is to add the 'static' images to a Pageimages field to then be rendered using Pageimage:render(), which PageimageSource extends, then that should work fine. Cheers, Chris

@adrian reported an issue where the module is generating entries in the files-errors log. We see this too on sites that are using the module. It is intermittent, but when it happens there are normally a few entries at the same time: rename: Rename to pathname ($newName) that already exists: /site/assets/files/8936/thumbnail_1000_x_1000_px_32.768x635-srcset-hidpi.webp rename: Rename to pathname ($newName) that already exists: /site/assets/files/8936/thumbnail_1000_x_1000_px_32.768x635-srcset-hidpi.jpg rename: Rename to pathname ($newName) that already exists: /site/assets/files/8936/thumbnail_1000_x_1000_px_32.300x600-srcset-hidpi.webp rename: Rename to pathname ($newName) that already exists: /site/assets/files/8936/thumbnail_1000_x_1000_px_32.300x600-srcset-hidpi.jpg rename: Rename to pathname ($newName) that already exists: /site/assets/files/8936/thumbnail_1000_x_1000_px_32.265x530-srcset-hidpi.webp rename: Rename to pathname ($newName) that already exists: /site/assets/files/8936/thumbnail_1000_x_1000_px_32.265x530-srcset-hidpi.jpg I've taken a look but can't see what is causing it, and reviewing Pageimage::size() suggests that it shouldn't be happening, as this checks whether the file exists before calling WireFileTools::rename(), where the error log originates. The best I can come up with is that because the module is (usually) passing webpAdd as an option to its width() / height() / size() calls, this sets forceNew to true, and a second request happens before the variation generation completes on the first request, and it is this second request that ends up generating the log entry (the first request completes between the second one checking and then calling rename). I'm not sure if that's it though, I could easily be missing something. @ryan do you have any idea what might be happening here? Is this an error you've seen in other places? EDIT: Adrian has consulted Claude and posted the result in the GitHub issue thread here: https://github.com/nbcommunication/PageimageSource/issues/8#issuecomment-4612395594. It does suggest a race condition which would need to be handled by a change to Pageimage::size(). Cheers, Chris

For a number of years we've grappled with how best to implement on-page structured data via JSON-LD. For almost all projects we've ended up using a code-based solution, with a standard JSON-LD output defined for all pages/templates, with any template specific structure defined in the template file (e.g. Article for a post template). This approach isn't particularly malleable, at least not for clients who actually want to implement JSON-LD themselves or via their SEO partners. MarkupJsonldModels is an attempt to find a good solution that's workable for everyone, including AgentTools. It uses the concept of "models" - valid JSON-LD using placeholder tags which resolve to actual page values when output on a rendered HTML page. It allows you to define a default model in the module config, a model for each template (assuming it will be output as HTML), and adds a field (jsonld_model) on installation which you can add to a template to allow a model to be defined per page. As GEO becomes more and more important, this is a module I hope will prove quite useful, however my own motivation for it is more laziness than anything else - I wanted to build something where I could just get an AI Agent to suggest and implement models via Agent Tools! Preliminary tests with this approach have been reasonable, and I can definitely see it being a time saver when I get it integrated into our dev process, and I expect the quality of the JSON-LD will end up significantly better too. However, it doesn't require Agent Tools to work - but an ability to work with JSON is... It is currently in Alpha, as it really hasn't been tested in the wild (just yet). I expect there will be another couple of rounds of dev and improvements once we start using it for existing sites that are current looking for GEO improvements. There's a pretty lengthy README - https://github.com/nbcommunication/MarkupJsonldModels/blob/main/README.md - which is likely a giveaway that I've been using Agent Tools (Claude 4.7) to assist in code and documentation review! Any thoughts and feedback would be much appreciated. Chris

@elabx - that's what Claude suggests. It looks more like a poor implementation in InnoDB itself to me but I'm sure there's reasons for why it behaves the way it does. Either way, I'd definitely be interested to hear what @ryan thinks.

Hi @elabx, Yes, but very small amounts. The kicker here is that it doesn't actually matter what is being stored, it is the frequency of writes that causes the index file to balloon. This caused me a lot of confusion, as I have sites where I store much larger JSON values in pages_meta and they don't appear to have the problem. Ultimately they do, but because writes are much less frequent the index file hasn't grown that much in comparison. Cheers, Chris

While trying to find the cause of disk usage increasing by several GB per week, I discovered a file inside /var/lib/mysql that was indeed increasing by several GB per week, sometimes up to a GB a day. This file is used for fulltext indexing: fts_000000000000dbd8_0000000000013612_index_1.ibd By running optimisation on the database tables, I was able to 'reset' the file. I thought it was maybe a bug in the database, so tried setting up a fresh database copy, but the issue persisted. Time to call Claude... Here's the full conversation: https://claude.ai/share/94de4c96-4a04-4fae-b3c5-de95225316bd Long story short, I was using pages_meta to record statistics tied to pages/users, so write operations on the table were pretty frequent. It seems a bit absurd to me that this could cause a index file to balloon to such a ridiculous size (it was 100GB when first discovered) as it isn't a high traffic site and the amount of data in the table is minimal (2MB). However because of the frequent writes, the indexing file was being frequently appended to and for some reason it doesn't prune itself it just keeps expanding. I've re-written the stats so they are stored on the filesystem instead of the database, so far that seems to be working. Claude brought a couple of things up, which would probably be worth reviewing @ryan: Why is there a fulltext index on the data column? No primary key Ultimately, I think the issue here is how I've gone about using pages_meta - It isn't the right solution for frequently updated datasets - but I thought I'd pass this on for consideration, and also for anyone else who might find themselves in the puzzling situation of a ballooning index_1.ibd file. Cheers, Chris

Hi @adrian, My experience is that it has to be implemented as middleware - as an example I've only experimented a little with Cloudflare Workers to implement a CSP nonce, but were it not for the Apache module this is likely the route I'd be going (for sites proxied through CF). A good goal, but I'm not sure it'll be achievable for sites using ProCache, there needs to be something modifying the cached HTML to add the nonce before serving it. Yep, agreed! We use a service (Report URI) to collate violation reports, and though it is a bit of a chore to review given the amount of violations that are recorded, that in itself is the reason to have it in place. I feel it also gives us a bit of a perspective on what clients are doing with their sites that we might not have otherwise, and for retained clients gives us information that allows us to be proactive (e.g. you've added a invalid media url on this page, it should be ...). Cheers, Chris

Hi, We use the mod_cspnonce + Apache SSI approach. .htaccess: Options +Includes AddType text/html .html .php AddOutputFilter INCLUDES .html .php <IfModule mod_headers.c> # If not the PW admin <If "! %{QUERY_STRING} =~ /{your-admin-url}/"> ... Header set Content-Security-Policy "\ default-src 'self';\ script-src 'nonce-%{CSP_NONCE}e' 'strict-dynamic';\ ... " </If> </IfModule> In your template: <!--NoMinify--> <script src="./your-script.js" nonce="<!--#echo var="CSP_NONCE"-->"> <!--/NoMinify--> Note that the NoMinify tags need to be added to stop ProCache stripping out the SSI var as it treats it as an HTML comment. We've been using this in production for 2-3 years on sites with the Apache module available and it works well. Cheers, Chris

@ryan, You'd mentioned at some point that existing installs could retain the old theme and perhaps users prompted to update to the new one. At the moment if I upgrade an existing site to the dev branch, the new theme is enabled by default. This breaks any custom TinyMCE styling as the new theme overrides it. Are you planning to implement this prior to the next master version? Ideally for us, given we have several hundred sites which we update to the latest master when it is available, nothing would change for the users. We could then turn on recommending a theme upgrade on a per site basis, or if we choose to, force the upgrade on the users. Cheers, Chris

Hi @Stefanowitsch, I'm afraid there's not much else I can recommend except from removing the account from the module (and removing the app from the IG account) and then trying to set it up again.

I agree, but shouldn't the labels be left-aligned in that case? Might just be me but I find the mix between alignments jarring.

I'd said as much to colleagues last week. At the same time, it's a development release. I think many of us working with PW may have just gotten used to the overall quality of dev releases and happy to work on projects on that branch as obvious bugs are a rarity. ... For what it's worth, I'm definitely getting used to working with the new theme now, and many of the things that niggled at me to begin with aren't now. I did find another tiny thing I wanted to point out: If the labels are centred on the login screen, the input text should be too? Cheers, Chris

Hi @Stefanowitsch, That's great, delighted to hear that! This is been a really useful exercise, I've pushed three bug fixes for the module so I'm happy 🙂 I'll update the README with a note that the module isn't compatible with DelayedImageVariations, and if I ever get around to it will try and figure out what the compatibility issue is. It isn't something I've used before. Cheers, Chris

Hi @Stefanowitsch, Thanks, could you please try the filesizeStr test with the attached image? Using this and gd I get 7.3 kB and 26.8 kB. EDIT: that's using 1000, 500 for the width and height. Cheers, Chris

Hi @Stefanowitsch, Something else that would be worth trying, output this somewhere: <?php echo implode('<br>', [ $pageimage->size(2550, 1440, [ 'webpQuality' => 10, 'webpAdd' => true, 'webpOnly' => true, 'suffix' => 'q10', ])->webp()->filesizeStr, $pageimage->size(2550, 1440, [ 'webpQuality' => 80, 'webpAdd' => true, 'webpOnly' => true, 'suffix' => 'q80', ])->webp()->filesizeStr, ]); Cheers, Chris