Leaderboard

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!

Hey all! This is a module to enhance forms built using the Pro FormBuilder module by providing the ability to submit them in place using AJAX and HTMX. FormBuilderHtmx works in harmony with FormBuilder by handling front-end rendering and AJAX and lets FormBuilder manage form configuration and processing. FormBuilderHtmx provides a drop-in replacement for the $forms->render() method and provides all native features and behavior (and adds a few extra superpowers to boot). Noteworthy features: Zero configuration, install and render AJAX powered FormBuilder forms immediately Render multiple forms on the same page. Supports both multiple instances of the same form or different forms. Each form is processed independently. Non-intrusive, can be used alongside FormBuilder's native rendering methods and does not modify core module behavior Perfect for forms embedded in popups and modals Does not conflict with styling and other JavaScript already in-place, only handles the form submission/response loop Automatically disables the `Submit` button on submission to prevent duplicate requests Provides the ability to add a custom 'spinner' shown when a form is being processed Gives you the ability to add additional HTML attributes to your FormBuilder <form> element. Add additional custom functionality using HTMX attributes, hook into form actions with your JavaScript, or even add AlpineJS directly to your forms. Compatible with FieldtypeFormSelect, let users choose which forms to embed, your code determines how they are rendered Uses HTMX, a stable, powerful, and tiny (14kb gzipped) library, installation documentation available here This module is BYOH (Bring Your Own HTMX) in that the HTMX library is not included or available within this module. This ensures long-term stability by not locking FormBuilderHtmx to external asset versioning. FormBuilderHtmx uses stable core HTMX features so use the library version that works for you and confidently add this module to both new, existing, and future ProcessWire applications. In some instances CSRF protection may need to be disabled to submit forms with this module. Just test your forms and you're good to go. Using this module is truly easy. <!-- Replace the native $forms->render() method with $htmxForms->render() --> <?php $htmxForm = $htmxForms->render('your_form_name') ?> <!-- Use native ProcessWire properties and methods as usual --> <?php echo $htmxForm->styles; echo $htmxForm->scripts; echo $htmxForm; ?> Presto. You can optionally include a helpful 'spinner' or activity animation that will be showed to users while their form request is being processed. Check out these ready-to-go examples you can use in your projects. <style> /* Add these styles to your CSS, the `.htmx-request` must be present as shown here. Be sure to include any CSS your 'spinner' may need, and style everything as desired */ .activity-indicator { display: none; } .htmx-request .activity-indicator, .htmx-request.activity-indicator { display: block; } </style> <!-- Optional second argument matches that of the $forms->render() method for pre-populated values The third argument is the CSS selector matching your 'spinner' element --> <?= $htmxForms->render('your_form_name', [], '#indicator-for-the-form') ?> <div id="indicator-for-the-form" class="activity-indicator"> <span class="spinner"></span> </div> Presto (again) Check out the documentation for detailed usage and other available features. Pull requests and issues filed on Github are welcome, or drop by here to get some help! Install as a ProcessWire module Install using Composer Download from the FormBuilderHtmx Github repository . Cheers!

https://nativephp.com/docs/1/getting-started/introduction "NativePHP is not a GUI framework. We don't want to tell you how to build your app. You can choose whatever UI toolset makes you and your team feel most productive." "#What's in the box? NativePHP comes with a bunch of useful features out of the box, including: Window management Menu management File management Database support (SQLite) Native notifications" What can I build with NativePHP? Honestly, anything you want. The only limit is your imagination. Now for building Windows apps too: https://github.com/orgs/NativePHP/discussions/278

This is my first module. It is primitive, like my neighbor who loves to fire up his new Makita breaker hammer after 21:30h. Please, feel free to do whatever you want. I don't promise I will add better functionality but maybe... If you do, please ping and send me back. Thanks! It loads every page on the backend. It calculates the text width in two fields you choose on the configuration page.. If there are any updates, I will post them here. Happy ProcessWiring! PS: These measurements are specifically for desktop and Google's SERP (Search Engine Results Page). UPDATE on 15 May 2024: Google started to calculate (truncate) the meta title for 20px Arial yesterday. The Module has been updated. Here is the link to download/install the latest version: https://processwire.com/modules/seo-text-width/ EDIT: The version 0.0.5. Added two dropdown fields on the configuration page of the module. PROVE IMAGE: You can check the meta title, which was measured with 18px Arial and it was less than 512 pixels.

This is absolutely fantastic and very timely as I was thinking of tackling the same issue in one of our current projects!

Wow, OMG! Then the secret is to change 'HOME', now it works like I need. Shows all other pages is based in what we configure in 'HOME'. For the gods, I almost give up, believe me, I'm trying to do it something like 5 or 6 days, only now by editing HOME works, I never tried to change on home, I always trying to change "about" page because the rest of uri with other languages! Thank you SO MUCH!

First you need to add a page reference field to the contract template. I assume you name it 'products' Set it to accept multiple pages Choose type ASM select and product template for allowed templates Now that you have your products field in place, you can write a script to assign the product pages to the contract pages. foreach($pages->find("template=contract") as $cp) { // assuming you have a field $cp->uid with the ids of the products // if you have a comma separated list of ids or the like, convert it to array $uids = explode(',', $cp->uid); // add products for each $id to products field foreach($uids as $id) { $cp->products->add($pages->find("template=product, uid=$id")); } // save the changes $cp->setAndSave('products'); } I would recommend using TracyDebugger Console to run the script. Or you can run it from site/templates/home.php This should assign the correct products to the contract pages and make them editable from the contract pages edit screen.

@Marty Walker @Robin S @Mats Could you try the attached version of the module and see if it helps with your issues with Vimeo URL formats? Robin, Mats (I hope I got the right one), I've included you both as you have a similar issue open on the repo. TextformatterVideoEmbed.module

If you're running Debian, try adding this to your config.php /** * Enable Session Garbage Collection * Garbage Collection is disabled in Debian as default (probability set to zero) * Enable session garbage collection with a 1% chance of running on each session_start(); * Chance calculated as gc_probability/gc_divisor * Session path is defined inside wire/core/Session.php and points to site/assets/sessions * Thanks to this modification session now takes into account gc_maxlifetime set in config */ ini_set('session.gc_probability', 1); ini_set('session.gc_divisor', 100);

Hi @Klenkes, sorry for the issue. I've just published a new version which should fix it. Please give that a go and let me know if it's worked.

For what it's worth, I switched from MySQL to MariaDB on my local dev server which is running Ubuntu 22.04. Importing a db dump that uses InnoDB is 7x faster in MariaDB. I tried making it faster in originally in MySQL by adjusting a bunch of settings without luck. Switching to MariaDB with its default settings is much faster based on my simple test. Edit: It seems the reason the speed is much faster has to do with MariaDB disabling binary logging by default while MySQL doesn't which is probably the more accurate explanation: https://dba.stackexchange.com/questions/327303/mysql-8-twenty-times-slower-than-mariadb-10-3

With every PW website, I usually create a folder in the root (let's call it "something") where I store various scripts that do random things (most of these scripts act on ProcessWire directly so I bootstrap it). I execute them either by visiting the url in my browser or using the terminal. There's a bit of security through obscurity with this approach that feels wrong. Using something like RockShell is probably the more formal way to do it, but sometimes it may not be the right choice for short-lived scripts or scripts that don't act on PW directly, or if the script is written in Bash. Also I haven't started using RockShell regularly yet although that's the plan (I'll have to convert a lot of sites). So my question is, what is your go-to approach in terms of where to store and how to handle supporting scripts like I described?

@Jonathan Lahijani If you edit your child page template and temporarily enable $config->advanced = true; you can click on the "System" tab and check the box to have it show the "name" field on the content tab, which should do the trick.

Would it be possible to edit the 'name' field of a page as well?

This is awesome. I use PageTable with a slight hack to accomplish what's shown here, but that will go away now. Also there's a typo with the word "ediable" in the module settings.

Have recognized the speed increase with a MariaDB / InnoDB project set up too. Never investigated further, why it feels much more responsive than comparable setups w/o InnoDB so far.

My personal policy is to assume those will only be executable through shell, and save them in site/templates/cli or something like that, but always inside templates so that they are blocked by default by the default htaccess config.

Same here. In that case adding $config->dbCharset = 'utf8mb4' manually fixes the issue for future emojis. Awesome. Thank you.

Sorry if that wasn't clear: Simple approach with as little inter-dependencies as possible and editors will copy over content if needed.

Just adding my two cents about experiences with this sort of thing: No matter how many times you discuss things with clients to create beautiful solutions to exactly these problems, there will always be a point where you run into flexibility problems if you start combining things and creating complex dependencies too much. Yes, usually this means more work for content management but also, this usually costs less in the long run because of exactly that reason. It is always easier to use said page tree option and for us, after many many projects which needed adjustment down the road - or even a rework to finally use the page tree option, we just never think about this anymore at all.

If you want to serve the english content from / instead of /en then you need to go to the home page (id=1), edit it and go to settings: In this example it's default = german and I'm serving "de" from foo.com/... English has url "en", so it's served from foo.com/en/...

Hey @Techno "default" means the default language of your specific ProcessWire instance, not more, not less. It does not refer to your default spoken language, not your default browser language, not a global default PW language, nothing like that. It only means this is the default language of your own website. Which language that is is up to you, it can be anything. For me the default is often german, for you it could be PT, for others it could be FI, etc.. Have a look here:

Hi @Techno welcome to PW ? Have a look at the absolutely brilliant Tracy Debugger https://adrianbj.github.io/TracyDebugger/#/ and its debug methods https://adrianbj.github.io/TracyDebugger/#/debug-methods

@cwsoftthanks for helping me! @adrian It's running on LiteSpeed, but I don't know what's underneath it. But hey, it is working like a charm.

Hi @CraigThank you very much! Seems to work fine now.

Looks cool! PW based desktop apps on the way? Ahh... SQLite not supported... Probably not.

@wbmnfktr I created an issue on Github for this.

Welcome to the plugin-author's club, @Leftfield!

Yes, this is what I would go for. Sth like domain.com/fr/market1/, domain.com/fr/market2/ etc. so you have segments /language/market/ You can either 1. reflect this in your page tree -home --market1 ---page --market2 ---page 2. use URL segments. This would make the routing more complex. 3. You could also use URL hooks with named arguments and do your routing from there. For 2 and 3 you need to make sure that the URLs with market segments resolve to a 404 without segments/hooks in place. I've done something like this at https://www.ziehm.com/en/products/ and https://www.ziehm.com/en/us/product-portfolio/ where /us/ is the market segment. In this case we solved it through the page tree structure. Drawback is that similar pages under default market (no market segment) and us market need to be maintained seperately. EDIT: to avoid maintaining duplicate pages for different markets, you can have a markets parent with markets as children with templates markets and market respectively: Market pages: -markets --europe --asia --africa Then have a page reference field that allows selection of 1 or more markets. Now you use this field in combination with prices or other things. In the rendering logic you can get the price for market by URL segment. You'd need to have the market chooser direct to the respective market segments of the page. In said project we have a market selector page for each market with the languages to choose from https://www.ziehm.com/en/us/market-selector/ If you have those market pages in the tree, you can also link markets to available languages for that market. It was fun and challenging to work that out for said project.

Just launched my first public Module ? This module allows ProcessWire to send transactional emails via Brevo. Download the latest version: https://github.com/ttttim0709/WireMailBrevo Installation Copy the WireMailBrevo directory into your site/modules/ directory. In the ProcessWire admin, go to Modules > Refresh. Click "Install" next to the WireMailBrevo module. Usage Example usage: $email = $mail->new(); $email->to = 'recipient@somedomain.com'; $email->subject = 'Test #1'; $email->body = 'An example email'; $email->send(); Use of Versions: Check the Brevo dev section for more information about Message versions $email->versions([ [ 'to' => [ [ 'email' => 'bob@example.com', 'name' => 'Bob Anderson' ], [ 'email' => 'anne@example.com', 'name' => 'Anne Smith' ], ], 'subject' => 'This is my version subject line', ], [ 'to' => [ [ 'email' => 'jim@example.com', 'name' => 'Jim Stevens' ] ], 'htmlContent' => "<!DOCTYPE html><html><body><h1>Modified header!</h1><p>This is still a paragraph</p></body></html>", ], ]); Configuration After installing the module, you can configure it by going to the module settings page. You need to provide the following configuration options: Brevo API Key: Obtain this key from your Brevo account settings. Sender Email Address: The email address to be used as the sender. Sender Name: The name associated with the sender's email address.

A few screenshots to demonstrate:

On my development laptop: $ mysql --version -> mysql Ver 15.1 Distrib 10.5.12-MariaDB, NO issues or problems.