Leaderboard

Something I've wanted in ProcessWire for a long time is full version support for pages. It's one of those things I've been trying to build since ProcessWire 1.0, but never totally got there. Versioning text and number fields (and similar types) is straightforward. But field types in ProcessWire are plugin modules, making any type of data storage possible. That just doesn't mix well with being version friendly, particularly when getting into repeaters and other complex types. ProDrafts got close, but full version support was dropped from it before the first version was released. It had just become too much to manage, and I wanted it to focus just on doing drafts, and doing them as well as we could. ProDrafts supports repeaters too, though nested repeaters became too complex to officially support, so there are still some inherent limitations. I tried again to get full version support with a module called PageSnapshots developed a couple years ago, and spent weeks developing it. But by the time I got it fully working with all the core Fieldtypes (including repeaters), I wasn't happy with it. It was functional but had become too complex for comfort. So it was never released. This happens with about 1/2 of the code I write – it gets thrown out or rewritten. It's part of the process. What I learned from all this is that it's not practical for any single module to effectively support versions across all Fieldtypes in ProcessWire. Instead, the Fieldtypes themselves have to manage versions of their own data, at least in the more complicated cases (repeaters, ProFields and such). The storage systems behind Fieldtypes are sometimes unique to the type, and version management needs to stay internal [to the Fieldtype] in those cases. Repeaters are a good example, as they literally use other pages as storage, in addition to the field_* tables. For the above reasons, I've been working on a core interface for Fieldtypes to provide their own version support. Alongside that, I've been working on something that vaguely resembles the Snapshots module's API. But rather than trying to manage versions for page field data itself, it delegates to the Fieldtypes when appropriate. If a Fieldtype implements the version interface, it calls upon that Fieldtype to save, get, restore and delete versions of its own data. It breaks the complexity down into smaller chunks, to the point where it's no longer "complexity", and thus reasonable and manageable. It's a work in progress and I've not committed any of it to the core yet, but some of this is functional already. So far it's going more smoothly than past attempts due to the different approach. My hope is to have core version support so that modules like ProDrafts and others can eventually use that API to handle their versioning needs rather than trying to do it all themselves. I also hope this will enable us to effectively version the repeater types (including nested). I'm not there yet, but it's in sight. If it all works out as intended, the plan is to have a page versions API, as part of the $pages API. I'll follow up more as work continues. Thanks for reading and have a great weekend!

To create a new field, you need to select a Fieldtype, not an Inputfield. Fieldtypes often have a matching Inputfield, but some support different Inputfields to faciliate the input. The Fieldtype is the part that takes care of storing and loading the data for the field, while the Inputfield provides the UI for entering that data. In the case of InputfieldTextTags, it doesn't have a matching FieldtypeTextTags, but rather complements the existing Fieldtypes FieldtypeText, FieldtypePage and FieldtypeOptions. So you need to create one of those and then, when you configure the field, choose "Text Tags" as the Inputfield of choice. Once you save it, you will see the configuration options specific to InputfieldTextTags.

But find() searches in current language AND default one. I assume OP wants to search only in one language. https://processwire.com/docs/multi-language-support/multi-language-fields/#how-language-fields-work

New version pushed to the dev branch with fixes for InputfieldTable and FieldsetPage elements. Please let me know if this solves the issue @monollonom https://github.com/SkyLundy/Fluency/tree/development Thanks for everyone's patience. Work has been crazy (and a long-ago planned vacation didn't help). Thanks!

Ah sorry, you are right! ? I'd have an idea but I'm on the go, so let's see if others know a good solution in the meantime.

You can set the language before the $pages->find() operation:

Ok. I finally followed my initial tutorial step by step based on a clean ProcessWire 3.0.229 with basic blank profile (output strategy Markup Regions) and PHP 8.2.4. Following the steps and copying the code one by one showed no warnings or errors at all. Of course i needed to adapt the events.php template for markup regions to see the output. However I found two possible traps one can step into. First trap is related to the installation process of the Latte composer package. If a default ProcessWire composer.json exists in the root of your installation, composer asks to use this composer.json file. If you answer Yes (default), this would install the Latte files in /root/vendor instead of /root/site/classes/vendor as I assume in my tutorial. This could explain the file not found error you mentioned. In order to install the Latte composer files inside /root/site/classes, one needs to answer NO to the composer question "Should I use the composer.json in the root?". Added a note in my initial post to avoid this trap. Second trap could be your template output strategy. My tutorial assumed you are using delayed output strategy, not markup regions or others. If you use markup regions, you won't see any Latte output in the events.php at all. So I decided to add an example for markup regions for the events.php template too. In your specific case, the error may be related to the fact that you already installed other Latte template implementations like RockFrontend, LatteTemplateEngine module or others, which may affect each other (e.g. namespaces, autoloaders). So I guess if you would start with a blank ProcessWire installation, my initial solution should work out of the box for you as well ?.

Hi @ryangorley! Not sure if you've taken at this old but still very relevant post: I'd say the best way is the one that fits your use case and in that sense ProcessWire has no rules about categorization. The tags can exist under their own parent separate from the "News > Blog Item 1" tree branch: /tags/tag-1 And be linked through the tags inputfield, it's pretty much the same case for categories. To my own personal taste I always tend to go with an structure like this: - ? News -- ? Tags ---- ? Tag 1 ---- ? Tag 2 -- ? Categories ---- ? Category 1 ---- ? Category 2 -- ? News Item 1 -- ? News Item 2 I like this because it keeps everything in the context of the "News" for the editors, and also the following URL structures which makes sense to me (not so sure about SEO but have had no complaints lol): /news/tags/tag-1 /news/categories/category-1 /news/news-item-1 The only part I'm not a huge fan of is that it requires a bit of code using hooks to keep the right sort underneath the "News" page, since the actual news items share a parent with the tag/categories parent, sorting the News children by published reversed, will (most likely) send the Tags and Categories to the bottom. But it ain't that big of a deal and if the problem arises to you I'll gladly share my solution. Also, to my own taste, I use a custom field for publish date, this lets me have more control over it and handle the visibility of the actual post with the hidden/unpublished status depending on what I want to achieve. Now for archive pages i'd suggest you take a look at what @ryan did in this old but also still relevant blog profile: https://github.com/ryancramerdesign/BlogProfile/blob/master/site-blog/templates/archives.php In all fairness this is not the clearest example and it's one of those part you'd expect to be built by default in a CMS, but I always think these details are worth the effort as a sacrifice for the flexibility PW gives you in terms of data structure/relation.

@szabesz you are right, it's not considered as a bug (I might disagree), see https://github.com/processwire/processwire-issues/issues/1322 @saschapi I've forked tpr's repo and amended some changes, https://github.com/matjazpotocnik/FrontEndEditLightbox

You could edit /site/templates/admin.php so that it looks something like this: // Get the user's IP address $ip = $session->getIP(); // Define the allowed IP addresses $allowed_ips = ['111.111.111.111', '222.222.222.222']; // Check user's IP is allowed if(!in_array($ip, $allowed_ips)) { return 'Access denied'; } require($config->paths->adminTemplates . 'controller.php');