Leaderboard

I'm off work this week, so I don't have any new ProcessWire updates, but just wanted to wish you a Happy New Year! Looking forward to a great 2024!

I would say page selects are the way to go. You could try my module https://github.com/MetaTunes/CustomDependSelects

One thing that has improved the speed at which I can mark up a design from Figma is the VS Code extension. I can open a design in a VS Code tab, and then not only see the the properties for an element but also have them appear as auto-complete suggestions as I type. Given that mostly I'm just grabbing one or two properties for an element that's really useful. The same goes for assets; I can copy SVG elements directly to paste into my markup or export them straight into my project folder. If you use Figma and VS Code then it's definitely worth checking out.

Season's Greetings ProcessWirers! I hope you enjoy the gift of this module, but use with care... TLDR: This module captures changes made in the development environment so that they can be easily migrated to the live environment without needing to specify the changes or write any code. The demo below gives a brief overview. Want to read? Read on. One of the (few) problems with ProcessWire, in my opinion, is the lack of any native way of handling migrations. Given that PW is such a powerful tool capable of sophisticated and complex web-based applications, this is less than ideal. There is a solution, however, in RockMigrations which accomplishes a lot in a controllable way, provided you are happy to specify your database set-up in code rather than via the UI (albeit that the latest versions allow you to grab much of the required code from the UI). If that suits your need, great. Around the same time as the first versions of RockMigrations, I started developing my own UI-based migrations module, which I have been using with reasonable success for some time. I halted development of the module for a while as RockMigrations developed and I considered switching to that route. However, I decided that my module suited me better and that a real improvement could be made if it was effectively automated so that I no longer needed to specify a migration. So that is exactly what it does: after configuring the module, you add a new migration page with ‘log changes’ enabled (which includes determining what types of objects are relevant for the migration) and work on your development system. Once you have made the desired changes (and tested them!) in the development environment, you go back to the migration page where it has magically captured the objects which have changed and listed them in dependency order. You then ‘export’ the changes, which creates json files to be uploaded to the live environment (via Git or FTP etc.), where they are then ‘installed’ to re-create the changes in the live system. The demo below illustrates this briefly. This first demo shows the creation of a migration. The installation demo will be in the next post, because of size constraints. See post 4 for HD video. Video-source small.mp4 There is a very extensive manual which covers all the features of the module, not just this ‘automatic’ method. Available on github at https://github.com/MetaTunes/ProcessDbMigrate and in the modules library here. PLEASE NOTE that this is still in 'alpha'. Do not use in production without fully testing and backing up at every stage. It is quite complex so, although I have tried hard to eliminate bugs, there will inevitably be some left!

Twig also is compiled to PHP, it's PHP code that interprets your method/property calls and fails on some PW properties for an obscure reason. Reading your link, the first talk is about this sh*t Twig interpretation. ? So at least this ugly behavior is not part of Latte. ? EDIT : Haha, and just now I'm searching something in my IDE and see an old Twig error log, showing how WIIIIIIIDE is this Twig interpretation:

I get that the gist of this thread is "WP bad", but to be fair I've ran relatively often into the opposite issue in ProcessWire: an image or file that should've been uploaded once and then reused is instead uploaded to a whole bunch of separate pages, using loads of unnecessary disk space. ProcessWire doesn't by itself create a lot of unnecessary variations, but it is not uncommon occurrence either: years of code changes combined with badly configured image fields (no limit for image dimensions) can lead to major disk bloat. Worse yet is when someone decides that a file/image that is separately uploaded all around the place now needs to be updated everywhere. Oh the joy! Long story short: there are cases for and against both central media/asset management and page based media/asset management, neither are perfect. Now what is indeed suboptimal is the way WordPress handles variations: they need to be globally registered, are created on upload (whether you need them or not), and won't be (re)created automatically if registered or changed later. This can absolutely lead to unnecessary disk usage, and on the other hand means that you may not have the variation you were looking for available, or it may not be what you expected it to be. But again, each approach/architecture has upsides and downsides ? -- By the way, I'm not generally against bashing [insert a CMS or any other product here] or venting frustrations about it, but I do think we should try to be fair. WP gets a lot of bad rep for a good reason, there are definitely issues and shortcomings, but it also gets blamed for legacy/aging custom (site/theme specific) code, overuse of third party plugins, outdated third party plugins, etc. None of these are core issues, and it's not really fair to blame them on WP ?

@JayGee Great! glad to hear you've found the module useful. Thanks.

Now in the modules library at https://processwire.com/modules/process-db-migrate/.

This week I've continued work on the page versions support that I wrote about last week. While the main PagesVersions module needs more work before it's ready to commit to the dev branch and test externally, it is so far working quite well in internal testing. I mentioned last week how it will support an interface where Fieldtypes can declare that they will handle their own versions. That interface has been pushed to the dev branch as FieldtypeDoesVersions. I've also implemented it with the Repeater Fieldtype, which is visible starting here. Repeaters are so far working really well with versions! As far as core Fieldtypes go, Repeater, PageTable and FieldsetPage are likely the only ones that will need custom implementations. For ProFields, RepeaterMatrix already works with the implementation in the core Repeater (already tested). It's possible that other ProFields will not need custom implementations, though not yet positive. The module that provides version capability is called PagesVersions and the plan so far is to make it a core module that provides API version support for pages. A separate module provides interactive version support in the page editor. I've built this module initially so that I can test versions more easily, but it'll be expanded to provide a lot more. Below is a screenshot if what it looks like in the page editor Settings tab so far: As you can see, you can Edit or Restore any existing version. You can also create a new version from the Live version, or any other version. And of course you can view and delete any versions. When you Restore a version, it essentially replaces the live version with the one that you are restoring. All of this can be done from the module's API as well. Note that the API is provided by a $pagesVersions API variable that is present when PagesVersions module is installed. The API method names and such are a bit verbose right now but may be simplified before it's final. // Get page and add a new version of it $page = $pages->get(1234); $page->title = 'New title'; $version = $pagesVersions->addPageVersion($page); echo $version; // i.e. "2" // Get version 2 of a page $pageV2 = $pagesVersions->getPageVersion($page, 2); // Update a version of a page $pageV2->title = "Updated title"; $pagesVersions->savePageVersion($pageV2); // Restore version to live page $pagesVersions->restorePageVersion($pageV2); // Delete page version $pagesVersions->deletePageVersion($pageV2); Thanks for reading! More next week.

Sure. Part 1 is here: https://1drv.ms/v/s!AmS0-Sk4lDz9h5tDqJwj50qq6-KEhg and part 2 here: https://1drv.ms/v/s!AmS0-Sk4lDz9h5tS2DJsT94F92fJmw If you want to play with it over the holidays ?, the best thing to do is to create a clean PW installation - ddev is great for doing this quickly - and I would recommend add ProcessDatabaseBackups and TracyDebugger. Start by following similar steps to the video. Note that, in the video, I have 'simulated' the migration installation by taking a backup before adding new fields etc. Take another backup after creating the migration, then restore the original one, changing the database name in the module config. And don't forget to RTM: https://metatunes.github.io/DbMigrate/help.html

Demo part 2, showing the installation of the migration was going to be here, until I realised that the file constraint is for the thread as a whole! You can see it here: ProcessDbMigrate video - target - 1703029659248.mp4 See post 4 for HD video.