Leaderboard

This week there’s new $pages->saveFields() and $page->saveFields() methods on the core dev branch. You might already be familiar with the $pages->saveField($page, $field); method which lets you save one field from a page, or $page->save($field); which does the same. This is useful when you only need to save one field from a page, rather than the entire page. Now we have a plural version of that method, which lets you specify multiple fields on a page to save: $pages->saveFields($page, [ 'title', 'body', 'summary' ]); Below is the same thing, but on a $page object, so you don't need to specify a $page argument: $page->saveFields([ 'title', 'body', 'summary' ]); You can also use a string if you prefer: $page->saveFields('title,body,summary'); In my case, I needed this method for a project I'm working on, and I also needed it to save without updating the 'modified' time or user, which you can achieve by specifying the 'quiet' argument. Though note, the 'quiet' argument is available for all the page saving methods and has been around a long time. But I'm not sure how widely used it is, so I'll mention it. $page->saveFields('title,body,summary', [ 'quiet' => true ]); This week the API methods for Select Options fields have also been updated to add more convenience for getting, adding and removing options to an existing selection. Let's say we have an Options field of checkboxes named "colors". Each selectable option has an ID, optional value, and title. Now you can get, add, or remove by any of those properties. Previously you had to work directly with SelectableOption instances, which wasn't as convenient. // add by title of option 'Blue' $page->colors->addByTitle('Blue'); // remove the option with value 'orange' from colors field $page->colors->removeByValue('orange'); // get SelectableOption instance of option with title 'Red' $red = $page->colors->getByTitle('Red'); echo "ID, value, title: $red->id, $red->value, $red->title"; // check if colors has an option with value 'purple' if($page->colors->hasValue('purple')) { // it has purple } The methods added to SelectableOptionArray (not yet reflected in linked docs page) include: getByID($id) getByValue($value) getByTitle($title) addByID($id) addByValue($value) addByTitle($title) removeByID($id) removeByValue($value) removeByTitle($title) That's all for this week. There likely won't be any core updates next week, as I'll be out of town again. Thanks for reading and I hope that you all have a great weekend and great week ahead.

This thread is #1 on HN at the moment: https://news.ycombinator.com/item?id=41805391 Do a search for processwire on the page. Looks like an old forum member.

I got great input from @BrendonKoz and @monollonom (and others) in the thread about RockCalendar development, so I thought I'd start a thread for RockCommerce too, as this module is finally taking shape 🚀 Today I implemented automatic image changing when a color option of the product is changed. This is so great, I had to share that!!! 😍 Now what is so great about this? The implementation! It will work with ANY frontend. Really. No matter if you are using Tailwind, UIkit, Bootstrap, whatever. All you have to do is to add a simple hook: // set image according to selected option ProcessWire.addHookAfter("RcVariationOption::enable", (event) => { // get the RcVariationOption instance const option = event.object; // get the image number from client input that is stored in rc-image attribute const image = parseInt(option.$rcattr("rc-image")); if (isNaN(image)) return; // find the thumbnail link and click it const index = image - 1; const link = document.querySelector( ".shop-gallery [uk-slideshow-item='" + index + "'] a" ); if (link) link.click(); }); Isn't that JavaScript code, you might ask? YES! 😎 I have totally refactored the JS implementation over the last week so that RockCommerce now uses the powerful concepts of Hooks that we know from PHP but in the JS world!! (See Let's bring hooks to JavaScript) I am in contact with Ryan to add this to the core once it is tested more. But so far it is really a pleasure to work with on both sides: First, when developing RockCommerce all I had to do to make the above shown hook possible is to make the enable() method of the RcVariationOption hookable by simply renaming it to ___enable() Second, it's also great for anybody using this module, as you can not only LISTEN to those events but you can also totally change the return value or even completely replace it's implementation. For example this is what I use to show custom prices based on the taxrate of the user visiting the website: ProcessWire.addHookAfter("RcProduct::priceTotal", (event) => { // get the money object // it's not a float, because 0.1 + 0.2 !== 0.3 in binary world! const money = event.return; // return the initial price plus the added tax event.return = money.times(1 + RockCommerce.getTaxrate() / 100); }); I've only been working with this new concept for a few days, but I already love it and can't believe I haven't implemented before! The next part to tackle is the cart 🤯😅 I'll keep you posted! PS: Anybody having an e-commerce project coming up or anybody interested in beta testing? Let's get in touch!

Hey @gebeer please download v5.8.0 and use $page->rockpagebuilder_blocks->find('type=Whatever') 🙂 I also added this to the docs: https://www.baumrock.com/en/processwire/modules/rockpagebuilder/docs/api/ Would you mind sharing your use case? I've never needed this 🙂

The question prompted me to put FieldtypeSketchyDate on GitHub. It's a small module I started writing for a solution that never went anywhere, so its pretty basic. It may be a starting point though. In short, it lets you enter 2024 or 2024/10 or 2024/10/11 in the date value, and it also lets you search for 2024/10 and returns all pages with a date between 2024/10/01 and 2024/10/31 as well as those where 2024/10 was entered. So far, it just validates the formatting through the HTML pattern attribute. Proper date validation and calendar UI are still on the todo list.

solved the issue: Unfortunately did redfine some values in the config for: $config->wiremailsmtp = array( .. "extra_headers" => array("Organization" => "My Org", "X-Header" => "") ) So removing them and keeping only the necessary for SMTP solved the issue

In the last couple of weeks I’ve been to several cities in Spain, France and Italy. I’d never been to any of those countries before (or Europe for that matter), so it was an exciting trip. Though the goal was for my kids to broaden their horizons and experience other parts of the world, as well as spend time with my parents and family. We got back this week and have been recovering from jet lag (another thing I’d not experienced before). The 6 hour difference was no problem getting there, but coming back, it’s a little harder to adjust! Next week I turn 50 years old (ugh), and then the following week I’m back in Europe again, except this time in the Netherlands on a bike trip with a client, and without my kids and parents. I’m not sure I’ll be able to do many core updates during the 10 day trip but do expect to have internet access this time, so will at least be online regularly and hope to be here in the forums. After that trip, I won’t be traveling again for a long time, and the focus will be on getting our next main/master version out. I noticed this week that @Robin S is now beating me as our most prolific module developer, with 72 modules! Great job and thanks for all the great modules Robin S.!

@Edward Ver you can use the contains operator for that. 1. First, set your field to use Pipe as delimiter (edit field > input > tag delimeter). With that, if our Page1 has 3 tags: logo vector illustration, they will be stored like this: logo|vector|illustration The pipe separator will be very useful because of this https://processwire.com/docs/selectors/#or-selectors1 2. Now lets find pages containing any of the tags of the page: //This will find pages containing any of this tags logo|vector|illustration (including the current page) $p = $pages->find("tags*={$page->tags}"); echo $p->each('{title} <br>'); 3. Let's remove the current page from the results: // Option 1: find all the pages and remove the current page. $p = $pages->find("tags*={$page->tags}")->remove($page); echo $p->each('{title} <br>'); //Option 2: find pages where the page ID isn't the same as the current page $p = $pages->find("id!={$page->id}, tags*={$page->tags}"); echo $p->each('{title} <br>');

I think the simplest solution would be to use a regular text field and additionally create a hidden datetime field. Then you add a hook on saveReady that populates that datetime field via something like strtotime(...). But it depends who inputs dates... only you? Or also others? Then you need to be more careful with input and maybe provide 3 inputfields, one for day, month, year. That could also be done with a hook.

To get the things done you need to play around with the logic until you hit the pot (usually the logic we write and the logic we think we write are different). To find the issue, let's poke your logic a little: // Find all pages with the template work_details and where the field tags is exactly the same as this page tags field $items = $pages->find("template=work_details, tags=$page->tags"); When viewing Page1 that will be translated to: //Pages with template work_details and field tags equal to branding/identity $items = $pages->find("template=work_details, tags=branding/identity"); To discover why you aren't getting the results you are expecting, try something simple first: // You can copy and paste each of these examples into your code // First, let's verify if all the pages with a specific tag are being fetched. // Print the title of all pages with a tags field containing "branding/identity" $items = $pages->find("tags=branding/identity"); echo $items->each('{title}'); // Now, let's do the same dynamically and also print the value of the tags to understand what $page->tags contains. // Print the title of all pages with a tags field equal to this page's tags field and print the value of tags $items = $pages->find("tags=$page->tags"); echo $items->each('{title} <br>'); echo "Tags value: " . $page->tags; // Also, note we can search for tags fields that contain a string using %= instead of = // Print the title of all pages containing the string from the page's tags field $items = $pages->find("tags%=$page->tags"); echo $items->each('{title} <br>'); echo "Tags value: " . $page->tags; As as side note, debugging will be way easier if you install TracyDebugger.

@ngrmm Hey there, Fluency author here. I submitted a PR that makes ProcessTranslatePage compatible with the new major release of Fluency. It hasn't been merged yet, but you should have success using this module with these changes. https://github.com/robertweiss/ProcessTranslatePage/pull/10

My pleasure. The hooks and inputfields APIs in ProcessWire make module development an absolute dream. It's very satisfying seeing the results you can get with just a little code, and working on modules provides a motivation to dig into the core code so I learn a lot in the process. Also, another shout out to @adrian's amazing Tracy Debugger, which has been transformative for my coding. I have several more modules in progress so watch this space. 🙂