Leaderboard

Hey everyone! Fluency v2.1.0 has been released with new features and bugfixes. Translation cache now caches translations permanently until cleared on the module config page when translation caching is enabled. Some Fluency methods are now hookable. Refer to README for documentation and use case. Credit to @Hari KT for inspiring this feature. Globally excluded strings can now be entered either one per line or all on one line separated by a || (double pipe). Credit to @bernhard for the feature suggestion Translating static strings using the ProcessWire translator now offers the ability to specify the language code to be used for the source language Fix issue where strings configured to be excluded from translations on the module config page were being translated. Credit to @bernhard for finding and reporting Correct issue where custom language code field that may optionally be added to ProcessWire language pages was inconsistent and incorrectly documented. Fix missing localization strings for some errors Various small improvements, some bugs that had not yet affected regular usage Various housekeeping and code cleanup that only matters if you like reading the source 🤷‍♂️ Thanks all, and please report any issues!

@teppo Thanks and good ideas. CSS variables sound good to me too. But want to mention that this isn't a new admin theme, this is AdminThemeUikit with an improved look and feel. There isn't any change to the underlying markup or CSS structure. The AdminThemeUikit CSS is still present so folks can still use the original look too. Longer term maybe we'll do a whole new admin theme. This does actually feel like a new admin theme when you use it, even if it's technically not.

@ryan Makes sense. Really looking forward to seeing what y'all been cooking up! I paused the other day and appreciated all the quality of life improvements that have come over the years and value them as much as the big features. Almost can't wait. It's like Christmas for adults, who are also developers.

There is a long open issue for UIkit to support CSS variables but unfortunately there seem to be no efforts in that direction: https://github.com/uikit/uikit/issues/4534

Prompted by @ryan's recent enhancement of the page tree display, I wanted to display an alphabetical index of pages rather than a numerical one, so I built a hook after MarkupPagerNav::render. You can see the result here: https://ncorchards.co.uk/main/fruit-orchards/apples/ Basically the hook just replaces render() with a modified version. The key modifications are to select all the items without limit: $items = $event->arguments(0); //PageArray $itemSelector = $items->getSelectors(true); // true returns the string rather than the object $noLimit = preg_replace('/,\s*limit=-?\d+/i', '', $itemSelector); and then to modify the pager: $pagerNav = new PagerNav($object->totalItems, $object->itemsPerPage, $object->pageNum); $pagerNav->setLabels($objectOptions['previousItemLabel'], $objectOptions['nextItemLabel']); $pagerNav->setNumPageLinks($object->numPageLinks); $pager = $pagerNav->getPager(); $allItems = $this->find($noLimit)->explode('title'); $itemsPerPage = $object->itemsPerPage; foreach($pager as $key => $item) { if(!ctype_digit("$item->label")) continue; $index = (int) $item->label; $itemTitle = $allItems[($index - 1) * $itemsPerPage]; $item->label = substr($itemTitle, 0, 2); } If anyone wants the full hook code, let me know, but you will probably want to modify it for your own use anyway and the above are the key bits.

Season's Greetings ProcessWirers! I hope you enjoy the gift of this module, but use with care... TLDR: This module captures changes made in the development environment so that they can be easily migrated to the live environment without needing to specify the changes or write any code. The demo below gives a brief overview. Want to read? Read on. One of the (few) problems with ProcessWire, in my opinion, is the lack of any native way of handling migrations. Given that PW is such a powerful tool capable of sophisticated and complex web-based applications, this is less than ideal. There is a solution, however, in RockMigrations which accomplishes a lot in a controllable way, provided you are happy to specify your database set-up in code rather than via the UI (albeit that the latest versions allow you to grab much of the required code from the UI). If that suits your need, great. Around the same time as the first versions of RockMigrations, I started developing my own UI-based migrations module, which I have been using with reasonable success for some time. I halted development of the module for a while as RockMigrations developed and I considered switching to that route. However, I decided that my module suited me better and that a real improvement could be made if it was effectively automated so that I no longer needed to specify a migration. So that is exactly what it does: after configuring the module, you add a new migration page with ‘log changes’ enabled (which includes determining what types of objects are relevant for the migration) and work on your development system. Once you have made the desired changes (and tested them!) in the development environment, you go back to the migration page where it has magically captured the objects which have changed and listed them in dependency order. You then ‘export’ the changes, which creates json files to be uploaded to the live environment (via Git or FTP etc.), where they are then ‘installed’ to re-create the changes in the live system. The demo below illustrates this briefly. This first demo shows the creation of a migration. The installation demo will be in the next post, because of size constraints. See post 4 for HD video. Video-source small.mp4 There is a very extensive manual which covers all the features of the module, not just this ‘automatic’ method. Available on github at https://github.com/MetaTunes/ProcessDbMigrate and in the modules library here. PLEASE NOTE that this is still in 'alpha'. Do not use in production without fully testing and backing up at every stage. It is quite complex so, although I have tried hard to eliminate bugs, there will inevitably be some left!

Work continues on the new processwire.com website. I’ve nearly finished developing most of the modules directory this week and next week will be working on the development side of the API reference and sites directory. Some more good news to share is that when the new site launches, the new admin look and feel will launch as well. The website and admin share a similar design language in some areas, and I’m confident you will love them both. When we use screenshots of ProcessWire in the new site design, they will be from the new admin look and feel. It is still admin AdminThemeUikit, but with a new face that is beautiful, modern and professionally designed. I’ve been using for more than a week and it’s fantastic in my opinion. If for some reason you end up wanting to keep the current look of AdminThemeUikit (perhaps a client doesn’t like change), it will remain as an option too. If you are extending AdminThemeUikit or using the admin.less feature (developed by Bernhard) to custom style the admin, all of that will continue working too. What will likely be changing is that we’ll be moving the older AdminThemeDefault and AdminThemeReno out of the core and into the modules directory. I’d rather keep the core efforts focused with AdminThemeUikit, but continue to support the older admin themes as installable options. Prior to this, most of what you’d seen in ProcessWire’s core admin and website has been designed by me (excluding AdminThemeReno). And I haven’t worked full time as a designer since 2005 or so. If I ever had any site design skills, they are long gone. So PW has always had a “designed by a developer” look. Having professional designers take over the design of both the admin and the website just feels like a major upgrade to ProcessWire all around. More than I could have guessed. I look forward to when I can share the new site design, admin look and feel, and the designers with you. Thanks for reading and have a great weekend!

First you need to make sure to get the value of the page reference field as PageArray (not a single page object or such). This might depend on your setting of the field and whether output formatting is turned on or off (in the hook it should be off, but just in case...). As ->removeAll() works it should be a PageArray in your case. In my case the field is called "pagelink" and I force the return type to be a pagearray via [] Then from the pagearray you can remove your page via remove("id=...") which is all you need I think

Hi Bernhard, thanks for your reply. Right now I'm involved in different jobs. As soon as I'm finished, I'll continue with my tests and let you know.

Thank you for all your work on this great module!

Publish it as a gist on Github or in case you are interested write a full recipe and publish it on processwire.recipes.

Have you changed the variable “$config->httpHosts” in your config.php so that it contains your local url?

Do you have the same userAuthSalt in config.php? If you change that (or it does not exist) you'll not be able to use the same password. You can also reset/force-login like this: https://processwire.com/talk/topic/29593-solved-do-the-reset-password-tricks-work-for-you-they-dont-work-for-me/?do=findComment&comment=239355 But it would be better if you understand why it does not work and then fix it if needed 🙂

I've decided to just create a custom module for this functionailty, still have no idea what the white page is all about though.

Wow. No, I’m sorry that I seem to be writing so unclearly. When you write: you are correctly describing the current situation. --- The whole point is that I want to open the system up for users around the world — regular people — who will be setting their preferences, creating public user profiles, tagging things privately for their own use, storing private notes. All using front-end forms and (probably) htmx. Because servers occasionally go down and people sometimes travel, I need this data to be on all the servers.

I think this approach is an excellent idea and hopefully something that will be considered. In addition to the benefits @teppo described, using CSS really open things up for JS as well where getting/setting values via scripts could make admin development very dynamic. Laying some future friendly groundwork in CSS would be a major advancement.

Hey @neophron RockFrontend doesn't change the _main.php file. I guess you mean the RockFrontend Site Profile?! Whatever. As I told you at the very beginning you need to remove all styles() and scripts() calls and add assets manually. How you do that is up to you. You can either add the script/style tags manually to your main markup file or you can use RockDevTools. It's really up to you. But unless you remove all styles() and script() calls your system will not work and is not expected to work. There might be some inconsistencies with the site profile or other references to that old concept. I'm sorry for that and I'm trying my best to remove all those outdated informations. For that it would help to get the exact steps you took to get where you are. I understand that this might be frustrating, but please also understand that it is frustrating for me to try to help but don't get proper information and searching in the dark for issues that I don't see. What is that status on your end? Did you get it working already? What did you try to make it work? I'm very busy until end of next week so it would be nice to get an as detailed report as possible. Alternatively I can offer you that you send me your project and I set everything up so that it works.

I don't think there is a coupon code for the ProFields, at least I'm not aware of one. But with your purchase you are supporting Ryan, the developer of Processwire.

Imagine you have a multisite setup where you need different languages for different domains: One website might be single-language (DE only), another one might need DE/EN/CZ, and another one might need DE/EN/HU: I didn't know how to do it, and I didn't find any other posts with a similar need or solution. When looking into the code I even thought that my need was not possible yet without modifying a core file. So I asked Ryan if he was willing to make the process of adding languages to the $languages array hookable. Turns out that this is not necessary! All you have to do is to grab the Iterator of the languages array and remove languages as you need: // /site/ready.php if($anyCondition) { // remove CZ language $languages->getIterator()->remove("name=cz"); } So simple 😍 Maybe it helps 🙂