Leaderboard

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!

Let me share my story first, you will see why it's important for this discussion. I am a fullstack web developer and I have always found CMSes to be very limiting because usually, their philosophy plays a big part in what you can do and if at all, how it should be done. Most of them even force you into a lot of predefined concepts for the frontend, too. Take WordPress (which to be honest, is not a CMS at all), you start with posts, comments and pages and are stuck with a weird loop concept for the frontend in which posts always get a "special treatment". In 90% of cases if you want to use WordPress as a true CMS, you can only do that by disabling most of the predefined stuff outright and installing a crapton of extensions to just have some custom structures available. With ProcessWire, all of that is different. You start with a clean slate. No predefined content, no structures, no nothing. You can get some niche output with a site profile but changing just anything about the frontend of these site profiles takes you straight into the code. You can't install a plugin to have a fully-fledged shop, add some products and then install a $50 theme, upload the logo and change some colors and call it a day. You have this wonderful API which - as a developer - really is a godsent and allows you to create the most complex structures and have complete control and freedom in the frontend because it literally allows you to do whatever you want. And in the end, we can offer an editing experience to our clients which is a hundred times easier to understand and use than anything done with e.g. WordPress. I think that exactly is what PW's message on the homepage is: It is easy to use for developers while creating the project and easy to use for the clients of the developer when using the finished product. So, to go full circle: I think you are used to systems like WordPress, Squarespace or Wix and expect to have a working website after installing ProcessWire. But this is not the case since ProcessWire is taylored towards web developers. This is also why you need to learn at least a considerable part of the API to then go into the code and create your website, app, own API or whatever your project entails. I don't want do discourage you and seeing new people getting into PW is always a blast. But I fear that without coding, ProcessWire might not be the right choice.

Hello everyone. ? WordPress, Squarespace or Wix? Uh...not for me ? These commercial CMS, as powerful as they are, don't suit me and I generally use very simple CMS, Open-source and easily modulable to get my results but their rigid concept doesn't allow me to progress and it's exactly for the reasons you develop @poljpocket the arguments that I'm interested in PW that I only discovered a few days ago. Of course, my minimal skills in PHP or other programming languages are a hindrance but, as @Nicolas writes, "between the documentation, which is very well done, and the support of the community on the forum, you can make rapid progress". I'm counting on it and I'll finally be able to realize my dream of building a tool that will allow me to display my data as I see fit. ? That ties in with my initial post, which regretted that ProcessWire's communication didn't emphasize the fact that it's aimed specifically at developers or people working to become one. Now, it's also an opportunity to win over tinkerers of my kind who just want to go further, and that's what's so wonderful about ProcessWire, its documentation and its community. Thank you for your warm welcome. ?

Hello Ryan, hello everyone, I've just discovered ProcessWire and I'm delighted. :-) As a beginner with this CMS, I'd like to share one or two little thoughts that are important when discovering and evaluating this tool. 1/ I installed Softaculous for the first time, and the installer doesn't offer to integrate a site profile as with the latest version, which I downloaded and installed manually. It was by studying the documentation that I learned about the existence of profiles (and many other things) and the installation procedure and, if I hadn't spent time reading the tutorials, I'd never have understood the concept of profiles and templates which, incidentally, I still don't fully understand, but I'm working on it ;) All this to say that the beginner who installs with Softaculous has every chance of getting lost if he doesn't have the patience and motivation to read the docs first, which we never do when we test unknown CMSes in general. :-D By installing ProcessWire manually via FTP, it's already much better. Which brings me to point 2/ In the presentation of this CMS, it's repeated very often (too often) that it's simple, easy, within everyone's reach and, while it's true that someone with a bit of experience can manage it because the documentation and help systems are very well done, the lambda user who's used to CMS but isn't a developer will fear his own limitations. I myself am impressed by the quality and possibilities offered, but I feel very small when I read the various topics on these forums. How far would I go?) Having said that, I think this is a wonderful product and thank you all warmly for having invented it and maintaining it for everyone's happiness. :)

You can hook "saved" method. When you don't want to trigger hooks on a page save you can use: $page->save(options: ['noHooks' => true]);

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.

I can't reproduce this behaviour. Both return the page properly.

You can find here the release of wire-cli, successor to wire shell, a powerful command-line interface (CLI) tool designed specifically for ProcessWire developers. Optimize your workflow, automate repetitive tasks, and manage your ProcessWire projects with ease. Wire-cli leverages the Symfony Console Component to provide a robust CLI experience, offering a wide range of features and commands to enhance your development process. From creating new projects and managing fields, templates, roles, and users, to performing database backups and serving your ProcessWire projects with a built-in web-server. Still in development, there might be some glitch, I will continuously improve and expand its functionality based on the feedback and needs of the ProcessWire community. Also mentioning that we will be probably working towards merging the features of wire-cli and rockshell to provide a unified CLI solution for ProcessWire. To get started with wire-cli, check out the GitHub repository or simply install it now from your terminal using Composer: composer global require wirecli/wire-cli Contributions are welcome. If you encounter any issues or have suggestions for improvements, please submit an issue, a pull request or post it here.

This week we'll take a look at a newly released module that enables you to lock page fields or properties from editing on a page-by-page basis. Originally planned as a core feature, I found it worked just as well built as a focused module, so here it is. This post serves as both an introduction to, as well as documentation for this new module— https://processwire.com/blog/posts/page-edit-lock-fields/

In the last couple of weeks I've been working on the page versions support in ProcessWire (recap here and here). This week the new PagesVersions module was committed to the core. Though please consider it very much "beta" at this stage. Along with this, the core dev branch version was bumped to 3.0.232. The API reference page for PagesVersions is now live here: https://processwire.com/api/ref/pages-versions/. Note that the module is not installed by default, but once running 3.0.232, it can be installed by going in your admin to Modules > Wire > Pages > PagesVersions. In addition, a related development module named PagesVersionsPro has also been released. This module uses the new API from the core PagesVersions module. This module will eventually be merged with or replace ProDrafts. The new PagesVersionsPro support board and module is currently visible to ProDrafts, ProFields and ProDevTools subscribers here. Unlike ProDrafts, PagesVersionsPro gets all of its version abilities from the core, and instead just focuses on providing an interactive interface to them in the page editor. To word it another way, the module does not extend the PagesVersions module in the way that ListerPro extends Lister. Instead, it just provides a web interface for it. I think this is a better long term and more sustainable strategy for handling version support. Core version 3.0.232 also adds version support for nested repeaters and FieldsetPage fields. Support was added in those Fieldtypes directly. Still remaining are PageTable (core) and Table (ProFields), both of which will need their own implementations for versions like Repeater and FieldsetPage needed. But following that, there won't be any unsupported fieldtypes to my knowledge. ProcessWire Weekly published its 500th issue! Congratulations and big thanks to @teppo for his incredible work with ProcessWire Weekly, it is truly outstanding! Thanks for reading and have a great weekend!

Thank you for this module. Great addition. Now people who prefer to work more in the GUI can manage migrations with your module. The automatic recording feature looks interesting.

$page->save(options: ['noHooks' => true]); Nice! Didn't know that ? This should take care of your loop issue.

Yes, that's exactly what I had in mind too. Wordpress really drives me insane as a developer, but the fact that almost all the backend is in the clients language is one of the few things I envy when using ProcessWire. The advantage is that everyone can submit translations in a matter of seconds, when you're bored or just waiting for your train. No need to clone a repo, go through the source files and submit a PR. Core: https://translate.wordpress.org/locale/de/default/wp/ Plugins: https://translate.wordpress.org/locale/de/default/wp-plugins/

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

Just from skimming through the code, I can see that you are creating an exponential endless loop. You are hooking the saved event for a page and then - for every file field - saving said page again inside the hook. This will trigger another saved hook for every file field which will loop endlessly. I think this is why you are getting the out-of-memory error from your second post. I would try the saveReady hook to accomplish this. Don't call page->save() in there because you factually change the stuff before the page is ever saved (your changes will be saved automatically).

If you haven't yet noticed it, @teppo has hit the 500th issue of PW Weekly! That is a ridiculously massive milestone and an amazing achievement, and after some quick maths, also tells me that he's held strong for almost 10 years now! I'm not sure what's more surprising, that he's managed to keep it going continuously for this long, or that I remember when he started it... That's a long darn time. I may not be a hugely active member of the community, but I'm darn proud to be a part of it regardless. Thank you so much for your devotion to the PW Weekly project, @teppo!!!!

It also took me a while to understand drupal. In a nutshell: A template is called content type and instead of pages there are nodes. These nodes can be transformed into a page structure via a navigation module. The templating is also somewhat difficult and the structures are predefined. The advantage is probabely that the editor can create many things in the backend himself (e.g. with the views module). However, it is anything but intuitive or easy to understand and learn.

Parts of it, at least, yes! I've had for a very long time on my todo list a related idea; basically something like the https://translate.wordpress.org/ portal for WordPress. Though I didn't honestly even consider using pre-built solutions. I don't say this lightly, but this is an area where WordPress is way ahead ProcessWire, in my opinion. Just a few reasons why I think their system is so good: It's a shared, easy to use, web-based, non-developer friendly system. Whether I'm a contributor or someone wanting to install a translation for a plugin, I don't need to figure out how author of plugin x wants to handle their translations, and I also don't need to know or figure out how to create a GitHub account, open pull requests, etc. This point alone is a major benefit and lowers the bar for contributing ? Just for the record, many plugins still bundle translations with the source code. So yes, both systems can co-exist. Anyone can contribute without core/theme/plugin author(s) having to do anything. I for one have access to Finnish translations for a few plugins. Permissions are handed down by general translation editors for the locale, which is much easier than having to contact individual plugin authors who may or may not be around and active, and may or may not be interested in bundling some language they have no personal interest in. Once a locale has enough coverage, it automatically becomes installable via the admin and via WP-CLI. Personally I use WP-CLI for managing site translations, as it makes things a lot easier to automate. Installing and updating translations is literally one command away, which — as someone who manages quite a few sites — is a big bonus. This, of course, only works for plugins that have been translated this way. Not all have. It's not a perfect world. Finally, the system handles versions properly. For an example if I wanted to submit a correction for the Finnish translations for ProcessWire version 3.0.184, there's no easy way to do that. Maintainer of the Finnish translations repository could set up separate branches or some other way to handle it, but this would be a case by case thing, and there's no guarantee that the language pack maintainer is interested in such a thing. In the past I've also contributed via Launchpad, which (at least back then) was essentially the same thing for free / open source software, and worked really well in my opinion. Anyway, I'm still interested in this idea, but have not had time to pursue it myself. Maybe one day, unless someone else solves it properly before me ? In my opinion it is a viable idea, but there are many questions to answer, and quite a few of those are not straightforward. Also I believe that in order to gain traction this would need to be somehow integrated into our current translation tool(s) and it shouldn't be too opinionated (for an example I personally would prefer it to not update anything completely automatically, as was suggested here earlier.)

Not sure exactly what you are wanting to achieve but, if it helps, here is some code I used to hook User::hasPagePermission. Obviously the context is specific to my app (a membership system), but maybe there are some useful ideas. /** * PAGE PERMISSIONS * Allow member users to edit etc. pages relevant to them (access via AIM in My NCOG) **/ wire()->addHookAfter('User::hasPagePermission', function(HookEvent $event) { // Get the object the event occurred on, if needed $user = $event->object; // An 'after' hook can retrieve and/or modify the return value $return = $event->return; // Get values of arguments sent to hook (if needed) $permission = $event->arguments(0); $p = $event->arguments(1); /* Your code here, perhaps modifying the return value */ // Is it a page we need to customise access for? $templates = ['Membership', 'Member', 'Profile', 'Subscription', 'Payment', 'MemberShop', 'Booking', 'NewsItem']; $permissions = ['page-edit', 'page-add']; $currentUser = $this->users->getCurrentUser(); if ($p and in_array($p->template, $templates) and $permission and in_array($permission, $permissions)) { if ($currentUser and $currentUser->isLoggedin()) { $this->log->save('debug', 'In hasPagePermission hook for Page = ' . $p . ', Permission = ' . $permission . '. Current user is ' . $currentUser); if ($currentUser->hasRole('member')) { $email = $currentUser->email; $memberPage = ($email and $email != '') ? $this->pages->get("has_parent=/memberships/, template=Member, email=$email") : null; if ($currentUser->memberOnly != 0) { $return = false; $this->log->save('debug', 'Member only'); } // Member-only users can only access pages as defined below // Admin members will also have their normal permissions if ($memberPage and $memberPage->id) { $membershipPage = $memberPage->parent; $this->log->save('debug', 'Membership page = ' . $membershipPage->id); $profilePage = $membershipPage->id ? $membershipPage->get("template=Profile, include=hidden") : null; $siblings = $memberPage->siblings("template=Member, include=hidden"); // includes member page itself $shops = $membershipPage->id ? $membershipPage->find("template=MemberShop, include=all") : null; $currentSub = $membershipPage->id ? $membershipPage->latestSubscription() : null; $subsPaymentPages = $membershipPage->id ? $membershipPage->find("template=Payment, parent=[template=Subscription], include=hidden") : null; $draftNewsPages = $membershipPage->id ? $memberPage->find("template=NewsItem, include=all") : null; $bookingPages = $membershipPage->id ? $membershipPage->find("template=Booking, include=hidden") : null; $editablePages = new PageArray(); $addablePages = new PageArray(); $editablePages = $editablePages->add($membershipPage)->add($profilePage)->add($siblings)->add($currentSub)->add($shops)->add($subsPaymentPages)->add($draftNewsPages)->add($bookingPages); $addablePages = $addablePages->add($membershipPage)->add($memberPage); // pages where creation of children is allowed $this->log->save('debug', 'Editable pages = ' . $editablePages->implode(', ', 'id')); $this->log->save('debug', 'Addable pages = ' . $addablePages->implode(', ', 'id')); if ($editablePages->has($p) and $permission == 'page-edit') $return = true; if ($addablePages->has($p) and $permission == 'page-add') $return = true; } } $retStr = $return ? 'true' : 'false'; $this->log->save('debug', 'Returning ' . $retStr); } } // Populate back return value, if you have modified it $event->return = $return; });

Source: https://processwire.com/blog/posts/processwire-3.0.107-core-updates/#trash-for-all