Leaderboard

This week we have ProcessWire 3.0.192 on the dev branch. This is about 20 commits ahead of the previous version and contains 11 issue fixes and 5 pull requests, along with various other updates. PR code contributors in this version including Daun, MrSnoozles, Radon8472, BernhardBaumrock and Tyde. Thanks! For more details see the dev branch commit log. In addition to core updates, in recent weeks I've also been working on a new module similar to the PageAutosave (developed for the admin) except that it is for front-end forms. It works with any front-end form (whether home brewed or from something like FormBuilder) and remembers the entered form values every time a field is changed. If the user doesn't submit the form, they get an email with a link to finish filling out the form after a configurable period of time. This is especially nice for order and reservation forms. Accompanying the module is a separate Process module that lets you view all the forms in progress in the admin. Each form entry has its own unique URL, making them easy for users to return to, from any device. Once the user submits the form, the data gets removed from the pending submissions database. This is something I've been meaning to develop for awhile, and with the admin PageAutosave module still fresh on my mind, I thought now was a good time to do it. Thanks for reading, Happy New Year and have a great weekend!

Please do, I'd be very interested to read that! It seems like this should be doable via a module in PW. I have a work-in-progress module that does something like this. It's not complete and haven't looked at it a while but it seemed like a promising avenue at the time. I think if the concept could be illustrated in a module then Ryan might see the benefits and then hopefully incorporate the features into the core. Seeing as you've clearly spent some time thinking about these issues, would you mind writing up a wishlist of what things you think PW should handle via files for the sake of version control? Fields and templates are the obvious things but you also mentioned translations which I wouldn't have thought of (I only work on single language websites) so it would be great to have a comprehensive list of problem areas for version control. Thanks in advance! ?

Hello all, Since https://processwire.com/docs/tutorials/using-custom-page-types-in-processwire/ came out, I used to implement custom page classes as modules, following the principles described in that tutorial. Now only a few weeks ago I stumbled across https://processwire.com/blog/posts/pw-3.0.152/#new-ability-to-specify-custom-page-classes. This seems to me a much cleaner and easier way of implementation. Though it restricts the naming of custom classes to the naming conventions for the class loader. Other than that I can't really see any more disadvantages. Which way do you prefer and why? On a side note, useful features like described in the second link often can only be found in @ryans core update blog posts. If you don't read them on a regular basis, those new features are easy to miss. I'd love to see those hidden gems find their way into the API reference in more detail. Although $config->usePageClasses is documented at https://processwire.com/api/ref/config/, I think it would deserve its own page with all the explanations from the blog post.

ProcessPageAdd preselects the template according to these principles: If there is already one or more child pages under the parent then it preselects the same template as used by the most recently added child page. If there are no child pages it preselects the same template as used by the parent page. But if that template isn't allowed to be used under the parent page then no template is preselected. So probably you recently added a page using the template that is only used in 5% of the cases, or that is the template of the parent page. You can force a particular template to be preselected in a couple of ways. 1. You can add a "template_id" GET variable to the URL of the "Add New" page. Example: "/processwire/page/add/?parent_id=1234&template_id=29" This might be a good approach if you are constructing your own custom link to the "Add New" screen but not so useful if you are just adding a new page via the standard PW admin. 2. You can use a hook in /site/ready.php to set a template_id GET variable to $input: // Before the ProcessPageAdd form is built $wire->addHookBefore('ProcessPageAdd::buildForm', function(HookEvent $event) { $input = $event->wire()->input; // Get the parent page the new page is being added under $parent_id = (int) $input->get('parent_id'); $parent = $event->wire()->pages->get($parent_id); // Return early if a single parent page isn't available or valid if(!$parent->id) return; // Do whatever check you need to identify if this is the parent you want to target if($parent->template == 'home') { // Get the template you want to be preselected $child_template = $event->wire()->templates->get('basic_page'); // Set the template ID to the "template_id" GET variable $input->get->template_id = $child_template->id; } });

@adrian Last year we've started using Craft CMS for some new projects, which has full support for version control out of the box. In terms of feature set it's quite similar to ProcessWire – you can define your own fields and entry types (similar to ProcessWire templates) and create custom field layouts. It's not a flat-file system, it does use a database. It also provides an API similar to ProcessWire's $pages to query for entries (pages) or other data. To keep track of schema changes, Craft saves all fields and entry type (and every other setting / config) as YAML files in a config folder. Those can be version controlled, merged and reasoned about easily. You can even read a pull request in Github and see what changes it introduces to field/entry type settings, it's great. It's called project config, here's the documentation. Particularly pleasant is that you can still use the backend to create fields and field layouts – every change in the backend is automatically written to the config folder. So you can just create field layouts in the backend and everything you need to track it in git is already there when you're done. To propagate changes between environments, the CLI has commands to apply the project config to the current environment (database). I was thinking about writing a comparison between ProcessWire and Craft CMS regarding feature set, support for version control and development experiences. There are some good ideas there that ProcessWire could really benefit from. BTW, if you want to track content in git as well as configuration – we also looked at Statamic, which does support flat files and can commit every backend edit to git. Haven't tried it though. @szabesz Not sure if it's that easy, making every aspect of ProcessWire version control friendly would require massive reworks. Including making ProcessWire and it's module installable through Composer and reworking the directory structure to have a better distinction between content and config, as well as dependencies and custom code. This would need to be ProcessWire 4 (at least). Not sure this can be done if ryan isn't looking to put massive amounts of work into this. I don't have the impression that this is the direction ProcessWire is going – though I'm happy to be proven wrong.

Things that I came across about creating/editing pages with the api: 1) Set output formatting state off, for page manipulation $page->of(false); 2) First save page in preparation for adding files e.g. an image $p->save(); So allow me to add 1) here to improve the above example code: <?php if($input->post->submit) { $p = new Page(); $p->of(false); $p->template = "template_to_save_form"; $p->parent = $pages->get("/parent-page/"); $p->title = $input->post->name . " - " . date("Y-m-d"); $p->submitted_by = $input->post->name; $p->message = $input->post->message; $p->save(); }

@kongondo Thanks, yesterday I was assuming the wrong thing and just enabled URL segments on the home template. Seeing so many TBDs I have not reached the end of the read me, sorry for that. Now I also see that you mention this topic over here too: https://docs.kongondo.com/frontend.html As for the About page, I did not even notice that yesterday. I just created a product, wondered why the product page is 404 then went to bed. BTW, this starter profile is really useful even though it needs more work, but quite enough to learn the basics.

/site/modules/MyModule /site/modules/MyModule/classes /site/modules/MyModule/classes/MyPageClassOne.php /site/modules/MyModule/classes/MyPageClassTwo.php /site/modules/MyModule/MyModule.module.php The module: <?php namespace ProcessWire; class MyModule extends WireData implements Module { public static function getModuleInfo() { return [ 'title' => 'MyModule', 'version' => '0.0.1', 'summary' => 'Your module description', 'autoload' => true, 'singular' => true, 'icon' => 'smile-o', 'requires' => [], 'installs' => [], ]; } public function init() { $this->rm()->initClasses(__DIR__."/classes"); } /** * @return RockMigrations */ public function rm() { return $this->wire->modules->get('RockMigrations'); } } The class: <?php namespace ProcessWire; class MyPageClassOne extends Page { public function init() { $this->wire->addHookAfter("Pages::saveReady", $this, "onCreate"); } public function onCreate(HookEvent $event) { $page = $event->arguments(0); if(!$page instanceof self) return; if($page->id) return; $page->status = 1; // auto-publish this page $this->message('Auto-published page '.$page->path); } } initClasses() will not only load your custom page classes but also trigger the init() method once. That makes it possible to attach all kinds of hooks that belong to the custom page class where they belong: Into the page classe's php file. You avoid hook-hell in ready.php like this. It will load one instance of your page class on every request though. You can also use custom namespaces easily: // in the module: $this->rm()->initClasses(__DIR__."/classes", "MyNameSpace"); // your page class: <?php namespace MyNameSpace; use ProcessWire\Page; class MyPageClassOne extends Page { ... } You don't need to use RockMigrations for that. You can have a look what initClasses() does. You could also just set the page class on the template. I don't know if that can be done manually but using RockMigrations it is just setting one property of the template: 'my_template' => [ 'fields' => [...], 'pageClass' => ..., ]

I realise the demo site README was not clear enough, apologies. Did you create the pages products and categories under /home? Have you enabled URL segments on the templates products and categories? Edit: I notice even your /about/ page is not working. Do you have that page?

Thank you very much! The solution with the ready.php worked perfectly! ?

@gornycreative - if I understand correctly, this should work. $searchEngine->addHookAfter('Renderer::renderTabLabel', function($event) use($types) { $event->return = $event->return . 's'; }); I was modifying the tabs a little more via a $types associative array, which you can see here. Just for fun I also included the hook I used to add images to the results. In the end I actually stopped using the built in tabs feature because even though it's really awesome, it doesn't work with multiple operators like: *=~= so I built up the tabs manually and now I can even change the operator if the user has wrapped something in double quotes to make it an exact match.

Sorry I missed your second post... Actually something similar would already be possible using RockMigrations. At least for basic setups. I'm not sure how that can work for more complex setups though. I'll try to explain that by an example: Let's say we created a new blog module. We need a blog page (parent) and several blog-items (children): - home '- blog |- blog entry 1 |- blog entry 2 ... This setup could easily be built into a module using rockmigrations: <?php namespace ProcessWire; class MyBlog extends WireData implements Module { public static function getModuleInfo() { return [ 'title' => 'MyBlog', 'version' => '0.0.1', 'summary' => 'blog module using rockmgirations', 'autoload' => true, 'singular' => true, 'icon' => 'smile-o', 'requires' => [], 'installs' => [], ]; } public function init() { $this->rm()->fireOnRefresh($this, "migrate"); } public function migrate() { $this->rm()->migrate([ 'fiels' => [...], 'templates' => [ 'blog_parent' => [...], 'blog_item' => [...], ], ]); $this->rm()->setParentChild('blog_parent', 'blog_item'); // --> this sets the family settings for both the parent and the child template - how long does that take by hand? ;) It means that all pages having the "blog_parent" template will create a "blog_item" page automatically when you click on "add new page". Basically the stuff that you set on the family tab of the template. } /** * @return RockMigrations */ public function rm() { return $this->wire->modules->get('RockMigrations'); } } That means I'm literally defining my config in the module code. We could also have the config read from a config.yaml - that would really be the same (just less powerful IMHO)! The problem arises when you want to make that config customizable. For example you want a page reference field to select the author for every blog post. Building that into the blog module would probably not be a good idea because not every site might need such a field. What I do in such situations is this: I make the migrate() method hookable and create one module that handles all the project-specific stuff: <?php namespace ProcessWire; class MyProject extends WireData implements Module { public static function getModuleInfo() { return [ 'title' => 'MyProject', 'version' => '0.0.1', 'summary' => 'module that handles site specific stuff', 'autoload' => true, 'singular' => true, 'icon' => 'smile-o', 'requires' => [], 'installs' => [], ]; } public function init() { $this->addHookAfter("MyBlog::migrate", $this, "migrate"); } public function migrate(HookEvent $event) { $this->rm()->createField("author", "page", [ 'label' => 'Select the author', ... ]); $this->rm()->addFieldToTemplate("author", "blog_item", "title"); } /** * @return RockMigrations */ public function rm() { return $this->wire->modules->get('RockMigrations'); } } That means you can have your blog module that you can reuse from project to project (and improve it and just pull changes if you need to) and you can still customize it the ProcessWire way (which we all love I guess). BUT Now we got a new field on the "blog_item", the "author" field. So the config.yaml of the blog module would change, wouldn't it? I'm not sure how CraftCMS handles such situations? And that's one of the reasons why I think that efforts like this are going in a wrong direction. It sounds intriguing for sure to have something like a "migrations recorder". I'm working or at least thinking about that since 2016. But I simply can't imagine a way that could reliably work in all situations. RockMigrations does. And it does it really well. And it does it for almost 3 years now and has evolved a lot. It's still not perfect for sure. But I don't think that This feels wrong. I'dont know how to explain. I think you have a good understanding of composer and such things. Likely a much better understanding than I have. So if it is true what you are saying, I must be doing a lot wrong in my daily work or at least I must be understanding a lot wrong... Because a lot of my workflows do feel very version control friendly. And I've lately started working in a company in vienna where we work on ProcessWire projects with fully automated workflows. We work in a team. We work on different local machines. We deploy to staging and if everything works (which has been the case 100% so far), we deploy to production with a single click. But maybe I'll change my opinion some day and look back and laugh. Maybe I should just try CraftCMS. Maybe many other fancy new tools. At my company they also work (or worked) with another CMS. They said they liked to be able to define fields and templates in code. They said that was one of the (few) things they didn't like about ProcessWire, because they love professional workflows and automated deployments... But they also admitted, that it was somewhat painful to define fields and templates in the other CMS. They said you have to add pieces of config in that file, then change another piece in another file. And end up changing many files for simple changes. Now they like RockMigrations ? And such comments make me think I am on a right track and we as ProcessWire enthusiasts are not that far away from what you seem to be missing. @MoritzLost have you ever heard someone saying "ProcessWire is great for small websites, but not for larger, more complex ones"? We all know how wrong that is, don't we? That's the way I feel when people here on the forum are talking about missing migration / version control features... PS: I tried to keep this post short and not so emotional. I think I failed, sorry ?

@dotnetic Hi I use docker containers everywhere. I my localhost develepoment environment I have docker stack yaml defining the containers and also the environment variables (can be included from external file). And in production I use AWS ECS, where you can specify env vars in many ways. If need more details just ask.

Yes <?php $rm->migrate([ 'templates' => [ 'car' => [ 'fields' => [ 'title' => [ 'label' => 'Name of the Car', 'columnWidth'=>50, ], 'km' => ['columnWidth'=>50], ], ], ], ]); voila. fields "title" and "km" will be 50% width in the car template context. the title field will have a custom label on the car template. It's really that simple most of the time! Change some properties, commit, push, done! What are you missing? Depends. Both are possible. RockMigrations is really also great if you add it later on a project that did not handle migrations before. It really does not care. For example you could add this in your ready.php: <?php $rm = $modules->get('RockMigrations'); $rm->createField('test', [ 'type' => 'text', 'label' => 'Testing RockMigrations', ]); // add field test to home template after the title field $rm->addFieldToTemplate("test", "home", "title"); You'll have your test field right after the title field of the home template. You can do the same for everything you add to your site. Doing it like this, of course, the migration will run on every page request. The great thing about the migrations is that this will just work! It's not ideal of course, but I just want to show how it works. Add another field? Here we go: <?php $rm = $modules->get('RockMigrations'); $rm->createField('test', [ 'type' => 'text', 'label' => 'Testing RockMigrations', ]); $rm->createField('test2', [ 'type' => 'text', 'label' => 'Testing RockMigrations again', ]); $rm->addFieldToTemplate("test", "home", "title"); $rm->addFieldToTemplate("test2", "home", "test"); Now we got two fields. Ok, we want those fields in a row? Lets refactor this (it would be possible using the syntax from above as well, but I just prefer the array syntax as it has everything in place): <?php $rm = $modules->get('RockMigrations'); $rm->migrate([ 'fields' => [ 'test' => [ 'type' => 'text', 'label' => 'Testing RockMigrations', ], 'test2' => [ 'type' => 'text', 'label' => 'Testing RockMigrations again', ], ], 'templates' => [ 'home' => [ 'fields' => [ 'title' => ['columnWidth'=>33], 'test' => ['columnWidth'=>33], 'test2' => ['columnWidth'=>33], ], ], ], ]); Commit, Push, Done. So do you really think manually creating those fields was quicker? Even if you create those fields remotely first and then pull a DB dump and you have at least semi-automated the process and a dump takes "only 15 seconds or so"... I bet migrations are quicker, more versatile, more powerful. Let's say you want to tidy up your project a little bit. Let's add tags for those two test fields: <?php $rm = $modules->get('RockMigrations'); $rm->migrate([ 'fields' => [ 'test' => [ 'type' => 'text', 'label' => 'Testing RockMigrations', 'tags' => 'RockMigrationsTests', // <----- add this ], 'test2' => [ 'type' => 'text', 'label' => 'Testing RockMigrations again', 'tags' => 'RockMigrationsTests', // <----- add this ], ], 'templates' => [ 'home' => [ 'fields' => [ 'title' => ['columnWidth'=>33], 'test' => ['columnWidth'=>33], 'test2' => ['columnWidth'=>33], ], ], ], ]); Thats it! Both fields live under that new tag: Nice and clean! Ok, now let's remove those changes: The IDE will help you find the right method... So we can do: /** @var RockMigrations $rm */ $rm = $modules->get('RockMigrations'); $rm->deleteFields("tags=RockMigrationsTests"); $rm->setFieldData("title", ["columnWidth"=>100], "home"); How long would it take you to delete those two fields manually? Making sure that all checks are met ("you can't delete this field... it is used by XX templates..." *#*&!), going back to the templates editor, removing the field first, then deleting the field, then going back to the home template and setting the title field back to 100%... I don't know the exact workflow - I haven't done that for a long time now ? Yeah and we are not even talking about doing those changes in a team... Have fun ? Yeah, @adrian, I know Tracy can help. Just trying to show how quick you can get when doing things using RockMigrations. Of course there are some situations where you might not know the properties you need to set. But Tracy can help you. Or you inspect the inputfield and lookup the name in your devtools. The nice side effect: You learn a lot about PW and you will understand it a lot better and improve even more. Well... I don't know what more to say. I feel your pain, but I don't really understand why there are many here "complaining" about those missing features of ProcessWire but nobody seems to be using RockMigrations or seems to have given it an hour or two to simply try it out... ?‍♂️ PS: I know the example runs migrations on every page request, which is not ideal. You can come up with your own strategy to prevent that or you can simply use $rm->fireOnRefresh() so migrations will only fire on modules::refresh I'm maybe similar. There's not a single new project not using RockMigrations and custom PageClasses now. It might be overkill for some, but I think for people that are asking questions that you are asking RockMigrations is just the right tool and you are missing something. That would be a pity. We need more people like you here ? Sometimes life as a developer is hard. But we get paid for that ?? I agree on that. I'm working on it and I wished more were doing so ? Why not? I agree it's not perfect, but I've put hard work into making this possible over the last years. And I think I've come very far. I don't know much other systems though, so I might be on the wrong track. If you know any better systems I'm just as happy to hear about them as @adrian

The good thing that the most important bits needed by native migration features are there. The bad thing is that it is not completely automated. If you already spotted the missing bits, maybe you (including Horst, since he does something similar) could cooperate with Ryan on implementing the "rest"? I am asking this because I am planning to apply this method as well in the future.

I'd love to know your favorite PW alternative - if something else exists with all the features, flexibility and ease of PW which also has full compatibility with version control, that would be perfect. Surely it would require a flat file database, but even that has its problems when it comes to data querying, doesn't it?

Thanks everyone for the insights! Nice to see all the different approaches, and that I'm not the only one struggling to find a 'perfect' solution … @bernhard Thanks for this. Look real close to a version-controllable schema config. Can the array syntax for fields/templates handle field overrides in a template context as well? What about settings that are environment-specific, like specific parent pages in page reference fields? How would you approach an existing site that doesn't use migrations – add all the existing fields to one big migration file? Or include a database dump as the base state and perform all further changes in the form of migrations? You're right, doing everything manually is a pain. But handling everything in code is a pain as well. The problem for me is that too many areas of ProcessWire are not built with version control in mind. Migrations solve field/template configuration. But then you need to keep track of installed modules, if you want to install modules with Composer you need custom config so they're installed in the right folder. Of course you can't put the entire modules folder in gitignore, since site-specific modules go into the same folder. And what about ProcessWire itself, I don't want the entire core in my version control. So again, custom download script. The list goes on. You don't want to keep track of uploaded files, so the asset folder goes into gitignore. But I do want translations in my version control, turns out those are in random directories in the assets folder … the list goes on. There are just so many small issues if you want a 'complete' version controlled ProcessWire site, which to me means (1) the site can be rebuilt completely from the repository alone and (2) there's no external code or dependencies. And if you solve all of these with scripts, those become hard to manage and even harder to enforce in a team … not sure where I'm going with this to be honest ? I'm a bit of an all-or-nothing person, if I can't have 'clean' version control I'd rather not have version control at all. Probably unwise. To be honest, for new projects I'm currently settled on option 3: to not use ProcessWire at all, unless the project won't require any significant updates after launch. Even all the problems mentioned above can be solved one way or another, it's just not worth it compared to other systems where I get full compatibility with version control by default. I don't think this will change as long as ProcessWire doesn't support version control natively. @horst Yeah, that's close to what I'm doing for updates as well. As long as you're keeping track of any field/template changes diligently, it's not too much work. Though it still bugs me doing the same thing twice. And of course it doesn't solve the problem of working on an update with multiple people at the same time. @szabesz We do that for significant updates to older projects where we don't have development versions any more. Though it means the client can't edit anything while updates are being done, and it doesn't work for sites with user-generated content or user accounts where you can't just freeze the live database for a larger amount of time … @elabx So all your sites are identical in feature set? That definitely doesn't apply to our projects ? The point regarding bitbucket pipelines is interesting. Though I'm hesitant to use automated deployments if I have too write too much custom logic for it or mix partially automated deployments with manual steps. Too error-prone and difficult to enforce in a team, in particular if you want to work on site updates with multiple people …

Once my PRs are approved the latest version of this module will make it possible to set the main color via an inputfield:

I didn't read the whole topic, so hope I guess corretly what is it about. I add my approach to having different configs for each environment. I did it very simple, just used environment variables, so I have one configurable config for all ? (I am using docker on localhost so it is easy to work with environment variables) <?php namespace ProcessWire; /** * ProcessWire Configuration File * * Site-specific configuration for ProcessWire * * Please see the file /wire/config.php which contains all configuration options you may * specify here. Simply copy any of the configuration options from that file and paste * them into this file in order to modify them. * * SECURITY NOTICE * In non-dedicated environments, you should lock down the permissions of this file so * that it cannot be seen by other users on the system. For more information, please * see the config.php section at: https://processwire.com/docs/security/file-permissions/ * * This file is licensed under the MIT license * https://processwire.com/about/license/mit/ * * ProcessWire 3.x, Copyright 2019 by Ryan Cramer * https://processwire.com * */ if(!defined("PROCESSWIRE")) die(); /*** SITE CONFIG *************************************************************************/ /** @var Config $config */ /** * Allow core API variables to also be accessed as functions? * * Recommended. This enables API varibles like $pages to also be accessed as pages(), * as an example. And so on for most other core variables. * * Benefits are better type hinting, always in scope, and potentially shorter API calls. * See the file /wire/core/FunctionsAPI.php for details on these functions. * * @var bool * */ $config->useFunctionsAPI = true; /*** INSTALLER CONFIG ********************************************************************/ /** * Installer: Database Configuration * */ $config->dbHost = getenv("DB_HOST"); $config->dbName = getenv("DB_NAME"); $config->dbUser = getenv("DB_USER"); $config->dbPass = getenv("DB_PASS"); $config->dbPort = getenv("DB_PORT"); $config->dbEngine = 'InnoDB'; /** * Installer: User Authentication Salt * * This value was randomly generated for your system on 2021/12/14. * This should be kept as private as a password and never stored in the database. * Must be retained if you migrate your site from one server to another. * Do not change this value, or user passwords will no longer work. * */ $config->userAuthSalt = getenv("USER_AUTH_SALT"); /** * Installer: Table Salt (General Purpose) * * Use this rather than userAuthSalt when a hashing salt is needed for non user * authentication purposes. Like with userAuthSalt, you should never change * this value or it may break internal system comparisons that use it. * */ $config->tableSalt = getenv("TABLE_SALT"); /** * Installer: File Permission Configuration * */ $config->chmodDir = '0755'; // permission for directories created by ProcessWire $config->chmodFile = '0644'; // permission for files created by ProcessWire /** * Installer: Time zone setting * */ $config->timezone = 'Europe/Prague'; /** * Installer: Admin theme * */ $config->defaultAdminTheme = 'AdminThemeUikit'; /** * Installer: Unix timestamp of date/time installed * * This is used to detect which when certain behaviors must be backwards compatible. * Please leave this value as-is. * */ $config->installed = 1639521804; /** * Installer: HTTP Hosts Whitelist * */ $config->httpHosts = preg_split('/\s*,\s*/', getenv('HTTP_HOSTS')); /** * Installer: Debug mode? * * When debug mode is true, errors and exceptions are visible. * When false, they are not visible except to superuser and in logs. * Should be true for development sites and false for live/production sites. * */ $config->debug = filter_var(getenv("DEBUG"), FILTER_VALIDATE_BOOLEAN); $config->advanced = true;

Haha yeah, sorry, I forgot to supply getCommentByID with the $page and $field arguments… Glad you got it working, happy New Year to you too! Regarding comment editing, have you considered just rolling your own comment system with Pages (maybe even custom page classes) or multi fields like Repeaters? That would allow you to use common ProcessWire skills instead of fighting this specific module.

Happy New Year! Hope that you all have a great end to 2021 and start of 2022. No major core updates to report this week, just a few minor issue fixing commits, so no version bump today. The dev branch is getting close to 100 commits (and at 7 versions) above the master branch, and with even more improvements/fixes/optimizations than that. So we may try to get a new master/main version out in early 2022, as I'd really like to get more master versions out in 2022 than we did in 2021. Some portion of our audience does not use the dev branch where most of the activity happens, and so it might be nice to share more of that activity on the master/main branch. That's one of many things I'm thinking about as the New Year approaches and am certain 2022 is going to be a great year for ProcessWire and the community. Hope that you have a great weekend and Happy New Year!

I wish everyone a good start into the new Year. To round up this year I released v0.10.0. The library is runnable as intended in a ProcessWire Environment and fully testable in Standalone mode for developing. Symprowire Release v0.10.0 - Backpain I will publish a demo implementation next year. Hope it will be of use for some of you guys.

OK, so as promised, for a use-case with Functional Fields, here's a simple code example and a screenshot how it might look like in the backend: __fieldset('plain,textarea,rich,hello', 'jsStrings', 'Javascript Strings'); // $pages->get(1044)->functional->plain // how you would get it from anywhere in your templates and pages echo "<p>" . __text('your plain text', 'plain', 'Label Text for Plain Text String') . "</p>"; // $pages->get(1044)->functional->textarea // how you would get it from anywhere in your templates and pages echo "<p>" . nl2br(__textarea('your textarea text', 'textarea', 'Label Text for Textarea')) . "</p>"; // $pages->get(1044)->functional->rich // how you would get it from anywhere in your templates and pages echo "<div>" . __richtext('<p>your richtext</p>', 'rich', 'Label for WYSIWYG') . "</div>"; echo "<div>" . __richtext('<p>Hello Wörld!!!</p>', 'hello', 'Label for Hello World') . "</div>"; This is how it looks like in the backend. The big advantage imho is that you have the familiar user interface you're used to when you are also in charge of creating or editing PW-pages. It all seems familiar, and if you have a multi-lang setup, you can edit it all without page-reloads and navigating to another language.

Or you modify your pagenames (eg john-doe-url) then you can use the URL segment and append the "-url" to your filter. In general it is often a good idea to have all persons under one parent and do the grouping via pagefields (or select options). But maybe it's better like you did in your case. This was just my experience

@modifiedcontent Say you have the following form <form method="post"> <input type="text" name="name"> <input type="textarea" name="message"> <input type="submit" name="submit"> </form> You can save it to a page like this <?php if($input->post->submit) { $p = new Page(); $p->template = "template_to_save_form"; $p->parent = $pages->get("/parent-page/"); $p->title = $input->post->name . " - " . date("Y-m-d"); $p->submitted_by = $input->post->name; $p->message = $input->post->message; $p->save(); } You'll have to create the template, its fields and the parent page first. Also before saving the page make sure to validate/sanitize the input. <?php $p->submitted_by = $sanitizer->text($input->post->name); // instead of just $p->submitted_by = $input->post->name; https://processwire.com/api/ref/sanitizer/