Leaderboard

Last week I asked you what you'd like to see in ProcessWire in the next year (and years ahead), and we got a lot of feedback. Thank you for all the feedback, we've had a lot of great and productive discussion, and of course feel free to keep suggesting things too. Below is a summary of things based on what I thought was feasible from the feedback so far. I'm not suggesting we'll be able to do all of this in 2021, but do think it makes a good preliminary roadmap of things to look closer at and start working on some very quickly. I'll keep working to narrow this into a real roadmap, but wanted to share where we're at so far (consider it preliminary/unofficial): Flexible content or page building One of the most common themes has been that people want more content building options as an alternative to using a rich text editor at one end, and page builder at another. This is a direction that some other CMSs have been going in (like WordPress), and one that many would like to see ProcessWire provide an option for as well. But the needs seem to come from two different angles, and it points to us pursuing 2 directions simultaneously: First would be a flexible content block style editor in the core as an alternative to rich text editor that supports pluggable block types while maintaining best content management practices. If possible, we'd use an existing tool/library like editor.js or another as a base to build from, or potentially build a new one if necessary. To be clear, it would not be a replacement for CKEditor but an alternative approach supported by the core. Second would involve improvements to Repeater/RepeaterMatrix that enhance its abilities in supporting those using it for building more complex content page builders. Since many are already using it for this purpose, the goal would be primarily to better and further support this use case, rather than make Repeater/RepeaterMatrix a dedicated builder. Jonathan Lahijani and others have pointed out some specific things that would help achieve this and I plan to implement them. Admin theme improvements We would like to add additional flexibility to the AdminThemeUikit theme so that people can further customize it how they would like it. What directions this will take aren't nailed down quite yet, other than to say that it's going to be getting some focus (and this has already started). At the very least, we know people want more sidebar options and the ability to tweak specific CSS, perhaps in a preset fashion. Improvements to existing Fieldtypes and Inputfields Things like support for a decimal column type, more date searching options and additional input level settings on other types. Though these are specific feature requests and our focus is more broad, so we'll be going through many of the core modules and adding improvements like these and more, where it makes sense. Pull requests and feature requests People would like to see us expand our code contributor base by merging more pull requests in cases where we safely do it. We will also be narrowing in on the specific feature requests repo to see which would be possible to implement this year. External API There are requests for an external/front-end API that would also be accessible from JS. I support the idea, but have security concerns so am not yet sure if or in what direction we might take here, other than that I would like us to continue looking at it and talking about it. File/media manager and more file sharing options There is interest in an option for a central media/file manager so that assets can be shared from a central manager rather than just shared page to page. There is also interest in the ability for file/image fields to reference files on other file/image fields. External file storage Some would like to be able to have PW store its /site/assets/ and/or /site/assets/files/ on alternate file systems like S3. That's something we'd like to use for this site too. To an extent, work already started on this last year with some updates that were made, but there's still a long way to go. But it will be great for sure. Live preview and auto-save There are requests for live preview and auto-save features to be in the core. Currently they are just in ProDrafts, but there are now more options and libraries that would facilitate their implementation in the core, so I'd like to see what we can do with this. More multi-site features There is interest in ProcessWire natively supporting more multi-site features, potentially with the option of working with our multi-language support.

The other great thing about it is that it's a very realistic thing we can do. Though Jonathan's video pointed out a lot of drawbacks. Maybe we can solve some of them with upgrades to RepeaterMatrix like Jonathan proposed, and maybe others are acceptable drawbacks given our context is very different from tools like WordPress. Plus, it seems like Jonathan is already using this approach successfully with clients. I took a closer look at https://editorjs.io/ and I like it for a lot of the same reasons I liked what The Bard example was showing. The plugin-based approach for blocks it uses looks great and this seems like something we could probably integrate pretty easily/quickly since it's based off an existing tool that handles the difficult-to-code parts. Being able to solve this need with an existing tool like this is the ideal route IMO. While cool no doubt, this is where I get into more of a grey area as to whether ProcessWire should be involved in this sort of thing at all. It just seems it steps maybe too much outside the scope of content management. Yes, this makes sense. This is what I liked about that editor.js option, as it seems like (combined with its plugins) it's already a clean system for doing this. Interested to hear of others think this approach would be a good path to take. I'm already a fan of Unpoly after spending a lot of time looking at it, particularly with how lightweight it is relative to what it does. There isn't anything hard coded in it. The top area is a CKE and images field, and images use tags to place in groups. The next part is list of features/highlights, each with headline, icon, description, and link; these are a FieldtypeTable field. Another FieldtypeTable field manages quotes (quote, cite, source, active), which are pulled randomly in different parts of the page, as well as on other pages in the site (which pull from the same field). Everything else on the page is pulled in dynamically from other parts of the site. For instance, the blog part always shows the newest blog posts, the showcase part always shows the newest site additions, the Pro modules part pulls from the /store/, etc. So there isn't really much code on the actual homepage template, since it's actually the other parts of the site rendering each of those. I agree, I will add this. Yes, that has been my experience as well and so this was one of the things ProcessWire has always tried to solve from the beginning. Keep the client focused on semantic content and not on style, layout or presentation. It's also why I've never been a fan of front-end editing. As soon as the person editing content takes their focus off of meaning and shifts to presentation, that's where things go south and content is no longer portable. I see a fundamental job of a CMS being to manage portable content. With all that said, it does seem like there is an exception to the above (per what Jonathan mentioned earlier). That is, the perhaps temporary 1-page marketing things, where questions of portability don't really matter and the short term marketing needs do. This is already built into FieldtypeFloat, so another good reason for it to add DECIMAL column support. Well in this case, we would add the support to the core, so one wouldn't need to use Combo for that purpose. A number spinner is built into the HTML5 number type, which is already an option for the float field. What's lacking is the ability to modify the step value from the default. I can add that, no problem. @Robin S I've been experimenting with your Uikit admin CSS additions and a few of them (some of the "fix" ones) seem like they should be added to the core. Some of the other more subjective ones, you've got me thinking we should have a "customization presets" dropdown in the Uikit admin that lets you select predefined customization sets like yours. I think having separate configuration settings for all the different things you've changed is probably too much configuration, but presets seems like a good way to answer common preferences people might have?

A lot to agree with here ?? One thing I particularly liked about editor.js is how it keeps content separate from design: behind the scenes everything is abstracted so that a quote block is really just an object with a few text properties, etc. You could render that quote block in a hundred different ways for the front-end. Portable indeed ? In fact the more I think of it, the less sense it makes to think of block editors as something that would replace pages and fields. I'm all about having content split into separate fields where it makes sense. But as a replacement for RTEs, that's something I can definitely get behind: an RTE is a decent tool for creating text-only content, while for anything beyond that I find them rather awkward. For "body content" (which may these days typically be a varying mixture of text, images, tables, forms, highlights, and so on) flexible content fields are (imho) a much better choice.

That's it. I just don't want to let my clients have the freedom to play with styles, at least not within boundaries I can manage by code. It would be such a pain if I have (as accountable/developer of the project) to fix the mess made by a client inside the editor. Moreover, from my experience, if I give a client some sort of freedom (especially inside the creative side of things) then he will ask me more and more (Can I do this? Can you add this for me?). The editor become their toy, and the front-end the crappiest as ever. On the flip side of the coin I would really love if we, as developers, could have the ability to let editors manage our pre-made components in a more compelling/modern visual way.

I agree. The way I see it, if there's a low level SQL type that supports given functionality, there should be a fieldtype that corresponds to it, however the ProcessWire specific fieldtypes are there for when additional functionality is required that can't be supported directly through SQL. Speaking of that, it may be a bit of a limited use case, but I've wondered a few times about adding geometry fieldtypes and adding geometry selectors. There's already the FieldtypeMapMarker, but this is using just standard float fields in mySQL, while mySQL and MariaDB have support for geometry datatypes and spacial indexes, and there are times it would be nice to be able to do a query and return all the places within a given distance. I already hacked the FieldtypeMapMarker a bit to allow adding KML overlays exported from Google Earth, or mobile tracker apps, but there's certainly a lot more that could be done to give geospatial data first class treatment if enough people use it.

ElasticsearchFeeder saves the document-ID returned by ElasticSearch and the time of the last sync to the correspondending page.

@arjen forked it because, quote: "We needed an option to determine whether 0 or empty should be regarded as equivalent. I copied the method + config from FieldTypeFloat. In my testing it seems to work fine." Others wanted to convert Float fields to Decimal but I guess your "combo" solution would solve that out of the box. Last but not least there was interest in "number spinner" which would be nice to have for all number fields, provided that the "values of increments" are configurable. BTW, I forgot about all this,but @apeisa joined in the discussion at some point, quote: "As a @sforsman's coworker I'll let him know about this. We do use namespaced version of this module ourselves." So maybe you and Apeisa could also discuss what their current extra needs are, if any.

The great thing about Repeater Matrix way, is that a dev can create his own Builder (be it layout, content or full page builder). A content type can represent a section with all predefined components, just a section, or a column in a grid. And it is the dev who decides how it is rendered for the frontend. It would be great if we wouldn't drop that customization part. Some of the content types I build contain not just the simple markup like buttons, text and headers, but link to other ProcessWire content. Like a Page Reference field to define selected products to output. Or a selector field for that purpose. It is not shown in @Jonathan Lahijani's video, so adding this point. Some "components" of mine are just a content type without any fields attached to customize - like a "calculator" content type. The whole page here, for example, between the header and a footer is a single Pepeater Matrix field. As for me, the WHATEVER-builder field should be in fact а framework for constructing: a content builder (just the content that goes into <main> tag, like the bard field or this editor.js based field) or a whole page builder (like the YOOtheme builder example). Leaving the dev to construct all the possible types, their possible children/parents, the way they are displayed in admin and rendered on the frontend. Plus the way to easily reuse stuff within a site or on a different project. Sounds like an impossible task, but a lot of us here already done that mixing Repeater Matrix (or a couple of those) and Mystique (for adjusting little things like headline tag or margin/padding, that does not deserve their own regular fields). The thing that's missing is the js polish on top of that and handling of edge cases. And I am not too much pro leaving the repeater pages as storage (it really hurts the reusability part). I am for the presence of the ability of customization that it gives to Repeater Matrix as it is now.

Hi everyone, I'm happy to present my latest project, which is a collection of guides and tutorials for web development with ProcessWire written by me. https://processwire.dev/ What is this? I have written several tutorials in this forum, and I wanted a central place to collect all my tutorials and put them in a logical order. processwire.dev is exactly that, a curated list of tutorials for different topics related to ProcessWire development. I have revised, updated and expanded most of my existing tutorials. There are also some completely new tutorials. Notable topics How to integrate Composer in your ProcessWire sites, and a general explainer for namespaces and autoloading. A two-part guide to using Twig with ProcessWire and adding custom functionality. How to create flexible content modules with Repeater Matrix fields and Twig. A general guide to performance optimization for ProcessWire. A starter guide for the "ProcessWire mindset" - how to structure your content. ... and much more! What's next? I hope this will be a useful resource to all of you fine people. Please note that these tutorials are very much opinionated, and they reflect my personal experience and development practices. So if you disagree with some of my conclusions, that's perfectly fine! I'm happy to discuss all my recommendations and approaches with you, so let me know if you have any feedback, suggestions or error corrections! I plan to expand this resource over time and already have some new topics planned. If you have suggestions for new topics, go ahead and post them here as well! Start reading now: processwire.dev

@flydev ??, Sorry to tag you like this. I am not sure if you are following the discussion here regarding content blocks? Just wondering how far you are from releasing your Editor.js-based Fieldtype? Given that you've probably spent months developing the module, I'd be interested to hear what your thoughts are.

@adrian Hi Adrian, tiny bug report, I get some PHP notices in the errors panel when I define a constant with an array value in my config.php: 2x PHP Notice: Array to string conversion in .../includes/GetTemplateResources.php:6 This is the corresponding line: \TracyDebugger::$templateConsts = array_diff_assoc(get_defined_constants(), \TracyDebugger::$initialConsts); I found this question on SO, apparently array_diff_assoc always throws this warning when given a multidimensional array, and get_defined_constants will be multidimensional if one of the constants is an array. Not sure how to properly fix this, maybe run through the defined constants and handle all constants with array values separately? It's not that big a deal, but the red error notice on the bottom is bugging me ^^ Here's an example of constants in my config.php that causes this error (slightly obfuscated): const MEMBER_TYPE_X = 123; const MEMBER_TYPE_Y = 456; const MEMBER_TYPE_Z = 789; const MEMBER_ACCESS_FIELDS = [ MEMBER_TYPE_X => 'access_x', MEMBER_TYPE_Y => 'access_y', MEMBER_TYPE_Z => 'access_z', ]; Can you take a look? Thanks!

Thanks @MoritzLost! It worked now. Something was happening with the regex AND with my input. It's all good now!

Nope. Both are quite experimental at the moment. Not in the sense that things don't work, but experimental so that things might change, there are no proper docs etc...

If the textarea contains exactly the same as your test string, preg_match will not work differently. There's probably some additional content in there, maybe some whitespace or even a hidden character from pasting or something like this. I'd try dumping both your test string and the value from the database next to each other and check them for differences. Besides that, the most likely cause are the issues with your regex explained above. I'd also recommend using urlencode or rawurlencode instead of str_replace to encode the URL part. What kind of output are you getting with the value from the database? No match at all, or does it match something it shouldn't?

@ryan - another thing I'd like to see is the search functionality from this module: https://processwire.com/talk/topic/14354-fieldtypedatetimeadvanced-subfield-selectors-for-datetime/ incorporated into the core datetime field.

This is an important question indeed. In its current state Gutenberg is a page or content builder: it provides the tools for laying out content for singular pages from existing out-of-the-box or developer-built components (aka blocks). It's literally a drop-in replacement for TinyMCE, now known as the "classic editor" in the WordPress ecosystem, with a GUI that is better suited for that kind of flexibility. The most one can do with Gutenberg in terms of "full site editing" is add columns of blocks, and even in that case there are limitations. (It does also provide tools for defining purely visual aspects of the blocks, such as colors, fonts, and whatnot, but most developers I've talked with outright disable or at the very least severely limit these features.) This is what, in my experience at least, many clients want these days: to be able to build rich and interesting content, whereas RTE is mostly good for relatively simple text content. Even laying out images among text with an RTE requires specialised know-how and can be a tedious task... and while a combination RTE and shortcodes may be able to achieve all the same things as a page builder, it's just not quite as intuitive. A site builder — which, as Jonathan already pointed out, is also where Gutenberg is eventually headed — is a different beast altogether. Personally I wouldn't feel comfortable giving clients access to this sort of tool, and in my experience that's not even the intent behind most of them. They are primarily tools for designers/developers: folks who are comfortable designing sites and making CSS/JS tweaks here and there, but don't necessarily feel comfortable diving into "actual development", backend work, or building sites/themes from scratch. Long story short: in my opinion ProcessWire has a great set of tools for developers, but what we lack is a great tool for building rich content. A GutenWire™. Just my five cents ? This! ☝️

I think most of us are thinking along this line in addition to more complex "custom components" as what we love ProcessWire for (among other things...) is that we devs can decide on the final output, and not the system is the one to dictate that in any way. However, ProcessWire could help us by providing a "builder" which renders semantic HTML which is in turn somehow also customizable by the developer. In other words: we need a layout tool so that our own "custom" components can be managed like LEGO blocks, either by us or by our clients. Allowing clients to customize styling could be "just" an additional feature but I would not venture too far in this area, as most of the time it is not a good I idea to let clients style anything (there are surely exceptions to this, of course, but still...).

Thanks for the defs @Jonathan Lahijani I'll see if I can set myself a challenge to build a basic clone of this this weekend ?.

ProcessWire is definitely a sustainable open source project and here for the long term. Though if the standard of adoption measurement is WP, then we are nowhere near that and never will be. I certainly wouldn’t want that either. But our installation base is already much larger than I would have ever believed possible. This is in part because ProcessWire has grown, but also because the demand for what ProcessWire provides has grown, as has the entire online landscape. When a client hires us, they hire us because they aren’t web developers themselves, and they want an expert. If the client has already decided on the best tools for the job, which is not their expertise, then they aren’t looking for an expert. I hope that most of us can be selective enough not to take on such clients. There are also cases where you as the expert may decide that WP is indeed a good fit for their need. So long as the client understands what they are getting into, and they trust your expertise, why not use WP? Maybe some think that PW should always replace WP, but they are different animals with their own strengths, and neither is a replacement for the other. To be honest, I am glad that WP is where it is and has the usage that it does. In some ways PW is successful because of WP and the path it has opened for PHP, MySQL, content management and open source. WP has helped to open the gates so that even a relatively small project like PW can have a significant self sustaining user and installation base. I see no harm in expanding FieldtypeFloat to support a decimal column type, so I’m going to go ahead and do that. Is there any issue in the existing FieldtypeDecimal that also needs to be solved when I put in this update? This is the AdminThemeFramework class, which AdminThemeUikit extends. While it hasn’t really played out that way yet, AdminThemeUikit itself was built to be a more generic base, though for Uikit-based theme) The AdminThemeUikit module (and its supporting files) are also a good template for marrying a CSS framework with an admin theme. I don’t see much potential for an abstraction layer between AdminThemeFramework and AdminThemeUikit. If I wanted to build an admin theme that used a different CSS framework, then I would copy all the files from AdminThemeUikit, replace the Uikit library with another, and update the files as needed for the other framework. AdminThemeUikit is already the default for new installations. For existing installations where someone has already selected AdminThemeDefault or AdminThemeReno as their theme, then we don’t change their selection. Although I think AdminThemeUikit has effectively replaced AdminThemeDefault, and I don’t plan on doing any more with AdminThemeDefault, other than probably dropping it at some point. I would like to keep AdminThemeReno though maybe refactor or rebuild it so that it is also using our base AdminThemeFramework. That you Jonathan, this is a really fantastic overview/presentation of the builder concepts. Also, amazing work with what you’ve built! My impression is that yes we could certainly take RepeaterMatrix quite a bit farther in supporting a lot of this (moving children with parents, limiting child types, etc.), per the things that have been outlined here and in your video. And maybe I should add those things, just to open the door at least, and let people decide how they want to use them. But it’s uncertain if RepeaterMatrix is the best foundation for this builder concept (as you’ve pointed out). To take it further, I think it’s also uncertain if pages are even the best foundation for each element or section in a builder. In a page builder, there doesn’t seem to be much technical need for all the data to be stored in separate fields and pages, because it all seems to be aimed at achieving some front-end layout rather than a flexible and accessible inventory of data. All of the sections, elements, etc. in the builder seem to be aimed at segmenting content for a particular layout on a single page. This separation is about front-end layout, and not much else (is this even content management?). I think the back-end storage of it should also reflect that. Basing it on a Fieldtype does seem to make sense, but RepeaterMatrix is really overkill on the storage side, while not enough on the editor side. Given this, it seems like a site builder might benefit from being a new Fieldtype rather than one based on Repeaters. Though I can already see there are drawbacks and benefits either way. One question for those interested in a site builder: who is the audience for it? Whether we should be looking towards something really simple, or something more complex, likely depends on the answer. It looks to me like the audience is primarily web developers, or at least people that know some web development, because you’d need some pretty savvy clients to use tools like this. Though “The Bard” looked like something I could potentially walk a client through. But it’s obviously not nearly as powerful as something like the YOOtheme builder. That one looks like Dreamweaver for Uikit. Is there demand for that? It’s technically quite cool, but is it wise or portable to couple content with layout like this? It’s clearly a compromise, but maybe it depends on the use case. CKEditor is also a compromise, but it’s usually portable and semantic enough for the content to survive site redesigns. I like and am open to adopting Vue where needed, but not at the expense of jQuery. I don’t lose interest in a particular tool just because it’s been around a long time. I know everyone likes what’s new and always changing, but for me, some of the best tools are the ones that have been around a long time. jQuery remains one of my favorite tools and an important part of ProcessWire's admin. Now if we have to change the way we use jQuery, such as using jQuery() instead of $(), in order to integrate a library like Vue, then I would be fine with that. As fun as it looks, building a tool at that level probably isn’t realistic (for me anyway). If we were to have a tool like that, we’d want to adopt an existing open source tool, much in the same way we do CKEditor. That would be ideal. If that’s even an option? I spent some time checking out the Unpoly library and thought it looked pretty great! Hotwire’s video lost me though, some guy talking on top of a video on fast forward, zipping through command lines and such, insanity, can't tell what the hell is going on.

RockMatrix --> thats a modules similar to RepeaterMatrix. When a matrix item is created, a meta entry stores the reference to the page, where the matrix item lives on. That's similar to the TrelloWire example ? RockMeta --> that are fields for the PW backend that do not store their value in their own DB table but in page meta-data. This is great, because I can add Inputfields to existing Inputfields to make them more flexible without having to create many fields in the system.

My module TrelloWire module uses $page->meta as an easy, site-independent way to associate module data with a page. The module creates Trello cards for new pages, and can update them through Trello's API whenever the page is changed. To do this, the module needs to store the ID of the card associated with that page somewhere. Using $page->meta was the easiest option, much simpler than creating a custom database table or programmatically creating a field when the module is installed. The caveat is that the value can't be updated or deleted through the user interface. However, that could be achieved through hooks. You can see how I store and use the page meta data in TrelloWire::createCardForPage and TrelloWire::buildCardData ?

Just looked at this issue recently. This seems to do the job: $this->addHookAfter('FieldtypeRepeater::wakeupValue', function($event) { $field = $event->arguments('field'); // Only for a particular repeater field // Could also use page argument for other tests if($field->name !== 'my_repeater') return; $pa = $event->return; $pa->sort("-created"); // or whatever sort you want $event->return = $pa; });

Thanks guys - Antti's was closest since this field allows multiple values. The goal for this was to pre-populate the author field with the current user's ID if the author field is empty (something that would only be the case on new articles). The check for empty ensures that editing old articles doesn't end up appending my name to them all In the module's init() function we have this: $this->addHookBefore('InputfieldPageAutocomplete::render', $this, 'addUserOnEmptyAuthor'); and the function is simply this: public function addUserOnEmptyAuthor(HookEvent $event) { $autocomfield = $event->object; if ($autocomfield->attr('name') == 'authors' && !$autocomfield->attr('value') && !in_array(wire('user')->id, $autocomfield->attr('value'))) { $autocomfield->attr('value', wire('user')->id); } } So it first checks the field is called "authors", then checks it's empty before adding the current user ID. I also left in another check (that's not required, since the check for empty is enough), but might be useful for others thinking of doing something similar, which simply checks if the current user's ID is in the list of values already. I know that even if it did appear twice in the editor, PW only saves it once, but it would look a bit odd to have the same person's name twice so there's a check for that if anyone needs it. And now I also know a bit more about OOPHP too as well as how to set default values for other fields Thanks all!

If you wanted all grandchildren, and nothing deeper, you could do this: $page->find("parent=$page->children"); If you wanted grandchildren and anything deeper, you could do this: $page->find("parent!=$page"); If you wanted children, grandchildren and anything deeper, you could do this: $page->find('');