Leaderboard

There isn't anything major to write about this week, so I'm just checking in to say hello and I hope that you are having a nice week, and tell you what I'm working on here. Time this week has been split mostly between working on the new PW website, working on an API project for a client, and researching and interviewing companies to replace our HVAC systems. That last one probably took the most time, as I didn't know much about HVAC before our maintenance person said it's time to replace the the heating and air conditioning systems. So I've been trying to learn all I can about HVAC in order to go about it in the most informed fashion possible. This is the sort of thing most might only do once or twice in a lifetime (it's a big expense). Usually I'm more DIY with this kind of stuff, and a lot of it is approachable. But when you get into the A/C side of things with refrigerants (R410A, R454B, R30), condensers, compressors, and coils, that's where my head spins, it's way beyond my DIY range. It really is a job for the professionals. So I'm going to leave that to the experts so I can focus on web development. On the PW website I've been working on the API reference this week, along with some final details on the modules directory. Next week I'm hoping to finish the API reference and start working on the homepage. Following that, I'll be writing a lot of new copy for the Features section (thanks for all your feedback there). Then we should be nearly finished. So it's still a few weeks out, but progress is good. Thanks for reading and have a great weekend!

Regarding the API reference, I always wondered if there could be a way for you to add links to pages that reference a particular method and go in deeper details about its usage. One such case could be to link the blog post about output formatting in the $page->of() documentation. Maybe there’s already something in place like this and then it may just be a question of adding/updating links. Thanks and I’m (we’re all!) looking forward to seeing the new website! (and I hope all goes well for your HVAC installation)

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

Heyo, Just ran into a conflict between RPB and other fields on the page. I'm using a custom inputfield that uses Quill as the editor. There's an event listener that is catching changes in an instance of a Quill input while the field is located outside of RPB blocks. InputfieldRockPageBuilder.js L327 // monitor inline ckeditor fields $(document).on("blur keyup paste input", "[contenteditable]", function (e) { RockPageBuilder.changed(e); }); Quill uses a contenteditable attribute for the editor so an instance of that field anywhere on the page is triggering a RPB field update event. // monitor inline ckeditor fields $(document).on("blur keyup paste input", ".rpb-item [contenteditable]", function (e) { RockPageBuilder.changed(e); }); I scoped the event listener selector by adding .rpb-item and that kept it from firing when editing a Quill field, but I don't have any CKEditor fields to test whether that affects other fields. "That fixed it for me, don't know if it breaks something for someone else." 😆

Thx! I think your fix should be fine and at least did not cause any problems on my end. I've pushed it to v6.3.1

ALTER DATABASE databasename CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE tablename CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; Just need to change the field tables which need to hold emoticons

@adrian I did a fresh install on localhost and Tracy runs just fine, so there must be something with my server. Although my localhost setup is the same as the server. I'm going to mark this thread as solved.

Hey @Stefanowitsch thx for the quick meeting. I updated the docs in the hope that others won't have the same problem of understanding how the toolbar works. Let me know if the docs are still missing anything.

With the current project that I'm working on, there's eventually going to be an enormous amount of data to edit within it (in ProcessWire), and so I've been looking for ways to optimize and facilitate the editing experience. The goal is to save the people editing as much time as possible, and reduce the number of steps necessary to make common edits. This is what motivated the recent Table field updates. The is also what motivated a new module I'm working on called PageEditChildren. The PageEditChildren module takes the existing "Children" tab in ProcessWire's page editor and replaces it with a new one that lets you edit all of the child pages inline, directly from the parent page. For specific cases, such as the one shown in this video (below), this provides a more convenient way to edit multiple pages at once. It can significantly reduce the amount of back-and-forth between the page editor and the page list, or multiple page editors, keeping it all in one page editor session. Likely you would use this module to replace the "Children" tab on just some (not all) pages. Specifically, pages where the relationship between parent and children is one where they are often edited as a group. This is a fairly common use case in ProcessWire, and one where this module can save you a lot of time. From an editing standpoint, it has a lot in common with repeaters. Other modules that have some crossover are PageTable (core) when configured to create/edit children pages, and BatchChildEditor. Both use page editors in modal windows to accomplish editing children, a different approach than PageEditChildren, which keeps it all part of the single page editor. Though BatchChildEditor can edit title and status (hidden/unpublished) inline, and supports CSV export/import options, among other useful tools. All of these modules are worth consideration when there is a need to optimize the editing experience between parent and children. This is just an early preview of PageEditChildren, so I'm going to work on the module and test it out a bit more before releasing it. But it could be ready to share as soon as next week. Supporting file/image and repeater fields in this module required some minor core improvements, which are in this week's core updates. I'm interested to hear your thoughts on whether this would be useful in your sites as well? More next week. Thanks for reading and have a great weekend!

@ryan For PageEditChildren, would it be a stretch to have it support editing a children's children from the grandparent page as well? I typically have an /options/ page, and under it I have my page-based options... for example "Colors", "Sizes", "Order Statuses", like this: Options (template is 'options') Colors Red Green Blue Sizes Small Medium Large Order Statuses Pending Canceled Complete If I were to activate the 'options' template in PageEditChildren, I will be able to edit only the "Colors", "Sizes" and "Order Statuses" holder pages, not their children (from within the holder pages) which are the actual options themselves. Is there a way to perhaps support this? This is something I've been meaning to address more nicely in the past, but PageEditChildren would solve it with being able to edit grandchild pages.

@MarkE There's definitely a lot of potential for this to evolve over time. Another example is that it can edit any pages this way, not just children. For that reason, I put in a hook: ___getChildren($page) so that anyone can override what are the "children" for the page. If there is hierarchy, such as there would be if the selector "parent_id=$page" were changed to "has_parent=$page", then I agree the way repeaters do hierarchy could work here too. But I figure the best bet is to keep it simple, focused and straightforward at first to get to a stable version 1, and then start evolving it to do more after that, if there's interest.

It seems like you're looking for a way to create 301 redirects within ProcessWire (PW) using page IDs instead of page paths. While there may not be a specific module that supports this exact requirement, you can achieve the desired functionality by implementing a custom solution within ProcessWire. Here's a general approach you can follow: Create a new field in your Page template to store the destination URL. Let's call this field "Redirect URL" for reference. In the template file for the source page, retrieve the "Redirect URL" field value for that specific page. You can use the $page API variable to access the current page object and retrieve the field value. In the same template file, issue a 301 redirect using the retrieved "Redirect URL" value. You can use the wire()->session->redirect() method to perform the redirect. Here's a sample code snippet to illustrate the process: php Copy code // Retrieve the Redirect URL field value for the current page $redirectURL = $page->redirect_url; // Perform the 301 redirect wire()->session->redirect($redirectURL, 301); Remember to adjust the field name and code to match your actual field name and template structure. By storing the destination URL in a custom field within ProcessWire, you can update it independently of the page path, allowing for flexibility in SEO experiments or changes.

It's pretty easy to implement that without a module. Create a page reference field and add it to all applicable templates. Let's call it 'redirect_page'. In your prepend template file, add a little snippet of code that checks if redirect_page is set and issues the redirect if it is. <?php if($page->redirect_page) $session->redirect($page->redirect_page->url);