Leaderboard

The plan was to merge dev to the main branch today, but I’m still working through a couple of GitHub issues that I’d like to resolve or finish the conversation before finalizing the 3.0.244 main version. One example is this issue report where it was pointed out that there are some issues with UTF-8 page names. ProcessWire uses PHP’s IDN functions to manage conversion to and from the non UTF-8 version of the URL. PHP 7.4 changed the default arguments of the idn_* functions to settings that made them not work 100% for page names in a few cases, which I didn’t realize before this week. But this is not an issue that I can just fix and be done with it… There may already be page names in any given installation that are affected by the post PHP 7.4 behavior. If I were to just fix the issue, then some affected pages might no longer match when accessed directly by URL. So this had to be a carefully considered fix. What I ended up doing is fix it for any new PW installations that occur after this weekend. PW keeps track of its installation date, so can do this by way of its $config->installedAfter(“2025-01-05”) function. Existing installations will keep the imperfect behavior. Presumably it doesn’t affect that many installations since it only came to light last week and PHP 7.4 was released roughly 5 years ago. Nevertheless, existing installations that want the “fixed” behavior can get it by specifying this in /site/config.php: $config->pageNameWhitelist = 'v3' . $config->pageNameWhitelist; That essentially says to use version 3 of the page name conversion. Version 2 will also work fine, but may be slightly slower since it uses a dedicated Punycode library. And version 1 is the one that worked correctly until PHP 7.4, and still works mosts most of the time, but can produce imperfect results in some cases. Installations prior to 5 Jan 2025 use v1 by default and installations after 5 Jan 2025 use v3 by default. Chances are few (if any) will want to specify the version manually like above, but the option is there, just in case. That’s one example of why I’m waiting another few days before the dev branch merge to main. Another is that Adrian mentioned double-clicking on the “Move to Trash” button [in the page editor] makes it permanently delete the page rather than trash it. While I can’t duplicate that, despite multiple attempts, I just want to make sure there’s not something that needs fixing there. But unless any major new issues turn up, by this time next week we’ll merge to main and bump the version to 3.0.244. Thanks and Happy New Year!

FrontendLoginRegister module is updated now (Version 1.3.6) The following last 2 issues have been fixed now: Support for usage of multilanguage fields inside user template added New configuration field to make the "Request deletion of user account page" public viewable added Screenshot of the new configuration field to change the access of the user account deletion page: In the middle you can see the "Allow public deletion of a user account" checkbox. If you check this checkbox, the deletion page will be public reachable. For more information check the changelog.md. Please keep in mind! This module is Beta stage, so it is not recommended to update live sites without testing it locally before! I have tested various scenarious, but I cannot test all possible cases - so happy testing 😉 As always, please report any issues here or on GitHub.

The following issues should be solved now: The position of the privacy check is now always at the bottom, regardless of the use of a CAPTCHA (bug fixed) New configuration field to select whether to use an internal or external page for the privacy policy added. This configuration supports multilingualism, which means you can select a different page for each language. These issues have been fixed in the FrontenForms module and not in the FrontendLoginRegister module. This means that you will need to update the FrontendForms module to the latest version 2.2.27 to fix these issues. The other problems (public deletion link, multilanguage user fields) directly affect the FrontendLoginRegister module and must be solved there. I will try to solve these issues in the next time. You can read the full documentation of changes in the changelog.md. Hope it works now as expected without problems!!

@FireWire @Jonathan Lahijani @gebeer I've created a demo module that shows how to use the new config migrations. Please note that it needs the latest RockMigrations version from the dev branch! https://github.com/baumrock/ConfigMigrationsDemo

Hello, Because I was in need of such a thing but there was nothing that I could find, I had to create my own. I'm sharing here, so maybe someone will find it useful. My second module, Use at your own risk, there may be some mistakes, please if you find them, let me know! Right now the module mostly works with datetime field!!! This was what I was going for actualy. Description Page Automation Module for ProcessWire Description: The Page Automation module automates various page management tasks in ProcessWire, such as copying, cloning, deleting, publishing, hiding, and more based on predefined conditions. It allows users to set triggers based on a page's field values and perform automated actions without manual intervention. The module integrates with LazyCron for scheduling periodic checks. Key Features: Perform actions like copy, clone, delete, publish, hide/unhide automatically. Configure conditions based on date/time fields (e.g., "older than 1 day"). Schedule actions with flexible cron intervals (every minute, hour, day, week, or year). Supports applying actions only to pages using specific templates. Option to assign a different template to cloned/copied pages. Logs all automated actions for easy tracking. Requirements: ProcessWire 3.x or later. LazyCron Module (it won't work without it). Setup Instructions: Install the module through the ProcessWire admin Modules upload by File upload. Configure the conditions, templates, and actions via the module settings. (Optional) Install LazyCron for time-based automation. Verify that the automation_processed checkbox field is automatically created for tracking processed pages. Once configured, the module will automatically handle repetitive page management tasks based on your specified conditions, saving time and effort. Important! Uppon install the module will create a new field "automation_processed" which you must add to the main template (template for action or make it global), if not you'll end up with a bunch of copies. This field tells the module that the page was already proccessed, so it will leave it alone. PageAutomation_preview.mp4 I hope u like it 😉 You can download it here: PageAutomation.zip

Thanks for the additions, great work!

@modifiedcontent: I, too, use MariaDb on Vultr servers with no problems whatsoever. But I think that @Jonathan Lahijani is asking about Vultr’s managed databases. I’m afraid I have no experience with those, so I can’t weigh in profitably. Have you used those?

Thanks @bernhard! After shutting down the pc yesterday I got the cause. All pages without news template do not have a saveReady-hook. So for renewing pagenames on pages with other templates I simply have to temporarily create a new hook to set the pagename for other templates, too. Without the prepended news-published-day. Seems to work!☺️🙏🙋‍♂️

Thanks! I'll have a go with that, though I did manage to get the inbuilt PW date translation to work. I had been using date() but realised i need to use $datetime->date() (as well as put translations in the WireDateTime.php file) Oooh actually I need ranges too so HumanDates will be very useful. Cheers!

Since my post I've also used Vultr for a client and have been very happy with it. The signup and server configuration process is nice and I'm glad I am moving away from DigitalOcean. I have a better long term feeling with them.

Needed this today while working on RockGrid. Realised that the version above attaches an event listener for every created link but doesn't remove it later. So I improved this by listening on the "pw-modal-closed" event on the $link instead of the $(document). This didn't work at first, but I found out, that the culprit was that I instantly removed the $link after it has been clicked, so obviously there is no element any more to listen for the event. After moving the $link.remove() in the modal closed callback it worked as expected. Here is the updated function that I use in RockCalendar: const openInModal = (href, options = {}) => { // merge options with defaults const defaults = { calendar: false, autoclose: true, buttons: "button.ui-button[type=submit]", }; const opts = { ...defaults, ...options }; // create a fake link element in body let link = document.createElement("a"); let $link = $(link); $link.attr("href", href); $link.addClass("pw-modal rc-link-remove"); if (opts.autoclose) $link.attr("data-autoclose", ""); if (opts.buttons) $link.attr("data-buttons", opts.buttons); $link.on("click", pwModalOpenEvent); $link.on("pw-modal-closed", () => { if (opts.calendar) opts.calendar.refresh(); $link.remove(); }); $link.click(); }; A different approach is to add a second button (save + close) to the modal:

Sure 🙂 You can have a Look at this thread:

@ryan and @ all of those reading this... https://hugerte.org/ "We've forked the last MIT-licensed commit of the popular TinyMCE WYSIWYG editor as they switched to a GPL-or-pay license model and we want to keep it free for everyone. We're working at improving the codebase, adding new features and fixing bugs"

@zoeck Being physically able to do something is not the same as legally/ethically being able to do something. I haven't found the license that pro modules are provided under, but Ryan makes it clear they are not open source, so your rights are unknown. Common sense says that I'm quite sure he doesn't mind anyone making changes to their local copy but that I'm quite sure he would mind if someone started sharing the code/modified versions of it, or even selling it! My interest in open source code is primarily sustainability - code that is openly shared/forked, has good leadership as part of an active team of developers, welcomes contributions. A closed product only exists as long as it is in the interests of its owner. If Ryan, God forbid, were to have a change of fortunes/interests, and shut shop, the open source code could be picked up by an interested community of developers and all our websites and services based on PW stand a chance of a future. The closed source products could not - legally - be continued. My biggest reservation in using ProcessWire is the business risks posed by its BDFL model / single point of failure in general and moreso with the pro modules. My interest in this forum post, however, was just how to give Ryan a modest donation to help fund his excellent continued work! I'll try reaching out directly/via contact-form on website as @Krlos suggested.

I totally get where you’re coming from and appreciate your support for open-source values. Personally, I keep renewing my Pro module membership even when I don’t need the new features. For me, it’s a way to back Ryan for all the amazing work he does. Plus, having access to support has been a lifesaver a few times when the forum couldn’t help. Maybe reach out to Ryan directly through the ProcessWire website to see if there’s a way to donate. I’m sure any support would go a long way for the project! Another idea could be setting up something like a Patreon or similar platform where the community could collectively fund updates to specific modules or even new features that aren’t currently on the ProcessWire roadmap. That might be a cool way for everyone to contribute in a more focused way!

You can also do this with the Pro modules. They are just PHP scripts like other modules. And you get access to the internal support forums of the corresponding pro modules. Of course you can also just buy the modules and not use them to support Ryan 😉