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!

Hope you had a joyful Christmas season, @ryan and ALL! I wish you, @ryan, your whole family, and of course each and every one of this wonderful community a Happy New Year! I know I wasn't this active in here this year, but be sure I missed and thought about you all the time. Cheers, for an awesome 2024!

Thanks, @ryan! Being here for so many years it feels like home. And everyone in the forums like relatives, even though I never seen them in person and only imagine them as their avatars living somewhere around the globe) So these "winter holidays" celebration posts are kind of like a family reunion, when everybody gathers at a holiday table after a not so easy year passed. Happy new year to everyone! Let it be a better one! С наступающим! Всего хорошего и доброго! ???

Many thanks @ryan for all your hard work and happy holidays and new year everyone!

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!

The core version has been bumped to 3.0.233 this week. While there aren't a lot of commits, there are some major updates to the core PagesVersions module. I also thought a version bump would be helpful as there's also a new PagesVersionsPro version released which requires features only available in 3.0.233. The PagesVersions module is now pretty much finished in terms of its API and feature set. This week the ability to save and restore partial versions was added, and that was the main remaining thing. By partial versions, I mean the ability to specify what fields are included when a version is saved or restored. Though I think it's primarily useful on the restore side. So if you find you just want to restore one or more particular fields from a past version, rather than all the fields, now you can. The core PageTable field was also updated to support versions, partially anyway. It supports versioning of items already in the page table, but doesn't handle versioning of items that you might add or remove within a version. It turns out it's going to be a lot of work to do that, so I settled with just partial support for this week. As it is, if you add a new item to the PageTable while in a version, then it'll ask you if you want to import it once you edit the live version. If you delete an item, it'll be deleted from all versions. That's how it works temporarily until it fully supports versions. ProFields Table now also supports versions. But there is one case where it doesn't: paginated table fields. A future version of Table will add support for that. Until then, the PagesVersionsPro module does make it clear when a paginated table field won't be added to the version. So now all fields in ProcessWire are supported, except for certain scenarios in PageTable and Table fields. A new version of the PagesVersionsPro module was released as well, and this is posted in the PagesVersionPro support board download thread here. This module made a lot of progress this week and will continue to evolve in the coming weeks. I'll copy/paste the version 2 changelog for it below this post. This weekend or early next week I also plan to release new versions of ProFields Table and Combo. These versions facilitate versions when doing partial save or restore operations that include file or image fields in Table or Combo fields. I hope that you and your family have a wonderful Winter/Christmas/Hanukkah/Festivus holiday! Version 2 changelog for PagesVersionsPro Added the ability to select which fields are included during a restore. When doing a restore, it now detects which fields differ between "live" and "version", making it easier for you to choose which fields to restore. When editing a version the “Delete” tab in the page editor now refers to deleting the version rather than trashing the page. The “compare” option has now been improved so that it can better detect differences between the live and version page. During restore, if you “Choose which fields to restore” you now have the option to compare them individually to see what is different between live and version. Added "page-edit-versions" permission so that you can limit the capabilities of this module to specific user roles.

Recently I transferred a website from WP to PW. First I had to clone the WP site in order to install it on a different hosting company. It turned out, that this WP installation (about 6 main pages and 20 subpages) with a few images, had the size of about 1 GB! This video helped me: https://www.youtube.com/watch?v=tIurrwfsCOg&list=LL&index=32&t=474s I found in the upload directory a lot of 7000px wide jpgs. Every time an image is uploaded, WP generates about 4 or 5 different size variations and keeps them all in the same directory. There were plugins installed, that all begged for an upgrade. Everywhere in the backend constantly informations from different sources popped up. After I finished the new website in PW, I compared the amount of the generated html code. The PW code was about 80% smaller.

If you click on the return value "PagesNames" you can get there. As to where / how I encountered it, it was from the "Name format for children" option in the ProcessTemplate edit page:

Back in the days when almost everything was build via tables in HTML you could actually use Photoshop to export your layout directly as HTML code. I used this for newsletter templates in the past. But beware, no one would ever design a page layout using tables anymore (at least I hope so...). Creating good designs is one thing and converting these designs in to a functional and responsive website is still really a piece of handcraft IMHO. So to answer your question: I use no AI helpers to turn those design files into working code. Too often you have to think around the corner "does this layout work on smaller viewports? How should the elements re-arrange, what elements should be hidden?" etc. etc. There is no way any AI can do that for me or for my clients - yet ?

Is it possible you have this in mind? https://processwire.com/api/ref/pages-names/page-name-from-format/

Recently hit the wordpress wall for the first time trying to help out a charity upgrade their WP-based site. Very troublesome.

Happy to announce the launch of the completely rebuilt San Francisco Contemporary Music Players website, using ProcessWire. https://sfcmp.org/ The previous website was a hornet's nest of disorganized content, dozens of 3rd party plugins, duct taped together within WordPress... difficult to use, time consuming and confusing to manage. And didn't look so good either. Lot of fun to rebuild this, though took several months. YOOtheme Pro and UiKit were a dream for me to work with, just love those. Made it so possible to create all of the custom sections, widgets, sliders, cards, mega menus, and so on. Don't consider myself a front-end focused web dev, so have a deep appreciation for the time, care and effort that Yoo has put into both UiKit and YOOtheme Pro. Almost no additonal CSS was needed to be written for this; the stock UiKit classes and attributes make it possible to just build things in HTML and not have to fiddle with CSS. Ryan's commercial modules played a major role in the build. ProFields, ListerPro, ProCache, and FormBuilder were all important. FormBuilder+Stripe allowed me to confidently migrate their need for a stripe checkout from some WP plugin to the clean and simple setup now using FB. ( https://sfcmp.org/donate/print-for-sale-dirge-by-hung-liu/ ) Some libraries also were of great use and value, namely PLYR for audio, and tabulator for some table display type of stuff. As always, the API was a dream to work with, many custom import scripts were created along the way to import legacy Press, Albums, Repertoire works, Program Booklets library, Players etc.. The image API is doing wonders with SRC sets, and webp images. The PW documentation site was a daily companion. This forum likewise was always a most valuable and enjoyable resource to search and rely on for solving the occasional conundrum. There is such a wealth of info here that i never found it necessary to post a question. Lastly, to underscore just how unparalleled, flexible and user-friendly the PW backend is, we had the backend training session a couple of weeks after the site was launched, and within 30 minutes, the person who will be managing the content was able to know how to create and manage concerts, blog posts, albums, press articles and more.