Leaderboard

This week I've added support for File Regions, part of the Markup Regions output system in ProcessWire. File Regions enable you to populate CSS and JS files with Markup Regions. I'm short on time today, so rather than writing much about it here, I've put up a documentation page for it in the API reference, which I'll link below. I'm using File Regions on a project right now and am finding it to very useful. Especially on a project where there are multiple developers, it simplifies a lot to be able to build features as self contained components, while still using the traditional route for site-wide stuff. It's something different, and I'm curious to know what you think. Here's the new documentation page for File Regions below. The page was a bit rushed, so I'll likely be amending it, but hopefully it gets across the main ideas. Thanks for reading and have a great weekend! https://processwire.com/api/ref/wire-markup-file-regions/

Hi @monollonom, thank you for posting the thread. Editing the language section is the more easy part when changing the default language. If you have plenty of multilingual content, then it gets hard eventually. Therefore, having such a good starting point thanks to @gebeer , e.g. his php script to swap content of language tabs,- this whatever makes it worth the effort. I mostly work on multilingual sites/projects, so this affects me regularly,- its a pity PW doesn't handle this more smoothly. Like other CMF do.

@ryan looks amazing to me. I use region("gallery", true) or similar in repeater matrix files and then do some logic in _main.php currently. Guessing this could replace that, or do markup regions not look that deep within repeater matrix template files?

Finally getting onboard with .env now I have a project where the same installation is getting rolled out multiple times and I don't want any accidents (I've excluded config.php on Github but still it could happen if I get careless and we pull in a lot of other API keys) - this was the missing piece of the puzzle for me so thanks @FireWire! 🎉

I have created an issue about the same bug a few hours ago: https://github.com/processwire/processwire-issues/issues/2160

This week on the core dev branch there are several new hookable methods added to the Page class. While many of them may be redundant with hooks already available on the Pages class, those on the Page class are more convenient to use in some cases, especially when it comes to using custom Page classes. It's helpful because you can hook CustomPageClass::method rather than Page::method to more easily target specific types of pages. Or you can override the methods in a custom page class, without having to hook them at all. I'll get into this with more details and examples in a future blog post that goes in-depth on using custom page classes. Here's a summary of the methods that were added with links to their API reference documentation pages: Page::addReady() Page::added() Page::addStatusReady() Page::addedStatus() Page::removeStatusReady() Page::removedStatus() Page::cloneReady() Page::cloned() Page::deleteReady() Page::deleted() Page::editReady() Page::moveReady() Page::moved() Page::renameReady() Page::renamed() Page::saveReady() Page::saved() Page::renderPage() The above is just for this week, but there's quite a bit more in 3.0.253 relative to 3.0.252, so be sure to check the last issues from ProcessWire Weekly for more details.

Good day, whoever needs this years later) This trick for hook is obsolete after the newly introduces Page::renderPage hook (see here). That is great, but it does break the old way of getting page with the line quoted above. Change the code to something like this: wire()->addHookBefore('Page::renderPage', function (HookEvent $event) { $page = $event->object; ...