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

Hi @Stefanowitsch, I've tested using gd and it is working as expected for me. Could you output phpinfo() and let me know what it says for gd? Here's what's on our dev server: Cheers, Chris

Hi @Stefanowitsch, I've tested based on the information you've provided and it isn't replicating: <?php // /site/config.php $config->imageSizes = [ 'title-img' => [ 'width' => 2550, 'height' => 1440 ] ]; // output, original pageimage is > 3000px wide echo print_r(explode(', ', $pageimage->size('title-img')->srcset([ 640, 1024, 1500, 1920, 2550, ])), 1); // result Array ( [0] => /site/assets/files/1031/very_large_array_clouds.640x361-srcset.webp 640w [1] => /site/assets/files/1031/very_large_array_clouds.1024x578-srcset.webp 1024w [2] => /site/assets/files/1031/very_large_array_clouds.1500x847-srcset.webp 1500w [3] => /site/assets/files/1031/very_large_array_clouds.1920x1084-srcset.webp 1920w [4] => /site/assets/files/1031/very_large_array_clouds.2550x1440.2550x1440-srcset.webp 2550w ) With module config webpQuality setting at 85 With module config setting at 10 With module config empty (defaults to 90 - there was a bug here, fix to be pushed shortly) The quality setting in the module config is definitely being used in this case. Reviewing the above, I'm quite surprised at the difference in file size between 85 and 90. There has to be something else going on here, maybe the image sizer engine (Imagick used here but that about as far as my knowledge goes on these things). Do you have access to any other server environments to try to replicate the test on? I've run this on a dev server and a production server which have different setups with the same result on both. Cheers, Chris

Hi @Stefanowitsch, PageimageSource:srcset() doesn't directly do any evaluation of the file sizes to decide what to return, it is just calling Pageimage::url() if webP is off, and Pageimage::webpUrl if it is on. When I test I'm getting all JPEG if off, and all webP if on. I don't use named size variations myself, quite possible that this is where the issue lies, and I need to implement something additional to handle these. What's the value of $imgFormat? Cheers, Chris

Hi @Stefanowitsch, Can you please share an example of the $srcset and $options arguments you are passing to srcset()? Cheers, Chris

This sounds good to me. Cheers.

Hi @Stefanowitsch, Thanks, I think I've spotted the issue here. The final image in the set was using the original image without applying the given options. I've pushed a fix for that which should be available as v1.1.4. Please let me know if that sorts it for you. Cheers, Chris

Hello, After spending a week with the new admin theme, my feeling is that it is definitely a step in the right direction, making the admin feel more like an application, and many thanks to all who've worked to get it where it is. That said, there's quite a few issues I and the team here have picked up on. Most of these have been highlighted already. Here's some observations interspersed with some issues: Page Tree A number of colleagues have commented on the removal of the 'lines' on the page tree. I much prefer the new look, but it may be useful to have the option to toggle this on/off. I also like the 'text' style of the action buttons, but feel a more button-like style on hover would help. Colouring Something I'm not keen on is the lack of colour for the messages. Having the primary alert colour being the same as the background makes it hard to notice. We think the background colour (#eee) in light mode is too dark. #fafafa feels better. I also miss the colour of AsmSelect items. Having these in grey makes them blend in too much. Dark mode I prefer dark mode, but I've found myself switching to light mode on all the installs I've worked on. I can't pin down the problem though. It might be that the muted grey background makes the actual UI (fieldsets) too stark. It doesn't feel right. I agree with other comments that there needs to be an ability to customise the logo and colour for both modes. The installer needs to be tested in dark mode. All the input text is white on an input on a white background! (longest, most frustrating PW install ever!) Colour picker I think there should be at least two more fields beside the colour picker input, one for HEX value, and another for RGB. Editing one updates the others. On Safari, the native colour picker doesn't give you the option to input a value so I needed to login on Chrome to set the value I actually wanted. ... My main concern with this is the rollout when this reaches the master branch. We have a setup where we can update all PW sites on a server at once, and as it stands I think we'll need to go into each site to specify light mode. We want the rollout to be successful with our clients, and we'd prefer to adopt the new theme gradually, as and when we're working on a site. I think retaining the original UIkit theme as the default should be considered. Cheers, Chris

Hi @Stefanowitsch, Thanks, yes this is a bug. It was affecting the webP generation when using <picture> and was just defaulting to 90 for quality. I've pushed a fix for this and refreshed the module so it should be available for upgrade now. As for webP being larger than the original - I've found this to be the case for some images. There's some good info on this in this thread: Cheers, Chris

Hi @mel47, That sounds like either an issue with the image or the library that's converting to webP. There isn't anything in the module to exclude file types, but you could do that in your own code: <?php $pageimage = $page->image; if($pageimage->ext !== 'png') { // your srcset code } You could also try: <?php $pageimageSource = $modules->get('PageimageSource'); $pageimage = $page->image; if($pageimage->ext === 'png') { $pageimageSource->webp = false; } // Your srcset code Cheers, Chris

Hi @DV-JF, I'm afraid the only thing I've to add is that I've found the Meta dev system pretty buggy - I've had issues with the system in the past and found people reporting the bugs on https://developers.facebook.com/community/. Worth a look there. Also worth trying again after a while! Cheers, Chris