Leaderboard

Hi all, Here is one of the latest website we created for a french company renting construction machines and trucks with specialized drivers, based in Le Mans. It’s a rather simple showcase/informational website, but we aimed at making clear (and visually attractive) what is available, what is the skillset and various ways to quickly get in touch. We produced everything, from the design, pictures, illustrations down to the development (ofc). There wasn’t any website before except for social media presence and this task was a follow-up to the update of the visual identity we did. Behind the scene, on the front-end, everything is custom made: we don’t use any frameworks. On the back-end we used the usual suspects and some: TracyDebugger ❤️ FormBuilder ProCache ProFields (RepeaterMatrix, Table) Dynamic options / Select images Our own flavor of “components” Thanks for having a look!

Dear ProcessWire folks! First of all, thanks for all your work on this amazing CMS @ryan and contributors! ❤️ I'm a WordPress guy with 10+ years experience. I'm well aware of the shortcomings of WP (chaos API, no built-in multilingual support, to name a few), but was always able to find a way to work around these. In 2023, due to the never-ending praise from some of my developer peers, I finally gave ProcessWire (and also Kirby CMS) a try for two small projects. If nothing else, these excursions gave me a more senior perspective on the advantages and shortcomings of these three content management systems (none of them is perfect). I was impressed by many thoughtful decisions in ProcessWire's setup, data structure and API. But I am missing one last thing that both WordPress and Kirby have solved in a very clean an comfortable way: A clean solution for deploying fields between environments and committing them to version control. ✅ In WordPress, I am using Advanced Custom Field's local JSON feature for this ✅ In Kirby, all fields and templates are being defined using YAML blueprints, so they are also easy to deploy and version control (although YAML configs come with their own set of shortcomings ?) ❌ In ProcessWire, I couldn't work out a reliable way to define (/autosave/sync) the fields in my code base. So, my question is: Is there any chance the core team will give first-class support for programmatic deployment of fields another thought? If not, what are the considerations that lead to this decision? Syncing fields manually between environments is too cumbersome and error-prone for my taste. I know my request is not new, but the information available felt a bit outdated and not very convincing to me. I'd like to start a discussion here based on facts, not opinions.

Welcome @Rasso! While ProcessWire doesn't have built-in support for migrations or version-controlled field definitions, it already supports export and import of field definitions via JSON, albeit only manually via the admin interface. However, it being JSON-based should be a good enough base to start automating some of this, e.g. by saving and reading the JSON from disk. That would also make them version-controlled as well. I agree this should be part of the core. Most CMS have solutions for this and it'd be a useful feature to advertise. The landscape of modules here is somewhat splintered. The module that integrates best with the core, Migrations, has unfortunately been deprecated. I haven't fully tested RockMigrations yet, but from what I've seen it seems to be doing a few things too many (snippets, "magic pages", "files on demand") and I'd prefer a module that limits itself to migrations, if not just for performance. +1 for a ProMigrations module from @ryan to ensure the best level of integration into the core.

This week in the blog we'll take a detailed look at the newest addition to the ProFields set of modules: the Date Range Fieldtype and Inputfield. This post serves both as an introduction to, and documentation for this new module. In addition, the v1 (beta) release of the module is now available for download in the ProFields board. https://processwire.com/blog/posts/date-range-fields/

@MarkE Sounds interesting! Keep us posted about new releases and let us know if you need beta testers.

I have a json based migrations module that I released some time ago (ProcessDbMigrate). It needed further work, so I have not publicised it further after the initial proof of concept. In the meantime I have improved it enormously and tested it quite extensively with multiple field types including RepeaterMatrix. It is almost ready for re-release. It is a completely different concept to RockMigrations, which is an excellent and well-established module. My module will automatically track database changes as you make them in the back end UI and then export json for installation in the target. It also provides for roll-back, database comparisons and much more. Hopefully out before Christmas. PS I found during the course of development that there are quite a few flaws in the native export functions and had to re-write quite a bit.

that is exactly what I try to do, find a solution to use LATTE without any of the modules that offer support for LATTE. That is what this thread is about and I didn´t post this in the RockFrontend thread ? From the existing modules that I tried, RockFrontend offers in my opinion the best LATTE support and is the easiest to use. But if I find a solution w/o a module needed, for me that would even be better. So I try to find that out now. fyi, I used an older backup from the site where I got the issues, and I tried to reproduce the error, but I can not manage to reproduce it anymore. So I take back the statement that it was RockFrontend causing the issues, it might have been also something else.

Thanks – completely forgot about the info.json file. Bumping to 1.5.63 to remedy it.

Sure. Here's a mini-Tutorial how you can find what you need yourself: Whenever you add a page you view the page /processwire/page/add. That's the page with ID #6 and it lives in your page tree in Admin > Pages > Add Page. If you edit this page you see that this page uses the process "ProcessPageAdd". So you can inspect that file in your IDE by opening wire/modules/Process/ProcessPageAdd/ProcessPageAdd.module There you see the ___execute() method which is the method that renders your page. There you see that at the very end it renders the form and that form is built some lines above by calling buildForm(). If you have a look at that method you see that it is hookable, so you can modify that form by hooking into "ProcessPageAdd::buildForm" <?php // in site/ready.php $wire->addHookAfter("ProcessPageAdd::buildForm", function($event) { $form = $event->return; $form->add([ 'type' => 'markup', 'label' => 'foo', 'value' => 'bar', ]); }); Hope that helps.

Thx @Atlasfreeman that issue should be fixed in the latest version of RockFrontend ?

Can you please try a fresh install? Maybe something was corrupted at your first installation and now things don't work any more as expected. Maybe also try to do a modules refresh two times before installing blocks. Another thing that you can try is to remove all files from /site/templates/RockPageBuilder and then do a modules refresh. This will remove blocks from the database that don't have an associated file. But the best would be to try a fresh install with PHP8.1; I'll try to see if I can reproduce the PHP8.2 issue and provide a fix for it as soon as possible!

Hey @Atlasfreeman sorry for the trouble. Which PHP Version are you using? I'm still on 8.1 on almost all of my projects, so if you can switch to PHP8.1 for the time that would be the best bet to make everything work without any issues ? Thank you very much ?

Sometimes you need to execute a slow task after some event occurs in the PW admin, and normally you have to wait for this task to finish before you can continue using the admin. This is because PHP is "blocking", meaning that while one thing is executing nothing else can execute. There are potentially lots of different kinds of tasks that could be slow, but just as an example suppose you want to generate resized variations of images on a page, and there are a lot of images. You might have a hook like this so that any non-existing variations are created when the page is saved: $pages->addHookAfter('saveReady', function(HookEvent $event) { /** @var Page $page */ $page = $event->arguments(0); // When a gallery page is saved if($page->template == 'gallery') { // Create an image variation for each image foreach($page->images as $image) { $image->size(1200, 1200); } } }); When you save a gallery page in the PW admin, the admin will be unresponsive and will only load again after all the variations have been created. I wanted to find a way for slow tasks to be triggered by events in the PW admin and for the website editor not to have to wait for the task to finish before continuing with other work in the admin. Inspired by this StackOverflow answer I came up with the following solution that seems to work well. Using the image variations task above as an example... First we make use of the URL hooks feature to set up a URL that can trigger tasks to run when it is loaded: // A URL that will trigger tasks when loaded $wire->addHook('/run-task/', function($event) { $input = $event->wire()->input; // A simple check to avoid unauthorised access // You could implement more advanced checks if needed if($input->post('key') !== 'cTdPMBQ7x8b7') return false; // Allow the script to keep running even though we have set a short WireHttp timeout ignore_user_abort(true); // The "create variations" task if($input->post('task') === 'create-variations') { $page_id = (int) $input->post('page'); $p = $event->wire()->pages->get($page_id); // Create an image variation for each image foreach($p->images as $image) { $image->size(1200, 1200); } return true; } return false; }); Then in the Pages::saveReady hook we use WireHttp to load that URL and post parameters that define what task to run and anything else needed for the task (in this case the ID of the page that has been saved). $pages->addHookAfter('saveReady', function(HookEvent $event) { /** @var Page $page */ $page = $event->arguments(0); // When a gallery page is saved if($page->template == 'gallery') { // Load the /run-task/ URL using WireHttp $http = new WireHttp(); // Set a short timeout so we don't have to wait until the script finishes // Timeout values shorter than 1 second can be tried once a core issue is fixed // https://github.com/processwire/processwire-issues/issues/1773 $http->setTimeout(1); $url = $event->wire()->config->urls->httpRoot . 'run-task/'; $data = [ 'key' => 'cTdPMBQ7x8b7', 'task' => 'create-variations', 'page' => $page->id, ]; $http->post($url, $data, ['use' => 'curl']); } }); By doing it this way the task runs in a separate request and the website editor doesn't have to wait for it to finish before they can continue working in the PW admin.