Leaderboard

After over 10 years, I didn't know you can simply give a page's name when assigning a value to a page field. I discovered this by accident. I used to do this: $page->setAndSave('order_status', $pages->get('/path/to/order-statuses/pending/')); But I realized you can simply do this in ProcessWire making it much easier on the eyes, with the added benefit of not having to update the code if the path to the page changes: $page->setAndSave('order_status', 'pending'); My mind is blown. It makes me wonder what other little things I haven't realized yet.

Thx for sharing, didn't know that as well! Not sure if your example is real or not, but I'd recommend something like this: $order->setOrderStatus('pending'); So your $page should better be an OrderPage (custom page class) and that pageclass should have this method: <?php ... public function setOrderStatus($status) { $this->setAndSave( 'order_status', $this->wire->pages->get("/path/to/order-statuses/$status") ); } I know the benefit looks little, but the code does not only get cleaner to read: <?php $page->setAndSave('order_status', $pages->get('/path/to/order-statuses/pending/')); // vs $order->setOrderStatus('pending'); It gets also more error-proof (what if someone/something created another page with name "pending" somewhere else in the tree? And not to forget your system will be better and easier to maintain. Imagine for example you change the path of your statuses one day. You only change the path in setOrderStatus() and you are done, rather than finding all instances of ->setAndSave(...). Also maybe one day the client want's E-Mail notifications on changed statuses... Simply go to setOrderStatus() method and add the mail code there. If you have several ->setAndSave('order_status', 'something') sprinkled around you might be tempted to add the mail sending on several locations or you might forget it somewhere and you'll have introduced an unnecessary bug ? PS: I'd even more prefer setStatus() but that's already taken by the Page baseclass. updateStatus() would also be an option. But setOrderStatus() might be the clearest anyhow ?

"I didn't know you can do this" is definitely a good theme for a blog post @ryan!

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!

It is weird to me seeing all those paths like "ProcessWire\UserPage.php" in amongst the other full correct paths. They are clearly not valid and will trigger errors for any open_basedir restrictions. So it does seem like a question for Ryan from what I can see.

OK to delete the files and the Modules table in the DB. ? Well, I reinstalled in PHP8 on an independent space and everything went fine. ? I was able to install my first modules and discover how they work, plus a lot of other things ? Of course, all this raises a lot of new questions, but I'll ask them when the time comes. Many thanks da² for your help in helping me discover ProcessWire. ?

Yes at least you'll get rid of errors if they prevent PW to work. There's also a database table "modules" that references installed modules I suppose, I don't know if it's preferable to remove module entry or not.

Salut @Webjack, On va le faire en anglais si ça te dérange pas, ce sera compréhensible par tout le monde. ? Yes this is a PHP version issue, it's about union type "string | int" introduced in PHP 8. You have issues in your system installation, none of MySQL or other PHP extensions are found. These requirements are validated at the begin of PW installation. ProcessWire works fine with PHP 8+.

You could try to delete the row of your module in the "modules" database table. That would mean that the module is uninstalled. Then you could check if the module get's installed automatically on the next page load or modules refresh. If it get's installed you could add something like this to your install() method of the module: bd(debug_backtrace()); die(); In that backtrace you should then see what is triggering the installation of the module.

The parent class but actually I’m seeing in ryan’s comment that it’s only necessary for “Process” modules, my bad

I do the following. Copy all files of the live site via FTP to my local dev environment (e.g, /htdocs/pw-test). Create a backup of the MySQL/MariaDB via phpMyAdmin (online). Open my local dev instance of phpMyAdmin (XAMPP) and import the database. You may need to change the DB settings in your local /site/config.php file in case the DB credentials differ between live and local DB connection.

What you described here is the opposite of PW. Call it what you want, but if these are your requirements for a tool to call itself a CMS, than PW is not —and won't be— one. This can happen with site profiles though. We only have to wait that they appear, and they will with time.