Leaderboard

ProcessWire added WebP image support this year and many have been adopting it enthusiastically in existing projects. In this post we’ll look at a process used for migrating an existing website to use WebP images. We’ll cover everything from preliminary considerations to implementation and testing, with lots of tips and tricks along the way— https://processwire.com/blog/posts/webp-images-on-an-existing-site/

https://www.comedywildlifephoto.com

Hey folks – a quick update: Wireframe 0.5.0 was released couple of days ago. Compared to 0.4.x this version mainly fixes bugs and improves performance – nothing particularly major, but if you're using Wireframe, it's a recommended update. On a loosely related note, Tracy Debugger has been really helpful in figuring things out, identifying bottlenecks, etc. Brilliant module ?

Hello folks! Recently we published a new website for Brightline, a Project Management Institute (PMI) initiative together with leading global organizations dedicated to helping executives bridge the expensive and unproductive gap between strategy design and delivery. The previous website was made in Hugo as in the beginning it was a very simple website, but as the business needs changed, I decided to build this version in ProcessWire. Nothing fancy occurs behind the curtains, the need was more on getting some data in a way that makes it easier to create reports and to give access to PW's great admin to another team member. For the other website, that you can see here, I didn't implement a CMS on top of Hugo because for me it was quicker to edit the files and push to the repository. Some content is still being copied but 98% is done. A quick list of modules used: - ProCache, FormBuilder, ProFields, SeoMaestro, PageHits, TracyDebugger, MenuBuilder, AutoSmush, and other custom ones. I'm biased, but there a lot of good and useful content created by us and also by partners and all is free to download. :)

You're right in that it's nearly impossible to tell which page to edit just from the URL. I think the only reliable way of getting the correct edit link is to render the admin bar server-side using wire('page'). No need to make it overly complex, I guess, by going the JS route. If somebody decides to do partial content replacement in their frontend, I feel like that's just something they have to take care of themselves by including the admin bar in the list of replaceable containers. The more I think about it, the more I feel like my case applies to that rule as well. If I want the links to force a full reload instead of a replacement, I need to configure my frontend accordingly. My only remaining gripe is probably the logout button that shouldn't be an anchor ? As far as I know, it wouldn't make a difference since most libraries don't care too much about accessibility and tend to define their own cancellation methods (data-no-turbolinks="true", etc.).

Thank you! The module is this one by @David Karich https://modules.processwire.com/modules/page-hit-counter/

@teppo Those are some good points. I agree the admin link itself and the edit link should stay anchor tags. Create, browse and logout, however, aren't semantically speaking links since they potentially have side effects (create, logout) or only trigger module JS (browse). There is one case that will create pages by merely following a link: when a template is configured to use the »Name format for children« setting in order to skip the page-add step. In that case, a new empty page is created every time the link is opened. I use that setting on most templates, that's probably why I noticed. The logout could be implemented using just a form and a submit button, using the form action for the logout URL. Not sure if ProcessWire currently supports custom redirect URIs after logout or if you might have to hook into the logout process for that. Turbolinks in particular switches out the whole body, but the problem here is that since there's no actual reload, stylesheets and scripts stay active on the page, so you mostly need to make sure that you don't cross between frontend and backend with any of these libraries, whatever part of the HTML they switch out. I've found a hacky solution by canceling any AJAX page visits if the URL matches the ProcessWire admin URL, but that means the frontend code needs to have a 3rd-party backend module in mind, which feels wrong.

Thanks for the feedback! Replacing <a> tags with buttons was originally on my list, but I've been pushing it back as there are some additional considerations here: There are some "proper links" (such as the admin link) that should remain that way. As such, this wouldn't apply to all links automatically. When the modal ("slide overlay" in module settings) mode is disabled, almost every item should be a regular link – except for browse, which technically shouldn't do anything there, as in that case it's just an indicator of your "current state". Admin Bar should work regardless of JavaScript. This makes it more robust, and as such more accessible. That last point isn't an argument against using buttons, just something to keep in mind when making changes: everything should remain functional regardless, which could mean links by default (when JS isn't available, or working as expected) and buttons otherwise. Since default styling is now based on BEM, it should make this easier in some respects, though; technically what element is used shouldn't matter anyway. I don't actually see (m)any notable issues in the current behaviour. None of the built-in Admin Bar features will create any content without user actually submitting a form – and I'd be very surprised if a plugin did that on itself. The logout link is problematic though, you're absolutely right on that one – I've added this on my todo list, but not entirely sure yet how to handle it. I'm not familiar with Turbolinks, but the way Barba.js usually works is that you define a container, which you then switch with new content. I'm not particularly experienced in this regard, but to my best understanding you wouldn't usually define your entire <body> element as a container, and since AdminBar attempts to place itself as the last element right before </body> closing tag, normally this shouldn't be an issue – though again, this is just based on my (quite likely lacking) understanding of such libraries ?

Anyone new to this module, please be aware of this unfixed issue: https://github.com/ryancramerdesign/ServiceCurrencyConversion/issues/1

@teppo I just installed the module but noticed all links are anchor tags, which is a bit problematic since these links can be triggered involuntarily by scripts or browsers prefetches. When combined with frontend link preloaders (e.g. InstantClick) or browser prefetching (e.g. Google Chrome Page Prefetch), this results in newly-created orphan pages or mystery logouts. Is there a way the module can be updated to use buttons instead? This would also make it work better with libraries like Turbolinks or Barba.js which intercept link clicks to load them via AJAX and switch out the response body. I'd gladly create my own theme to do that, but figure this is also a security issue, so it might be best to tackle this at the root level ?

It doesn't diminish your request, but Interestingly I have an issue where AOS actually causes a horizontal scrollbar to appear on desktop on some pages - as soon as I disable AOS it goes away. I haven't narrowed down the cause, but something worth thinking about in all this.

It's not that I think the PW admin isn't easy, but there are lots of scenarios where users don't need to edit site content in any big way and seeing the PW admin would confuse them more than anything. Like where your users just have an account so they can access a private "members" area, or view "premium" content, etc.