Leaderboard

These last few weeks I've been working on integrating a ProcessWire installation with the Fareharbor API for a client. Other than the authentication part (which is as simple as it gets), I've found this API to be one of the more time consuming ones to work with. It's not so much that the API is difficult to use, as much as it is just a time sink, taking a long time to reorganize the info it provides into something useful for our needs. And likewise taking a long time to prepare information to put back into it in the format it requires. My best guess is that it is an echo of an existing back-end API, projecting internals rather than tailoring a simpler public API to them. Perhaps it's an interface optimized for the some internal legacy system rather than the external consumers of it. Or perhaps it already is a lot simpler than what's behind it, and its interface has been carefully considered (even if it doesn't feel that way), who knows. To be fair, no API is perfect, and this particular API does provide a working and reliable interface to some pretty complex data, and an immense amount of power. It's good to work with lots of different APIs, from easy-to-painful, as it helps to clarify paths to take (and to avoid) when authoring new APIs. I ended up building an adaptor module in ProcessWire just to give this particular API a simpler interface that was more useful to the needs we had, and that is now saving us a lot of time. It reminded me of one reason why ProcessWire was built in the first place, to create a simple interface to things that are not-so-simple behind the scenes, and I think we've been pretty successful with that. We'll keep doing that as ProcessWire continues to mature, evolve and grow, as we always have. In terms of core updates, commits this week were similar to those from the last couple of weeks: a combination of issue fixes, a PR, feature requests and minor improvements. We are now 17 commits past 3.0.211, but I'm going to wait till next week before bumping the version to 3.0.212, as there's a little more I'd like to add first. Thanks for reading this update and I hope that you have a great weekend!

What's the big picture here? Will this div-soup eventually contain content? Or stay like that, just as some sort of decoration? The easiest way to do what you want, is using a plain old table - but with role=presentation. If you don't present tabular data to the user, this is OK. <table role="presentation"> <tr> <td></td> <td></td> <td></td> </tr> <tr> <td></td> <td></td> <td></td> </tr> <tr> <td></td> <td></td> </tr> </table> table { border-collapse: collapse; width: 150px; } td { width: 50px; height: 50px; border: 1px solid black; } https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/presentation_role

Almost every time. I think we're just a bit spoiled with the PW API, but it is always a bit of a shock to work with API data that needs to be wrestled into shape before we can do what we want to do. I'm not sure I could even wrestle it into shape if it wasn't for PW.... On the plus side, at least that API is documented and returning JSON ?

Haven’t tested but isn’t this just $page->prevAll('limit=5') and $page->nextAll('limit=5')? https://processwire.com/api/ref/page/prev-all/

v2.15.1 ignores module migrate files if the corresponding module is not installed ? And it will trigger the migratefile right after the module has been installed! Thx for your input and feedback guys! Keep up bringing good suggestions ?

This is a reissue of a module of mine called "PublishingOptions", that I wrote a while ago. The big difference is that this module is written in PHP 8 and has some nice additional features. The old module could only publish and unpublish pages depending on date and time settings, but the new version goes much further. So you can decide what should happen after the publication end date has been reached. You have the following options: Unpublish the page - this is what the old version did Move the page to trash - new Delete the page permanently- new Move the page to a new position in the page tree - new The last option will be interesting if you want to move the page fe to an archive after a certain date. You can select the new parent page and after the publication end date has been reached, the page will be moved under the new parent page. You will find a more detailed instruction and download possibility at https://github.com/juergenweb/JkPublishPages This module is Alpha stage and should be tested carefully before using it on live sites. I have planned to add this module to the PW module download section, so everyone is invited to test it out and to report issues directly at GitHub. Thanx

TextformatterRockDown ProcessWire Textformatter for simple mardown-like text formatting ideal for headlines: *bold* _italic_ ~strike~ ```monospace``` #monospace# This module does intentionally not support full markdown syntax! It is intended to be used for simple formattings that you usually want to apply to headlines. Problem The title field is always available in ProcessWire and it is often used for page headlines. But unfortunately when using such a plain textfield it will not be possible to print some words in bold or italic font. One solution is to create a CKEditor/TinyMCE field, but it's a lot more tedious to setup. Also it's not easy to make it single-line-only. Solution Just apply this textformatter to your field and you'll get quick and easy headlines with bold and italic fonts that will also work with frontend editing. Backend Editing: Frontend Editing: Formatted: Custom tags You can add custom replacements easily via hook in /site/ready.php $wire->addHookAfter("TextformatterRockDown::replace", function ($event) { $str = $event->arguments(0); $start = $event->arguments(1); $end = $event->arguments(2); $str = preg_replace("/$start@(.*?)@$end/", "$1<span style=\"color:red;\">$2</span>$3", $str); $event->return = $str; }); Download https://github.com/baumrock/TextformatterRockDown https://processwire.com/modules/textformatter-rock-down/

Just to be clear, which version of ProcessWire are you using? The implementation for populating pages_parents has changed a few times even in recent versions. Anyway, my understanding is that pages_parents should contain every page that has children — but again, the implementation has changed a few times, and earlier versions (before 3.0.165?) were not entirely reliable. Meanwhile the very latest dev version has another approach that fixes scalability issues that were introduced around 3.0.165, but this version is considered experimental ?

A million thanks! :)

Thanks Bernhard - I had to remove the Save button when adding a new page with a particular template today for a specific reason, so here was my solution which I arrived at thanks to your code above: $this->addHookAfter("ProcessPageEdit::buildForm", function($event) { $page_id = (int)$this->input->get->id; $page = $this->pages->get($page_id); if ($page->template->name == 'my_template_which_only_needs_publish_but_not_save') { $form = $event->arguments(0); // We want to check the publish button is actually visible first - usually there is "isNew=1" at the end of the URL but that can be removed // manually so best to use a more thorough check $publish_button = $form->getChildByName('submit_publish'); if ($publish_button) { $save_button = $form->getChildByName('submit_save'); $form->remove($save_button); } } } }); This will of course revert to just showing the Save button once the page has been saved. Hope that helps someone in future (probably me in about 6 months time when I forget all about it - that's usually the case ? ).

Appending ?field=yourfieldname to the URL should be enough. ?fields=foo,bar would also work.

yeah looks very cool @gornycreative Perhaps if you don't mind sharing it, it would be great to have a look! - this is somewhat the original intention of the module, to be able to provide all of those types of settings interfaces like people build for WordPress etc..

BTW: You will get also a notice that your system does not fulfill the requirements if you have not installed LazyCron (not only if the PHP version is lower). You can ignore this, because LazyCron will be installed automatically during the module installation, if it is not installed. Unfortunately, Processwire gives you a warning that your system does not fulfill the requirements for the module, but not exactly what the problem is. ?

Cool! I've been searching for a module like this. This comes in handy when users are preparing blog/news articles and want them to be published automatically on a specific date. I will definitely try it out.

If you're interested in running ProcessWire using PHP's built in Webserver this one's for you: <?php /***************************************************************************** * Router script for emulating Apache's "mod_rewrite" functionality. * This router script is designed for testing ProcessWire instances quickly. * Don't use this script and/or PHP's built in Webserver in production. * * Usage: php -S localhost:8000 -t /ProcessWire /ProcessWire/routing.php *****************************************************************************/ $uri = urldecode(parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH)); if ($uri !== '/' && file_exists(__DIR__ . $uri)) return false; $_GET['it'] = $uri; // emulate index.php?it=$1 require_once __DIR__.'/index.php'; Enjoy!