Leaderboard

The ProcessPageList module now has a configuration setting where you can select pages that should not be shown in the page list. For example, maybe once you've set up your 404 page, you don't really need it to display there anymore, except maybe in debug mode. Or maybe you don't ever need the "Admin" page to display in the page list. This new feature lets you do that, and for any page that you decide. Next, a "Usage" fields has been added to the "Basics" tab in the Field editor, just like the one in the Template editor (requested feature #445). This shows you what fields are using the template. It's essentially the same information that you'll find in the "Actions > Add or remove from templates" feature, but easier to find, especially for people newer to PW. That's all for this week, I hope you have a great weekend!

Hi folks, I just released version 1.1.1 which fixes the PHP 8.1 related errors from this issue: https://github.com/wanze/SeoMaestro/issues/41 These issues have been fixed by merging a pull request. I appreciate if the community can help me out, as I am quite disconnected from the ProcessWire world (as you might have noticed). However, I still want to support this module with bugfix releases. Cheers

Great! Is there a chance to add hiding pages (and their children) by template or by custom selector. That would make the new feature more complete and useful IMHO.

Very nice addition, thanks Ryan! ? This is actually one of the features of a general purpose utility module we install on all our client sites, so will definitely be using this option in the future.

Hello friends! I have another module for you, which will make your daily work as a Processwire developer easier. Introducing: AppApi This module helps you to create api-endpoints, to which an app or an external service can connect to. Features Simple routing definition Authentication - Three different authentication-mechanisms are ready to use. Access-management via UI Multiple different applications with unique access-rights and authentication-mechanisms can be defined The documentation has become quite extensive, so have a look at the Github repository for details: Installation Defining Applications Api-Keys PHP-Session (Recommended for on-site usage) Single JWT (Recommended for external server-calls) Double JWT (Recommended for apps) Creating Endpoints Output Formatting Error Handling Example: Listing Users Example: Universal Twack Api Routes Page Handlers File Handlers A special thanks goes to Thomas Aull , whose module RestApi was the starting point to this project. This module is not meant to replace this module because it does a great job. But if you want to connect and manage multiple apps or need other authentication methods, this module might help you. I am already very curious about your feedback and would be glad if the module helps you a little bit.

We recently launched DOMiD Labs, a new microsite for our existing client DOMiD. We already built the main site for DOMiD in 2019, as shown in our previous post here and featured in ProcessWire Weekly #296. The new DOMiD Labs site belongs to a project to plan participative museum concepts for the upcoming migration museum in Cologne, Germany. Concept, design and implementation by schwarzdesign - web agency in Cologne, Germany. Featured in ProcessWire Weekly #433 We're using an in-house starter project to bootstrap new ProcessWire projects. This allows us to deliver smaller projects on a low budget while still providing an extensive, modular content system and to spend some time polishing the features our clients care about. Notable features of the site include: A modular content builder utilizing the excellent Repeater Matrix field. A blog area with a paginated news index page. Multi-language support (site available in English and German). Q&A sections using accordion elements. A contact form built with the Form Builder module. Fully configurable navigation and footer components. Custom translation management for interface translations. Learn more: domidlabs.de

Huh, sorry, I thought ProcessWire would figure out the arguments automatically, since their types are distinct. It usually does that. Try passing null in the second argument: $sanitizer->date($input->post->termin1, null, ['returnFormat' => 'd.m.Y']); (Sorry, I’m on vacation, no code formatting on mobile) Anyway, as I understand it, the first parameter is the format you expect the incoming value to be. A sanitizer’s job is generally to make sure the input conforms to some expectation. In this case you don’t care what format the input is, so you don’t tell it your expectation and it will just try to make any valid date out of the input. Additionally you specify the returnFormat to get a pre-formatted string back (this is not always desired because often dates need to be used in calculations or be checked against additional logic). Be aware you might still get null if the input can’t be made into a valid date. Also, if the input is in an ambiguous format, it may get parsed in an unexpected way (in fact, sometimes it seems to default to the current date). But this shouldn’t be a problem because AFAIK browsers all send YYYY-MM-DD when a date input is used. It’s just to say that it’s usually good practice to specify the input format.

Hi, as per the docs you can specify the return format in $sanitizer->date(), just not quite the way you have done it (https://processwire.com/api/ref/sanitizer/date/). This should do the trick: $sanitizer->date($input->post->termin1, ['returnFormat' => 'd.m.Y']);

Thx for the quick and detailed answer ? Have you seen the new version? https://github.com/baumrock/rockmigrations#running-migrations What you describe is possible with a single file called /site/migrate.php (similar to /site/ready.php for hooks): https://github.com/baumrock/rockmigrations#quickstart No need for another module, no need for creating separate php files with php class notation for simple migration changes, no need for a CLI. Unless I'm missing something ?

So it goes like this, you create a migration file under the Setup > Migrations. This is a "Default" type of migration. Which is the one I only use, since with RockMigrations the whole API work is abstracted so nicely that working with the "data schema" (meaning ALL the config in processwire) is really more simple, so no need for the specific migrations types. <?php class Migration_2022_06_02_11_42_58 extends Migration { public static $description = "Do some awesome migrations stuff"; public function update() { // Put your migration code here $rm = wire('modules')->get('RockMigrations'); $rm->migrate([ 'fields' => [ 'button_label' => ['label'=> 'Button Label', 'type' => 'text'] ] ]); } public function downgrade() { // Put your rollback code here } } Then this runs either through the UI under Setup > Migrations or the CLI included in the Migrations module. We could say one "caveat" is that to use the CLI you need to install the Migration module through composer as the CLI tool has dependencies assuming them. So every time I wan to to push a migration to the live site, the pipelines I use for deployment (Bitbucket Pipelines) rsync's the new files, then triggers on the server: php /path-to-website/site/modules/Migrations/bin/migrate run Or for anyone reading this not familiarized with CI/CD pipelines, just log into the server and run the command. So "migrate run" runs all "pending" migrations. Previously run migrations are already tracked as migrated, so they won't run again. cc @MrSnoozles. I DO NOT, have an automated rollback solution yet, in terms of the CI/CD pipeline. So if I break something, I just move forward with another migration. Let me know if it sounds I'm skipping something, wrote this a bit quickly!

Today I needed to implement a background image with sources, using the new UIkit Image component implementation: https://getuikit.com/docs/image#picture-sources PageimageSource doesn't do this out of the box, but I found I neat solution, which I thought I'd share: <?php // $bannerImage = Pageimage; preg_match_all('<source\ssrcset="(.*?)"\ssizes="(.*?)"\stype="(.*?)">', $bannerImage->render(), $matches); $sources = []; foreach($matches as $index => $match) { if(!$index) continue; foreach($match as $i => $v) { if(!isset($sources[$i])) { $sources[$i] = []; } $sources[$i][[ 'srcset', 'sizes', 'type', ][$index - 1]] = $v; } } echo '<div class="uk-background-cover" sources="' . $sanitizer->entities(json_encode(array_values($sources))) . '" data-src="' . $bannerImage->url . '" data-uk-img></div>'; This assumes that the render() function is returning a <picture> element. Cheers, Chris

Good comparison and and I can agree to almost all of your statements, except: Personally I would count that as disadvantage because Craft is forcing you to use one special template engine. I know you don't want to start a discussion about Twig vs. PHP, so I just want to say that I think it is better to be able to switch template engines like in ProcessWire instead of being forced to use one template engine. ? That and the expensive pricing were the reason why I never used Craft for a project yet. But I can understand why you like it so much.