artfulrobot

@zoeck Being physically able to do something is not the same as legally/ethically being able to do something. I haven't found the license that pro modules are provided under, but Ryan makes it clear they are not open source, so your rights are unknown. Common sense says that I'm quite sure he doesn't mind anyone making changes to their local copy but that I'm quite sure he would mind if someone started sharing the code/modified versions of it, or even selling it! My interest in open source code is primarily sustainability - code that is openly shared/forked, has good leadership as part of an active team of developers, welcomes contributions. A closed product only exists as long as it is in the interests of its owner. If Ryan, God forbid, were to have a change of fortunes/interests, and shut shop, the open source code could be picked up by an interested community of developers and all our websites and services based on PW stand a chance of a future. The closed source products could not - legally - be continued. My biggest reservation in using ProcessWire is the business risks posed by its BDFL model / single point of failure in general and moreso with the pro modules. My interest in this forum post, however, was just how to give Ryan a modest donation to help fund his excellent continued work! I'll try reaching out directly/via contact-form on website as @Krlos suggested.

I really appreciate ProcessWire as an open source CMF/CMS. I have used it for 3 websites now. I understand that the Pro modules are a way to support the project, however I do not want to use any proprietary code because it feels like a backwards step; I like being able to use, bend, fix, study, share the software I use, and I actively contribute to dozens of such projects. Is there a way I can make a donation to the work of the project without buying a Pro module?

Thanks for taking the time to write this up and share, interesting read! I've been using some htmx on a processwire site recently, too, but you've gone much deeper into HTML integration than I did. To be honest I'm still not won over by htmx's "pretty much everything requires a server request" norm as it seems like excessive load and traffic in many use cases. And I did struggle a bit with multi-stage forms where pages may be used in different orders (I basically implemented a state machine flow). I'd be interested to see more of your implementation for interest/learning 🙂 as I'm into the idea of minimal no-build-step JS libs these days. It's also nice to revisit the idea that a site works without javascript, though I can't say I'm achieving this yet. So if you do have public access to view your code, please do drop a link here.

@BitPoet Wow thank you, that worked! I note that: you used ready not init. This makes sense; ready fires after all the installed modules have initialised, and we need ProcessWire to know that the InputfieldSelector module exists before adding a hook, presumably. (Note that your code worked for me using init() instead which I tested to see. I guess this is at risk of a race condition though; if my module loaded before InputfieldSelector did, it might not work). You hooked InputfieldSelector not the parent Inputfield yours worked, mine didn't, so I guess we're not allowed to hook on parent classes? This is a great example of how flexible ProcessWire is. And how much I've yet to learn! Very grateful for your time responding to this and sorry I didn't see it sooner (note to self: check my notification settings!).

I have a selector field and I need it to be able to select User templates, but User is hidden because it's a system template. I thought I could make this change with a hook, but I have not been successful. To try, I made a new module (single, auto load) and in its init() method I added code like this: class MyCustomModule extends Process implements Module { ... public function init() { $this->wire->addHookBefore('Inputfield::getConfigInputfields', function (HookEvent $event) { $this->wire->log('getConfigInputfields Fired', ['name' => 'testHooks']); }); $this->wire->addHookBefore('InputfieldSelector::init', function (HookEvent $event) { $this->wire->log('InputfieldSelector::init', ['name' => 'testHooks']); }); } ... } I thought that if I hooked into when an InputfieldSelector got instantiated, I could check whether it was the field I wanted to target and if so, make the setting change. But none of these hooks fired when I edited the page. Currently, I have achieved this through changing InputfieldSelector.module's __construct() method, but I wanted to do it with a hook so it has more of a chance of not getting removed on upgrade! Any help appreciated ?

Nb. the same works for Roles. e.g. I added a text field to the Role template, called it "purpose" and then added that to the Roles admin list so it's clearer what role does what. Thanks for the tips.

One question I have is: is output formatting on or off in this situation? $pwUser = $this->wire->pages->newPage([ 'template' => 'someTemplate', 'name' => 'someName', 'someField' => 'someValue', ]); A reflection about setting a value when output formatting is ON: The blog says that when it's ON, the formatters will run to check it can be formatted and it will set it to status:corrupted if they can't run. This sounds like good validation to me, which makes me think it might be better advice to do $page->of(true) before setting values, unless you're in a situation where you can really trust your raw data to be valid. Caveat: I note that the example edits are self referential ($page->someField = $page->someField + 'altered') in which case it's clear that output formatting ON is going to cause problems.

The problem goes deeper. As well as the hooks above (published/unpublished) i needed to add one on Pages::saved(1:published) because my paths are based on the published date. I believe there's a bug in core that prevents us being able to implement path() in a page class successfully: https://github.com/processwire/processwire-issues/issues/1906

I started with those, but they're not always the right way. There's also url segments and path() method overrides. The challenge is: 1. you want pages to be served at your desired url. 2. You want the admin ui to show correct URLs. 3. You want the link adding UI to find the correct URL. 4. You want $pages->get(url) to work. 5. You want the qa checker to work. 6. You want PagePath module to keep up with changes. If interested, here's a rambling post of my journey, I got there in end (except 2, but, meh!).

Here's a copy of my blog with some reflections on building my first site with ProcessWire as someone coming from Drupal: peopleandplanet.org ProcessWire is an open source CMS Content Management System or Framework (CMS / CMF respectively) using PHP and MariaDB/MySQL. It's been around a while, humbly gathering users and sites. I spent a good while reviewing lots of open source CMSes recently as I have previously relied on Drupal 7 (excellent) and didn't like Drupal 8+ nor BackDrop (a fork of Drupal 7). WordPress? not with Gutenberg/React and all those plugin ads, thanks. Turns out I'm quite picky about CMSes! This is because my role is developer, trainer, implementer, themer, discusser of problems and solutions and dreams. I have personal relationships with my clients and am here to help. So I need a system that makes it simple for them to do as much as possible without me, while also being flexible enough for me to rapidly develop new features. So I was shopping for me and my clients, not just one of those parties. ProcessWire seemed a good balance, and once I started developing with it I was hooked. I've now launched my first site with it: peopleandplanet.org and my clients are pretty pleased with it, and I have another job in the pipeline. Templates and pages In ProcessWire, everything (even users!) is a Page, and every Page has a Template. So in Drupal-speak, it's kinda like Page = Content/Entity and Template = Content/Entity Type. A Template is configured with lots of options and describes what fields apply. Templates don't all need to be renderable, but typically are, so generally have an accompanying Template File. Key implementation decisions I made There are many ways to generate and theme page HTML in ProcessWire and I went through them all! Here's what I settled on: Use Page classes: these are PHP classes which add/bend functionality for a particular page/template. Doing pre-processing of data this way seemed the cleanest way to organise things, using inheritance to share code between similar templates. I used the excellent Latte templating engine instead of plain PHP or other options like Blade/Smarty/... Latte is context-aware which makes templates cleaner and clearer to look at and safer because it knows to escape content in one way as HTML text and another as an attribute, for example. The final clincher is that it uses the same syntax as PHP itself, so as a developer hopping between PHP and Latte, there's much less brain strain. Use PageTableNext. This is similar to Drupal's Paragraphs or Gutenberg's Blocks (ish). It allows a page to be built from slices/sections of various different templates, e.g. I have things like "text" and "text-over-image" and "animated stats" etc. These let authors make interesting pages, applying different preset styles to things, giving a good mix of creative control and theme adherence. What I liked Beyond the above features, I liked these things: Fairly unopinionated: the core is quite small and everything is a module, so when you write your own module, you have similar level of access. e.g. I was able to make a core module behave differently by using hooks rather than having to maintain a patch of a core code file. The selector API is a domain-specific query language for fetching page data that makes a lot of common things you need to do very easy and clear to read. I like readable code a lot. A lot of basic CMS features are implemented really nicely; thought has gone into them. e.g. Drupal has a redirect module that can add redirects from old URLs when you update the 'path alias' for a page - great - but ProcessWire's implementation (a) prevents you making circular redirects which is a quick way to kill a Drupal site by accident that's happened more than once, and (b) has some useful rules like let's only do this if the page has been in existence for a little while - because typically while first composing a page you may change the title quite a few times before you publish. e.g. when you save a page that has links to other pages in it, it stores the page IDs of those other pages too, and when the page is fetched it will check that the URLs exist and still match the ID, fixing them if needed. Images - have 'focus' built in as well as resizing etc. so if a crop is needed you can ensure the important content of the image is still present. Booting is flexible; it enabled me to boot ProcessWire from within Drupal7 and thereby write a migration script for a lot of content. There's a good community on the forum. A forum feels a bit old fashioned, but it's good because you can have long form discussions; it sort of doubles as a blog, and a lot of new features are announced in forum posts by Ryan and others. The Tracy debugger is mind-blowingly good, just wow. Modules - third party or core - are typically very focussed and often tiny. This is a testament to what can be achieved throught the flexible and well-designed APIs. Weekly updates on core development from both the lead developer on the blog and the community, both with RSS feeds so it's easy to keep updated. What I don't like Logging is weird and non-standard. I prefer one chronological log of well categorised events, but instead we have lots of separate files. This is a bit weird. One thing it is opinionated on is that there should be a strict hierarchy between pages and URLs. I like that level of order, but in real life, it's not what I needed. e.g. People & Planet has three main campaigns and it wanted those at /campaign-name not /campaigns/campaign-name. And we wanted news at /news/2024-03-25/title-of-news-article, but we don't want a page at /news/2024-03-25/ and we want the news index to be under an Info page in the menu. This meant I had to write a custom menu implementation to implement a different hierarchy to display what we wanted it to look (3 campaigns under a Campaigns menu, the news index under an Info menu). There was a page hook for having news articles describe their URLs with the publish date, but this took quite a bit of figuring out. Ryan Cramer leads/owns the project and other contributors are sparse. He seems like a lovely person, and I'm super grateful for his work, but there's only one of him, so this is a bit of a risk. Also, the code has no phpunit tests. Gulp. There have been various initiatives, but this sort of thing needs to come from a core team, and it's not a priority for Ryan. I love tests, they help avoid regressions, help document designed behaviour, etc. Likewise, there's a styleguide, but it's not adhered to, so... Right decision? I'm very happy with it, and it seems a great fit for my clients' needs, and they're very happy. All software has risks and I got burned twice with Drupal 8/9 - once backing out after months of development; another project that went to completion I regret and dislike administering/maintaining now. But so far, so good, and I intend to use ProcessWire for other projects (including replacing this website) very soon. Contributions I have two ProcessWire modules that are there for anyone who needs them. TagHerder provides a page at Setup » Tag Herder that lists every tag and every page tagged with that tag, and provides three options: Rename the tag; Trash the tag; Replace the tag with another. Useful for cleaning up tags that have gotten out of control! EditablePublishedDate lets you edit the published date of a page. Useful for entering historical page information or such.

I think my problem may have been caused by the code in https://processwire.com/talk/topic/29716-mysterious-blank-page-no-errors-to-be-found-andor-how-to-use-alternate-urls-path-pages_paths-table/?do=findComment&comment=239935 because $page->published is not how to tell if a page is published(!) and it has a value for unpublished pages, too. Instead I should have been using $page->isUnpublished() I also needed this to ensure that the PagePaths module kept its table up-to-date: $pagePathModule = modules('PagePaths'); $this->pages->addHook('published', $pagePathModule, 'hookPageMoved'); $this->pages->addHook('unpublished', $pagePathModule, 'hookPageMoved');

I have no idea if this is of interest to anyone else, but it might be useful for me to document my discovery journey, so I'll continue spouting into the void! Having looked into how PW fetches pages specified by path, what have I learnt? $pages->pathFinder() is described as a newer more capable way to find pages by path, but it's not the method that is used by $pages->get() / the PageLoader class. (That PageLoader::getByPath() method does/can use pathFinder but only in the case that its searches bring up multiple possibilities. The QA/link checker code introduces a concept of sleep/wake which as far as I can guess, it calls sleep when the HTML is written to the database which tries to add an attribute in to identify the page a link goes to by ID. And wake when loading the HTML, possibly replacing URLs with something based on the previously stored ID. I'm not 100%. The QA code calls $pages->getByPath() up to twice. The first time it looks, given /a/b/c for a page whose name is c and whose parent page's name is b and whose parent page is named a; if that fails it checks whether the page is covered by a template using urlSegments; if that fails it checks the history table (if enabled). Then if not found, it calls again without urlSegments, which causes it to also search for a page called c - if there's only one, then it's happy. I'm still puzzling over why the QA method seems to be different from the normal method. Perhaps it's because the QA can't know about access restrictions of the user who will access the link, so only goes on existence? why a page class' path() output seems to be ignored - I realise that the only way not to ignore it would be to rely on the optional PagePaths module, but that seems reasonable, and is hard wired into core anyway in other places (e.g. multiple matches). If getByPath() used that, perhaps via pathFinder would that fix things I wonder?

So the link validator really strictly imposes the hierarchy. Given a path /a/b/c it looks for a page named 'c' whose parent is named 'b' whose parent is named 'a'. Which is why it fails. I can quieten the false link validation errors if I enable url segments on the /news/ template - but then the link validation thinks /news/anything exists because it has a handler - even though the handler might give a 404. I would like to see a different resolve path to page mechanism in use that could accommodate these other layouts. I'm unclear how and when the PagesPaths module is brought in to assist in this process too. I understand it's supposed to sort of be a bit of a cache to assist lookups. I'd think something like: Does the path map to a page in pages_paths? Great, super quick indexed lookup, use that. If not... Hookable path-to-page method. Tries first the original way (above), if not... if page handled via segments, has some way to ask the controller for the page to use (may be itself, or some other), if not check path history (what about URL hooks?) invalid.

Update: so this doesn't solve it. Why? Because the automatic link selector will offer you the facade links to select, but then when you save it complains that the link is wrong and, although it has saved, it won't let you off the screen because it considers it a validation error. :shrug: I think I'm going to need to grok the pages() get code to see if there's a way around this. The whole public-facing URLs must match an internal hierarchy constraint is a real bind.