Leaderboard

The new dev branch version 3.0.222 contains about 20 commits and 16 issue resolutions. In terms of new features, last week I mentioned some upgrades to WireHttp, and below are this week's additions: Multi-language month and day names The WireDateTime class (aka the $datetime API variable) has been updated to support multi-language month and day names. Now all month and days are translatable in the WireDateTime file (/wire/core/WireDateTime.php). So if you request any date in a format that uses month names or abbreviations, or day names or abbreviations, they now support multi-language, whether you requested it from the wireDate() function or the $datetime API variable. ProcessWire has long supported multi-language month and day names when using a PHP version prior to 8.1 and you've requested a strftime date format that uses them. But PHP 8.1 dropped the multi-language supporting strftime() function, without leaving a suitable replacement. PHP's IntlDateFormatter can't be relied upon since it's not always compiled with PHP. But as of PW 3.0.222, now we have a suitable replacement. Though it does require you to translate the 7 days and 12 months for file /wire/core/WireDateTime.php using ProcessWire's language translation tool. Note that unlike the previous strftime() solution, the new solution no longer requires you to use strftime() format codes and you can instead use regular date formats and they will be translated automatically. New conditional hooks that match by argument type Another new addition this week is support for conditional hooks that match by argument type. I think this is especially useful combined with ProcessWire's custom page class support. It enables you to make a hook apply only to methods containing arguments of a specific type. For instance, if you had a custom page class "ProductPage" for template "product" and you wanted to capture the "Pages::saved" event for pages of that type (ProductPage) you could do so like this: $wire->addHook('Pages::saved(<ProductPage>)', function($event) { $product = $event->arguments(0); /** @var ProductPage $product */ $event->message("ProductPage '$product->title' has been saved"); }); In addition to supporting class or interface names, you can also specify regular PHP types such as <array>, <string>, <int>, <object>, etc. For more details on this type of hook see the new Conditional hooks that match argument type section of the Hooks documentation. Thanks for reading and have a great weekend!

RockShell v2.0.0 is out. It's been in development for quite a long time and I use it on a daily basis. This module is a little special, as it has to be placed in the PW root folder (not in /site/modules). From there you can then call the shell interface via "php RockShell/rockshell" You can then use the "symlink" command to create a symlink in the root folder. After that you can call rockshell via "php rock" in the pw root folder. I've made it as easy as possible to create custom commands - you only need one config() and one handle() method! https://github.com/baumrock/RockShell/

There’s also this really good tutorial on how to achieve a customizable cookie notice with plain JavaScript using the dialog element: https://www.thomasvantuycom.com/writing/simpler-cookie-notices/

The ProcessPageList.js is pretty complex and there are things in it I don't understand. I had to do some some rather hacky stuff to get the module working, but the stakes are lower in a module because each person can decide if they want the functionality and are willing to install a beta module to get it. Whereas if I make changes to the core in a PR it might break something for everyone. So I'll wait a while to see if any issues crop up before considering a PR.

This is one of the rare things that are not instantly intuitive to I guess 99% of my clients! Have you considered adding a PR @Robin S ? Imho that's really an essential feature, thx for creating and sharing it! Just added it to RockMigrations default profile ?

As a free solution for ProcessWire I would definitely recommend PrivacyWire. In my opinion it is the only viable solution at the moment. When that's not an option or more automation is needed, we tend to use Cookiebot. It's a paid service (they do have a free tier for small scale and limited requirements), but there are a few things that can make it worth the cost: It scans the site (as you mentioned) automatically and creates a list/table of used cookies, as well as identifies any cases where cookies are set without prior consent. At least here in Finland a list of cookies used on a site — including whether they are first or third party cookies, what they are used for, and for how long they are stored — is required. While one can of course keep such a table up manually, well... let's just say that especially for large and media-rich sites it's a whole lot of work. It has an automatic block mode that at least tries to automatically prevent the browser from loading anything that can set cookies. With PrivacyWire (for an example) you'll have to modify the markup of embedded script tags, iframe elements, etc. in order to load them only after consent has been given. It automatically generates and stores per-user consent history. At least here in Finland that is a necessary thing — site owners must be able to produce proof that the user has indeed given consent to storing data, and a separate registry is a must (said proof has to be available even if the user has cleared their cookies, localstorage, etc.) With paid plans it is very customizable. For an example we use a modified version of generaxion/cookiebot-accessible-template, since many of our sites need to be accessible. There are other services that do similar things, and I believe that some are cheaper than Cookiebot, but I have not had a chance or any need to properly dig into said other services. I'm only familiar with official guidelines and legislation as it has been implemented here in Finland, and also IANAL. Even with GDPR the actual implementation (and how that implementation is interpreted by officials) can vary from country to country ?

Thanks, hope this module gets included in the PW-core.

Page List Auto Expand Automatically expands the next adjacent page when moving a page in Page List. Usage As you are moving a page in Page List, if you position the yellow move placeholder above a Page List item for a configurable period of time (default is 1000 milliseconds) then that item will expand, allowing the moving page to be dropped as child page. Configuration In the module config you can set the delay before the Page List item adjacent to the move placeholder will be automatically expanded. Restricting the module to certain roles If you want to restrict the module functionality to only certain roles then create a new permission named page-list-auto-expand. If that permission exists then a user's role must have that permission or the module will not have an effect in Page List. https://github.com/Toutouwai/PageListAutoExpand https://processwire.com/modules/page-list-auto-expand/

@Ivan Gretsky that's genius! Thanks.

I'm not sure about text fields in combination with operators. Maybe you try a float field. But in general i would recommend to use a search index field: look here

Did you possibly use the v1 of the skyscraper profile? This is the more current (2016) one here: https://github.com/ryancramerdesign/skyscrapers2

Thanks everyone for the useful replies. There's lots to go through, it's all very helpful thanks. PrivacyWire looks very interesting and also easy to implement. I also like the look of https://github.com/orestbida/cookieconsent#how-to-blockmanage-scripts as it looks like you can accomplish the same thing independent of the platform (I have a lot of legacy sites that aren't PW). I think that will suit most smaller clients. Cookiebot looks reasonably priced and seems to have all the features so I suspect my bigger clients may go or this. Thanks everyone!

Hey, @mel47! Here is the code for the method. Seems like the 3rd parameter is to override default field value, not to provide additional variables to the template: @param mixed|null $value Optionally specify value to render, otherwise it will be pulled from this $page. Did not try this, but you probably can do this to have additional variable in the field template context: // main template $page->$sizeColumn = 2; $content .= $thanks_page->render('images', '/images_column'); // images_column.php foreach($value as $image) { echo " <article class='column is-{$page->sizeColumn}'> .... }

We'll what to say here ? Documentation depends on individuals who want to spare time and contribute. If something is not documented yet you can find it mentioned in threads, blog or just by looking for classes in the core. These threads can help you out what you are looking for: https://processwire.com/talk/topic/3145-multiple-views-for-templates/page-2#entry32876 https://processwire.com/talk/topic/4367-using-page-renderoptions-and-template-cache/ https://processwire.com/talk/topic/1102-to-render-or-not-to-render-thats-the-question/ http://www.flamingruby.com/blog/mapping-processwire-page-render-process/ https://processwire.com/talk/topic/1946-page-render-isnt-generating-the-same-output-as-viewing-a-page/ https://processwire.com/talk/topic/5394-page-renderfilename-confusion/ Camilo Castro documented and explains here how his wire render pattern works: https://medium.com/@clsource/the-wire-render-pattern-806bf6d6097a#.jquhbxejn https://github.com/NinjasCL/wire-render-pattern https://processwire.com/talk/topic/11199-mainphp-inflexibility/ https://processwire.com/talk/topic/11836-wirerenderfile-on-child-pages/