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.

Here's how I solved bodged it: public function path() { // We're including a trailing slash, even though it's configured not to use them. if (!$this->published) { // Before a page is published, return the basic, hierarchical path. // This will get stored in pages_paths table, which is important so the // page can be found by its hierarchical path. return '/news/' . $this->name . '/'; } // On a published page, return our facade. return '/news/' . date('Y-m-d', $this->published) . '/' . $this->name . '/'; } When calling the path() with an unpublished page, return a plain path that matches the actual hierarchy. This results in the correct value being written to the pages_paths table. Then on a published page, return the facade.

Symptoms: as title says, just a blank page, no content, but successful http response. Nothing logged in any of PW's log files, or in php's error log. Cleared caches, still same problem. Other pages using same template all work fine. Page loadable with pages(1234) but *not* loadable with pages('/path/name-of-page') - the latter gets null page object. Workaround: I changed the page's name, saved, then changed it back again, and it seems to work. Possible(?) confounding factors These news pages live under /news/ however I wanted the URLs to include the published date, like /news/2024-02-21/some-page It is being accessed via URL hook on /news/[0-9-]{10}/(title[^/]+) with $event->pages->get("/news/$event->title"); The page class overrides the `path()` function which contains `return '/news/' . date('Y-m-d', $this->published) . '/' . $this->name . '/';` This has worked fine for all the other pages. Any ideas what might have happened? What could cause pages() to fail to load by page path for this page? Possible asides: I'm not 100% on how to use different urls for pages, but what I have seems/ed to work; for example the template is configured not to use trailing slash, but I found I needed one returned by path(). pages('news/the-page') (without the date) loads the page. So I think path() is only used for rendering. It didn't look like the date-prefix is persisted in the db. EDIT: page_path table When it was broken, I did a mysqldump. And after it was fixed I repeated. I then used neovim to diff the dumps (mmm, fun). Here's what I found. I believe the key difference is in the pages_paths table, where the broken version had 'news/1970-01-01/the-page' and the working version had 'news/2024-02-21/the-page'. My hunch is that something populated the pages_paths table before the page was published, thereby getting the epoch date. So I need to understand the relationship between a class's path() function, and loading with pages($path).

@kazno worries, just glad you got a solution.

Hi @kaz I began trying to answer you, but it's so hard to talk about these things in text! Not sure if this picture I made to document my setup is any use?

At risk of making myself unpopular, I'm a neovim user who has ethical aversion to AI. I get a great developer experience and I don't have to worry about Kernighan's law making my code buggy and hard to maintain. I am also concerned about climate change, and AI has huge carbon emissions - (re)training an LLM has been estimated to emit the equivalent CO2e as 125 round-trip flights between New York and Beijing [source]. I'm concerned that my open source code has been used against its license to train AI through github (find my stuff on codeberg or project owed gitlabs) and so now will be included in proprietary products. I'm also against having to pay subscriptions to a handful of big tech companies because this accelerates wealth inequality and erodes democracy, reducing our chances of turning the ship around before crossing the runaway climate change event horizon. I do not doubt AI's usefulness, or it's ability to charm and amaze or excite, I do not doubt that it can be used to save lives even (e.g. specific medical use such as identifying cancer early from scans). But I do remember how Nobel thought his invention of dynamite would be great and I'm not going to be taken in by another big tech lie about "don't be evil". We have very weak regulatory powers and a world teetering on the edge of unfathomable suffering. This is a post about a personal choice of text editor, and I'm not judging folx who choose Cursor (or ai plugins for neovim!) - I respect that opinions differ. But I wanted to share my opinions on my choice, too.

I've just made a module that exposes the 'published' date under the page's Settings tab, so you can update it. It appears to be working nicely, but any feedback would be very welcome as I'm new to this still. https://codeberg.org/artfulrobot/EditablePublishedDate/src/branch/main/EditablePublishedDate.module.php

I only have one pw site at the mo, and I can't reproduce it reliably. It's just happened a few times and I wondered if anyone else had the problem. The main bother of it is that, typically I'm in a hurry to debug the crash, not debug the debugger at the time of the crash!

@adrian oh yeah, I'm all about the hard reload. I have basically stuck tape over my Ctrl key. But sadly it didn''t help. It's so weird how it exhibits the error, yet quotes the corrected code!

I've noticed this a couple of times. I load a page and it crashes, Tracy gives me a big red page with helpful info on it. I then fix the problem, and reload the page - but the error won't go away. For example the screenshot below shows and error saying "Call to undefined function ProcessWore\pappub_inlay_request()", and then highlights a line in my code that (now because it's been fixed) doesn't show the code from the error message! One part of the page is lying to me, and it doesn't go away until some timeout. I'm guessing a cache timeout? But I've tried adding a ?something=123 var and that didn't fix anything either: still received the old error that no longer correlates to the actual code; Tracy seems to be intercepting my actual code to show me the old error! Anyone else had this?

Thanks for sharing this @BitPoet I read about it in the newsletter. I love that people publish simple useful solutions like this because it is a great learning aid as someone who still considers themself new to ProcessWire. On looking at your code, I had these observations (which I'm only sharing in case they are interesting!) Wow, how cool that PW lets you invent new 'subfields' as a way to integrate potentially complex SQL. I wonder what I might do with that! Hmmm. Why escape what must only be an integer as a string? I then wondered how MariaDB would handle the comparison since you're requiring an implicit coercion by comparing an int (output of CHAR_LENGTH) to a string. Because '2' > '100' if you're comparing string values, which is not what we want. It seems from my tests that MariaDB picks integer as the shared type for the comparison, which is lucky. I assume the operator does not need validating because we're assuming PW core has already done this and there's no codepath that would allow this function to be called with user input for the operator. SELECT '2' > '100', CHAR_LENGTH('12') > '100', '100' < CHAR_LENGTH('12'); +-------------+---------------------------+---------------------------+ | '2' > '100' | CHAR_LENGTH('12') > '100' | '100' < CHAR_LENGTH('12') | +-------------+---------------------------+---------------------------+ | 1 | 0 | 0 | +-------------+---------------------------+---------------------------+ Anyway, thanks for sharing the code, I'm not sure if I'll need a length search any time soon, but it's helpful to have learnt that it's possible and that similar such extensions are possible.