Leaderboard

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!

... but it feels like home.

@wbmnfktr It's funny that you say that, because this is exactly what I told the designers the first time I saw what they did with the admin theme. I told them that what they did with ProcessWire feels like home. Not just home, but a nicer and more modern home. 🙂

Hey @FireWire and @noodles I have a present for you: v1.6.0 now supports custom fields/values for recurring events. All you have to do is to add the field you your events' template and then tell RockCalendar to "keep" it: wire()->addHookAfter('RockCalendar::keepFields', function ($event) { $fields = $event->return; $fields[] = 'booked'; $event->return = $fields; }); See the full docs here: https://www.baumrock.com/en/processwire/modules/rockcalendar/docs/recurring/#custom-fields-for-recurring-events

Hi All! Specs: Processwire [3.0.246] RockFrontend [5.1.0] RockMoney [3.0.2] RockMigrations [6.7.1] PHP 8.3 MySQL server with InnoDB engine Subdomain ( configured via DNS point to subfolder of public_html, works as expected ) I’ve been trying to install RockCommerce on a fresh install, but the installation fails caused by a timeout, With RockMigrations From v6.6.0 and onward the site gives a timeout error when trying to install RockCommerce. With RockMigrations From v6.5.0 the site doesn’t timeout but gives a error: ModulesInstaller: Unable to install module (RockCommerce): Can’t save page (id=0): /discounts/: It has no parent assigned This setup partially installs the module for later gives me this: ProcessWire: ProcessModule: Can’t save page (id=0): /discounts/: It has no parent assigned DEBUG MODE BACKTRACE ($config->debug == true): #0 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/core/Pages.php(841): ProcessWire\PagesEditor->save() #1 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/core/Wire.php(419): ProcessWire\Pages->___save() #2 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/core/WireHooks.php(968): ProcessWire\Wire->_callMethod() #3 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks() #4 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/core/Page.php(2418): ProcessWire\Wire->__call() #5 /home/u855151783/domains/big-in-fabric.be/public_html/merge/site/modules/RockMigrations/RockMigrations.module.php(1101): ProcessWire\Page->save() #6 /home/u855151783/domains/big-in-fabric.be/public_html/merge/site/modules/RockCommerce/RockMigrations/afterAssets.php(6): ProcessWire\RockMigrations->createPage() #7 /home/u855151783/domains/big-in-fabric.be/public_html/merge/site/modules/RockMigrations/RockMigrations.module.php(4267): require('/home/u85515178...') #8 /home/u855151783/domains/big-in-fabric.be/public_html/merge/site/modules/RockMigrations/RockMigrations.module.php(4298): ProcessWire\RockMigrations->runConfigHooks() #9 /home/u855151783/domains/big-in-fabric.be/public_html/merge/site/modules/RockMigrations/RockMigrations.module.php(3524): ProcessWire\RockMigrations->runConfigMigrations() #10 /home/u855151783/domains/big-in-fabric.be/public_html/merge/site/modules/RockMigrations/RockMigrations.module.php(4172): ProcessWire\RockMigrations->migrateWatchfiles() #11 /home/u855151783/domains/big-in-fabric.be/public_html/merge/site/modules/RockMigrations/RockMigrations.module.php(5656): ProcessWire\RockMigrations->run() #12 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/core/WireHooks.php(1094): ProcessWire\RockMigrations->triggerMigrations() #13 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks() #14 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/modules/Process/ProcessModule/ProcessModule.module(389): ProcessWire\Wire->__call() #15 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/core/Wire.php(413): ProcessWire\ProcessModule->___execute() #16 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/core/WireHooks.php(968): ProcessWire\Wire->_callMethod() #17 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks() #18 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/core/ProcessController.php(361): ProcessWire\Wire->__call() #19 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/core/Wire.php(413): ProcessWire\ProcessController->___execute() #20 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/core/WireHooks.php(968): ProcessWire\Wire->_callMethod() #21 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks() #22 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/core/admin.php(174): ProcessWire\Wire->__call() #23 /home/u855151783/domains/big-in-fabric.be/public_html/merge/site/templates/admin.php(18): require('/home/u85515178...') #24 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/core/TemplateFile.php(328): require('/home/u85515178...') #25 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/core/Wire.php(413): ProcessWire\TemplateFile->___render() #26 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/core/WireHooks.php(968): ProcessWire\Wire->_callMethod() #27 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks() #28 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/modules/PageRender.module(581): ProcessWire\Wire->__call() #29 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/core/Wire.php(416): ProcessWire\PageRender->___renderPage() #30 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/core/WireHooks.php(968): ProcessWire\Wire->_callMethod() #31 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks() #32 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/core/WireHooks.php(1094): ProcessWire\Wire->__call() #33 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks() #34 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/modules/Process/ProcessPageView.module(193): ProcessWire\Wire->__call() #35 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/modules/Process/ProcessPageView.module(114): ProcessWire\ProcessPageView->renderPage() #36 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/core/Wire.php(416): ProcessWire\ProcessPageView->___execute() #37 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/core/WireHooks.php(968): ProcessWire\Wire->_callMethod() #38 /home/u855151783/domains/big-in-fabric.be/public_html/merge/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks() #39 /home/u855151783/domains/big-in-fabric.be/public_html/merge/index.php(55): ProcessWire\Wire->__call() #40 {main} It might still timeout after this, but atleast it return a proper error. I’ve tried pretty much all possible combinations of RockMigrations, RockCommerce 1.0 and 1.1 but to no avail 😞 Does anybody have any clue as to why this is happening? Any help would be greatly appreciated! 🙂 Grtz Bram

Hello everyone! 🙂 I’ve been using ProcessWire for well over a decade now, so I've been reading here forever, but never actually posted! I recently launced simplesignature.email and once again was delighted how great ProcessWire works for me, so I decided to share this one here! We’re a creative duo (Michael, and Stefan) from Switzerland working at and for many creative and branding agencies over the years. One thing often comes up: we need to create consistent email signatures for our clients. After trying many unsatisfying solutions, we decided to build our own. Goals: Clean, very minimal and easy to use, targeted mostly at designers Work reliably across email clients Possibility to easily share a signature with team members or clients Free of the common issues (PNG logos, font inconsistencies, broken layouts) So we built Simple Signature! Technical Stuff / ProcessWire Architecture Each user gets one ProcessWire page that stores all their signature configurations as JSON We bypassed ProcessWire's user system for a simpler magic link authentication (most users don’t need to login) Technical Features Client-server synchronization with signature configs stored in localStorage first and then pushed to the server, with debounced synchronization to do this efficiently Pure vanilla JavaScript with modular components for real-time preview rendering Server-side image processing using Imagick for different image shapes (circle, square, rectangle) “Business” Model Free for individual use (one signature) Pro plan enables multuple signatures and sharing them via a link - useful for agencies creating signatures for clients Simple Lemon Squeezy checkout overlay integration for payment processing While we’re not primarily revenue-focused - we built it for our own needs and as a free tool – a few paid users might help support operation and hosting costs for free tier Let me know if you happen to have a use for Pro features – happy to send you a discount code! Third Party Modules used: MarkupCloudflareTurnstile to make sure users requesting to create a login magic link are human WireMailSmtp to send emails As primarily a frontend developer, I found ProcessWire to be (again!) the perfect backend solution for this project, even without extensive PHP experience. It’s just super flexible, easy to use and robust. Visit simplesignature.email/signature-editor/ to see the tool it in action. Happy to answer any questions! Best, Michael

Boy howdy, I'm pretty excited to see this.

To dump my thoughts here: What's the main goal? Or ... What's the reason you need an off-site user management system? How real-time does it need to be? Putting everything on one server (#1) would be perfect as you then could bootstrap ProcessWire into other instances quite easily and go that route - which actually would be #4 - but you would lose those juice ms on each request you already mentioned. Ideas #2 and #3 sound fun but yes, probably total overkill. Never used or tried those, so no idea how well that would work out at the end here. #4 as mentioned would probably need all sites/instances on one server as well. Not sure if and how you wouild do this across multiple serveres. But here comes idea #5: Get a server that's somewhere in the middle and build a your user management there. You then could put an API on top with either your custom code or something like the AppApi module and roll your own auth for some or all users. Probably a bit overkill as well, yet another approach could be some kind of API to sync accounts from and to that server. Trigger actions via webhooks in case new users were added or removed somewhere. Could be fun. Could be pain. Not sure for now.

Perfect!!! This will make everyone's dreams come true 🙌 I have been looking forward to spending more time with RockCalendar. I've just had to prioritize things according to client needs so I've had to put that feature on the back burner but can't wait to work with it. It's such a relief to know that there's a quality modern module to handle this feature. Well done and many thanks! Note: It double posted for some reason, but this is the better comment 😆

Perfect!!! This will make everyone's dreams come true

I tested it. Works great. Thank you very much! I merged it with my adjustments. Maybe you’d like to take another look at it sometime. But for now, I think I’ve bothered you enough. 😄 RRule "byhour" extension Problems with multilanguage websites and PagePaths module: I am happy to provide my dirty code, if you'd like so. 😉

Ha! That's awesome! Thank you very much!!!

Of course it is! 🙂 Let's focus on appointments rather than events. In my case, I create a series of appointments: every weekday from 10 AM to 7 PM, every hour, until June 30th. People can book an appointment in my online calendar. Once booked, the appointment needs to be marked as "booked" so my client and his clients can see that it is no longer available. My initial idea was to add a checkbox field to the appointment template. This checkbox would be automatically checked when an appointment is booked. If an appointment gets canceled, my client could manually uncheck it, making the slot available for booking again. However, I realized that this approach conflicts with the concept of recurring appointments since they are inherently identical. That said, I forgot to update my post yesterday! 🙂 Here's what I ended up doing: Instead of modifying recurring appointments directly, I took a more straightforward and compatible approach. When an appointment from the series is booked, I delete that specific instance and create a new single appointment via the API. This way, my client can still modify the checkbox if needed, and the appointment time is kind of "extracted" from the recurring series. I think that's way cleaner than my previous idea.

See my post re the context Now that I know the cause, my solution is to build a selector that always operates on the DB, by merging the user's selector with the one that was used to generate the Page Array: /** * Find the first generation of children that matches the given selector. * * This method traverses the children of the given parent page, generation by generation, * and returns the matches in first generation that has matches for the provided selector. * * @param Page $parentPage The parent page whose children are to be searched. * @param string $selector The selector to match against the children. * @return PageArray Returns a PageArray of the first generation that has matches, or an empty PageArray if no matches are found. */ public function findFirstMatchingGeneration(Page $parentPage, string $selector) { $currentGeneration = $parentPage->children(); $count = 1; while($currentGeneration->count()) { $currentSelector = $currentGeneration->getSelectors(true); $matching = $this->pages()->find("$currentSelector, $selector"); if($matching->count()) { return $matching; // Return the first generation that has matches } // Move to the next generation $nextGeneration = new PageArray(); foreach($currentGeneration as $child) { $nextGeneration->add($child->children()); } $count += 1; $currentGeneration = $nextGeneration; } return new PageArray(); // Return an empty PageArray if no matches are found }

Hey! A client wanted me to update their website to make it show dates in the form "1. - 3. Jän. 2023" instead of "1. Jän. 2023 - 3. Jän. 2023" It's a small change but not so easy to solve, especially if you want to make it locale aware etc... So I've created "HumanDates" library which is not a PW module but a standalone PHP class so that everybody can easily use it even outside of the PW universe: https://github.com/baumrock/HumanDates Usage is simple and the library can be used as a strftime replacement: // manual download require_once "/path/to/HumanDates.php"; // using composer // composer require baumrock/humandates require_once "/path/to/composer/autoload.php"; // create HumanDates instance $dates = new HumanDates(); echo $dates->format("2023-01-01"); // 1. Jan 2023 echo $dates->range("2023-01-01", "2023-01-03"); // 1. - 3. Jan 2023 If it is useful to you please let me know by giving it a star on github ? https://github.com/baumrock/HumanDates/stargazers PS: It will be available in RockFrontend in the next release simply by calling $rockfrontend->humandates() ?

@horst, it's perfect for me. I already had WebP since your code from late 2018 and use my own ImageSizer, which relies on LibVips. The Vips engine is very fast - about 5 times faster than ImageMagick. I hope WebP will make it into the core soon - many thanks for your hard work!