-
Posts
313 -
Joined
-
Last visited
-
Days Won
8
nbcommunication last won the day on May 21 2025
nbcommunication had the most liked content!
Profile Information
-
Gender
Not Telling
-
Location
Lerwick, Shetland
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
nbcommunication's Achievements
-
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