Leaderboard

This week I’m happy to report we now have WEBP support in ProcessWire thanks to a GitHub pull request from Horst Nogajski. This enables you to have highly optimized image output in PW and I think you’ll really like the difference it makes. Read on for all the details… https://processwire.com/blog/posts/webp-images-in-pw/

@ryan thank you very much for all the additions you implemented in such a short time on top of my github pullrequest. It seems that there currently nothing is left in regard of webp support in ProcessWire. But I already have one or two points for future updates to the image rendering engines, that should be implemented when all browsers will support webp and we don't need fallback jpegs or pngs anymore. ?

UPDATE OK, after I've faced that for and against again, I've decided to make the module freely available. If you are interested, you can test the current state of development. I already put the module on GitHub. Please note that the software is not yet intended for use in a production system. (Alpha version). For example, the configuration and handling of the VAT rates are still missing. Also the dashboard is still incomplete. And many other things needs to be improved and implemented... ? If you like, you can also submit feature requests and suggestions for improvement. I also accept pull requests. https://github.com/gadgetto/SnipWire

sure

Woooaw - with your query and renaming the fields of the other template, I got a perfect result!! (You were right that the column names have to be different) Thanks a lot. This is using my old hacky Tabulator grid ?

Hi Beluga, is this a tabulator grid? Is it a custom module or the rockgrid extension you've linked some time ago? Regarding your join: I think in that case it would be the easiest to join them via plain sql; Something like $foo = $finder1->getSQL(); $bar = $finder2->getSQL(); $sql = "SELECT * FROM ($foo) AS foo LEFT JOIN ($bar) as bar ON (foo.col1 = bar.col1 AND foo.col2 = bar.col2)"; $this->setData($sql); PS: Be careful when joining / listing tables that have same name columns! This can lead to different results in the grid than in the resulting sql table. Compare the results to a regular SQL client by copying the resulting sql and executing it in Adminer and similar...

301 are totally fine - for ProcessWire and Google. Nothing to worry about. Read next part - as you have almost nothing to do for this. ? The existing ProcessWire .htaccess file already has this in place. Uncomment two lines and you are ready to go. # ----------------------------------------------------------------------------------------------- # 13. OPTIONAL: Redirect users to the 'www.' version of the site (uncomment to enable). # For example: http://processwire.com/ would be redirected to http://www.processwire.com/ # ----------------------------------------------------------------------------------------------- # RewriteCond %{HTTP_HOST} !^www\. [NC] # RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301] You can just add those fields to the user template - which can be found in Setup > Templates (after enabling showing system templates). And of course you have to create those fields first - if not already created. Setup > Fields There you can create all kinds of fields. Text, textarea, image, whatever... I recommend doing the tutorials available here: https://processwire.com/docs/tutorials/ They will help you to understand ProcessWire. It's absolutely not a waste of time. Even as someone who never worked with ProcessWire, but having some basic knowledge in terms of PHP, can learn ProcessWire within a weekend.

Thanks Ryan and horst!

This looks great! I've set up my fair share of Snipcart sites, but never bothered to abstract any of it into a module. So thanks for making this available in whichever form you're comfortable with, free or paid. My Snipcart styles have usually been very tightly linked to the site stylesheets (shared SASS variables and mixins) and ended up in the global site stylesheet. Maybe the stylesheet URL input shouldn't be mandatory for sites that already have the Snipcart CSS embedded? Just a thought.

@teppo Thank you very much. Yes, I plan to go with ProCache and to avoid template caching for most of the templates. I think I misunderstood the comment of Soma regarding the template cache problem, thanks for the hint.

Ok, I read the issue 432 thread again, so yes, the need to "revisit" (Ryan) could refer to the implementation of the template cache only. However, it would be good to know if pagefileExtendedPaths is a reliable option and I'm glad that you suspect that this is true.

It can definitely get a bit confusing when multiple topics are discussed in single issue or thread ? Anyway, template cache is a separate feature, and the files it creates are not stored under /site/assets/files/. In other words: pagefileExtendedPaths is a feature related to Pagefiles, and has no direct correlation with template cache files. The point here is that while template cache files can indeed suffer from the same limitation that resulted in the creation of the pagefileExtendedPaths feature, whether pagefileExtendedPaths is enabled or not has no effect on that. If you're worried about scalability on the filesystem level, you may indeed want to steer away from the template cache feature – but this problem only comes into play when you have tens of thousands of pages with template caching enabled (32k+ for ext3 filesystem, 64k+ for ext4, etc.)

@Lutz, note that pagefileExtendedPaths is all about /site/assets/files/, i.e. Pagefiles uploaded through the Admin or added via the API. What Soma and Ryan discuss in that issue is implementing a similar, but likely separate, feature for the files created by the built-in template cache feature (/site/assets/cache/Page/). In other words that discussion is not about an issue with pagefileExtendedPaths, but rather a suggestion to add another similar feature for a different purpose ?

I haven't used this feature myself, but for what it's worth this feature has been in the core for a very long time, and I haven't heard of any issues regarding it in years. As such, I'm pretty sure that the "beta" label is something you can safely ignore by now.

There is a honeypot option. There's a JS-based approach that goes back a long time... ...and a more recent addition... https://github.com/processwire/processwire/commit/8405c586f03a2a0a6271b5edd5ba9361f768da6a

Done! ?

Here's a couple of other projects that I looked at. I'm not sure if it is needed, but they include a couple of other directives as well. https://github.com/vincentorback/WebP-images-with-htaccess https://git.drupalcode.org/project/webp/blob/8.x-1.x/.htaccess from the Drupal 8 webp module https://github.com/nomidi/silverstripe-webp-image/blob/master/templates/SilverStripe/Assets/Flysystem/PublicAssetAdapter_HTAccess.ss for Silverstripe CMS https://github.com/S1SYPHOS/kirby-webp - for Kirby CMS I wasn't sure about this one: <IfModule mod_headers.c> Header append Vary Accept env=REQUEST_image </IfModule> Do you think something like that should be included?

Hi @Gadgetto, this looks great! I've played around with Snipcart and Foxycart quite a lot and then built my own solution (which was quite a pain as well ? ). Snipcart definitely looked best IMHO but it is also quite expensive. But it may be worth that price if we have a good working module that integrates well and saves us lots of time during development. Well... free sounds great ? No idea how much money one can make by selling a pro module to the community - I've never heard any numbers and there have been several discussions about that. So I'm not even sure if it makes sense at all to sell anything to the pw community. It's also more effort to setup some kind of selling process, api key verificaton etc. (well, maybe not for you now that you can use SnipWire for that ? ); I decided to release RockGrid free for example so that others can use it easily in their modules (didn't happen as far as I know), but I stated that extended support is not for free. But RockGrid is totally different. A shopping cart is of course much more mainstream and has a broader audience for sure. I could be a possible customer one day ?

I have played with a .htaccess only solution to serve WEBP instead of JPEGs or PNGs. This way you can - leave your existing template markup untouched, and the apache_rewrite will - detect if the browser supports WEBP - if a WEBP copy is available for a JPEG or PNG image. Locally it's working out nicely! ? This markup automatically serves a WEBP copy to all browsers that support it: $options = ['webpAdd'=>true, 'webpQuality'=>90]; $image = $page->images->first()->size(300, 300, $options); // this will create a 300x300 Thumb for JPEGs and PNGs with an additional WEBP copy ?> <img src="<?=$image->src?>" alt="<?=$image->alt?>" /> <!-- this will serve the WEBP image to all Browsers that supports it, and the JPEG/PNG to other browsers --> AddType image/webp .webp <IfModule mod_rewrite.c> RewriteEngine On AddDefaultCharset UTF-8 ### Redirect regular PW JPEGs and PNGs to their WEBP image copies, ### if available and if the Browser supports WEBP: ## Does Browser accept WEBP images? RewriteCond %{HTTP_ACCEPT} image/webp ## Is it an existing file? RewriteCond %{REQUEST_FILENAME} -f ## Does a WEBP copy exist for it? RewriteCond %{DOCUMENT_ROOT}/$1$2$3/$4.webp -f ## With an added GET var or GET value of skiprewrite we do send the original JPEG or PNG RewriteCond expr "! %{QUERY_STRING} -strmatch '*skiprewrite*'" ## With an added GET var or GET value from the PW Page Editor, we do send the original JPEG or PNG RewriteCond expr "! %{QUERY_STRING} -strmatch 'nc=*'" ## Is it a regular PW JPEG or PNG image, stored under site/assets/files? RewriteRule ^(.*?)(site/assets/files/)([0-9]+)/(.*)\.(jpe?g|png)(.*)$ /$1$2$3/$4.webp [L] </IfModule> Adding a GET var or GET value with the string "skiprewrite" added to an image bypasses serving the WEBP copy in favour for the original variation. (Maybe useful for debug purposes!)

@Soma Yeah this is my issue with Vue.JS - I use Vue.JS often for two way data-binding which is amazing to be able to easily update content and do visual changes to the site based on those updates. For example adding something to a basket. It's much easier with Vue than jQuery or JavaScript. My issue with Vue is exactly that. You can use it just on a component basis or you can use it to render your entire UI. To me it just doesn't make sense to use it to render an entire UI with a website. A web app sure, but a website it's often overkill and introduces that exact problem. You can introduce server side rendering of Vue with Nuxt but then it just seems like another layer of 'over complication'. I personally stopped using Vue for websites unless I absolutely needed two way binding. It just didn't make sense and the extra complication of implementing it such as having to convert everything from ProcessWire into a JSON feed. EDIT: Noticed this post still gets likes, so what's changed since then? AlpineJS. AlpineJS is a solution to this exact problem, worth a look for anyone wanting to do some cool UI stuff without including all of Vue features and overhead.