ryan

A couple weeks ago there were a lot of ideas about page builders and different approaches in ProcessWire. Some really interesting ideas actually, and great proof of concepts as well. The conversation started moving faster than I could keep up with, and I think Teppo's summary in ProcessWire Weekly 351 is a great overview, if you haven't yet seen it. These are so great in fact, that I don't think anything I build could live up to what some of you have already built. In part because my focus is more server-side than client-side development, and I can clearly see most of these page builders are much more client-side based than I have expertise in (though would like to learn). Whereas some of you are clearly amazing client-side developers; I'm blown away by what's been built, and how quickly it happened. One struggle I have with page builders is that I don't have my own good use cases for them, with the projects that I work on. Others here (like Jonathan) already have a lot of good use cases. Clearly there are a lot of benefits. I'm fascinated and enthusiastic by all of it, but can't envision how or if I'd use such a tool in my own projects. And having experience with (and particularly close use cases for) a tool is important in hitting the right notes in building it. Likely page builder support belongs in ProcessWire in some form or another, and ProcessWire can be an excellent platform for it. But the actual page builder needs to be designed and built by the people that have expertise in the tools needed to build it, and by the people that will actually use it. I think it should be a community collaboration. For anything needed to support this on the PHP side, count me in. I don't think I've got the background to "lead" the development of the page builder, but I do think I've got plenty to contribute to it. I'd also like to continue building out existing tools like Repeater/Matrix to further support page builder type use cases. I'd like to rebuild and move the auto-save and Live Preview features from ProDrafts into the core, which should also help support some of these page builder cases. Whether these will eventually apply to the larger page-builder project, I don't know, but they'll be useful either way. What are the next steps? Who's interested in working on this? Let's keep the conversion going and move forward with it.

@LMD Thanks, it looks like a last minute optimization screwup on my part, changing a $page->set() to a $page->setForced(), when there was bug in $page->setForced() preventing it from populating $page->settings when it should. I have pushed a fix for it on the dev branch. Please let me know if you continue to see any errors.

In that case it would have to use the existing find() method, which does that: performs a find() to find the page IDs and template IDs, breaks them into different groups by template, and then performs query(ies) to then load the pages with the appropriate autojoin fields for the templates. The new find method used by findJoin() and "field=..." option is a lot simpler so it does all of it in 1 query, which is possible because you are specifying the fields to autojoin (rather than the template, so it doesn't need to figure that part out). I don't yet know if there is a downside, as I've never tried to autojoin-all before. I'm going to look into it though. But I think there are potential downsides, as 1 big query with a lot of joins can sometimes be slower and harder for MySQL to cache than a lot of simple queries. MySQL also has limits on how many joins it can perform in a query and how much data can be concatenated from a multi-row table, so it's likely that autojoin of all fields might be less reliable in some cases. I guess I see autojoin as a good optimization for some (or many) cases where it's found to be reliable and increase performance, but not all cases, and not something to use by default.

@adrian Sounds like a good idea to me. I think it would be possible if your selector specifies which template(s) are in use, so it knows what fields it can autojoin, rather than attempting to autojoin all fields in the system. I can look into it further. Though should also mention that not all fields support autojoin, so it wouldn't technically be possible to autojoin "all", though it could accomplish it by using autojoin to load what it can and then manually load the rest, so it could still deliver pages to you with all of the fields populated and no further loading necessary. Not sure if this applies to your case or not, but wanted to mention that if doing this for just the current/page being rendered, then it wouldn't be worthwhile. The efficiency benefits in autojoin come into play when lots of pages are being loaded. @Zeka It's a similar option in terms of what it does, but also quite different. The new "field=..." option (or findJoin method) uses an entirely different page finding method that performs the find and load in the same query. (This is possible since you are specifically telling it what fields to join). Whereas the options.loadOptions.joinFields you mentioned is just an option to the pages.getById() method that occurs after the find() has already taken place, and it's really more intended as an internal option rather than a public API one. The newly added feature can do the same thing more efficiently, and easily enough that I thought it belonged in the public API. One other difference to mention is that the options.loadOptions.joinFields adds to the default autojoin fields for the loaded pages rather than overrides it. So it doesn't give you the level of control that the new option does unless you don't have any fields with the autojoin flag in your system. No changes here. There's only so much that can be joined in one query per field, so autojoin is not always possible, especially on multi-value (FieldtypeMulti) fields with lots of values. It should be possible on most Page reference and options fields though, so long as they don't have huge amounts of selections. If there's need for it though, I may be able to have fields (where applicable) store a cache of data (like FieldtypeCombo does) that can be autojoined. Since you specified a field that does not exist, I think you are seeing the "no fields specified: load all" behavior here. Probably it would be better if it threw an Exception or just returned a blank result set. Autojoin isn't very useful for the current page, like the one you are rendering. There isn't likely going to be a worthwhile difference in overhead between autojoin fields and load-on-demand fields when rendering the current page being viewed. The difference becomes worthwhile when working with lots of pages that all have the same field. For instance, think of the page-list in the admin—having the title field autojoin is useful there. For most people, they probably don't ever even need to think about autojoin. But for those of us interested in optimization, it does offer some worthwhile improvements in the right situations. I wouldn't bother with trying to autojoin your SEO fields since you would only use those rendering the page being viewed. This kind of micro-optimization can take up your time without delivering benefits you'll ever feel. Though if you wanted to load them all in one chunk, a Combo field would be a great way to do that.

This week ProcessWire gained powerful new tools for finding pages and controlling how they are loaded. If you like to maximize performance and efficiency, you’ll like what 3.0.172 brings— https://processwire.com/blog/posts/find-faster-and-more-efficiently/

This week we have a couple of useful new $pages API methods. They are methods I've been meaning to add for awhile but hadn't found the right time. The need coincided with client work this week, so it seemed like a good time to go ahead and add them. I'm doing a lot of import-related work and needed some simple methods that let me work with more page data than I could usually fit in memory, and these methods make that possible. These won't be useful to everyone all the time, but they will be useful in specific cases. The first is $pages->findRaw() which works just like the $pages->find() method except that it returns the raw data from the matching pages, and lets you specify which specific fields you want to get from them. For more details see the findRaw() documentation page. There's also getRaw() method which is identical to findRaw() except that it returns the raw data for just 1 page, and like get(), it has no default exclusions. The next method is $pages->getFresh(). This works just like $pages->get() except that it gets a fresh copy of the page from the database, bypassing all caches, and likewise never itself getting cached. ProcessWire is pretty aggressive about not having to reload the same page more than once, so this method effectively enables you to bypass that for cases where it might be needed. Again, probably not something you need every day, but really useful for when you do. More details on the getFresh() documentation page. I'm going to likely cover these new $pages API methods in more detail in a future blog post, along with some better examples, so stay tuned for that. I noticed there's some pretty great conversion and examples happening in the posts on page builders here, but have been so busy this week I haven't had a chance to dive in, but I'm really looking forward to doing so. Thanks and I hope you all have a great weekend!

This week I've had to work on a client project (and that continues for the next week or two), but also have some good progress in the next development branch version of ProcessWire (v3.0.171), which includes the addition to two feature requests: The Repeater Fieldtype (and likewise RepeaterMatrix) was updated to improve support for the "depth" option by introducing something called "family friendly mode". This makes the "depth" setting behave in a manner where items with more indent are considered children of items with less indent (parents). So when you click and drag to move a parent item, it brings along the children too. This works whether changing the location or the indent of the parent. In addition, it enforces the parent/child relationship so that there can't be more than one level of indent between parent and child. So you couldn't (for example) have a parent-to-grandchild relationship in the repeater items. A useful case for this is when using repeaters in page builder contexts, like those Jonathan Lahijani demonstrated with RepeaterMatrix. In fact, the settings in this "family friendly" mode were his idea. More to come here too. To enable "family friendly mode", go to your Repeater or RepeaterMatrix field settings and make sure the "depth" setting is greater than 1. When greater than 1, the family-friendly option will appear as a toggle you can enable. The other thing added to the core this week was a FieldtypeDecimal module that has been requested for awhile. I was planning on making it a setting of FieldtypeFloat, largely to avoid interfering with the existing 3rd party FieldtypeDecimal module. But a few people indicated they'd prefer it to be separate. After testing on an installation that already had the 3rd party FieldtypeDecimal installed, I found it didn't cause any problems, so that alleviated my concern. To be safe, the new core FieldtypeDecimal module uses the same exact setting names as the 3rd party one, so that hopefully they should remain compatible. In my case, I found that deleting my /site/modules/FieldtypeDecimal directory, and then doing a “Modules > Refresh” enabled the core one to take over with any existing decimal fields. However, until we have reports that the same works well for others, I would suggest backing up and confirming it yourself to be safe. It's not often we intentionally introduce module name collisions, and I don't think we've ever done it in the direction where a new core module overlaps with an established 3rd party one. But in this case, it does seem to facilitate the transition a bit. That's all for this week. I've been enjoying and am looking forward to continuing with our roadmap discussions hopefully next week. Have a great weekend!

This week I've been focused primarily on keeping up with the conversation about requests for 2021 and beyond, as well as doing related research here. We are starting to narrow in on ideas and plans, but there's more to cover still. Most of the conversation is happening in the PW 3.0.170 thread and last week's update thread. If you want to see what our preliminary roadmap looks like, Teppo did an amazing job covering it in the ProcessWire Weekly #348. I don't recall where it was or who asked, but I remember someone asking whether things like "thumbs up" quantities on GitHub issue reports and feature requests are paid attention to. And the answer is, not really so far. That's because GitHub doesn't display this info anywhere other than on the actual issue report. And even then, I often don't notice it. But this week I've been looking into it more and see that we can sort GitHub reports by quantity of thumbs-up votes. (Maybe the rest of you knew about this, but I guess I'm slow when it comes to GitHub). So it turns out that these thumbs-up votes aren't just social media fluff, they are actually very useful on issue reports and feature requests. Usually I cover these things newest-to-oldest, but now I'm going to start going through in order of votes, as this seems to make a lot more sense. Sorry I didn't catch this useful feature earlier. Please use the thumbs-up votes on GitHub for issue reports and feature requests that you value the most, and going forward, that will help us to cover them in a useful order. Next week I'm booked on a client project (working in PW), so it may be quiet for another week in terms of core updates, but then will be back to wrapping up our roadmap and ProcessWire development. Thanks for reading this far and have a great weekend!

I'll have to think about it a bit more to be certain, but most likely it isn't a problem. And what's in your screenshot above definitely isn't a problem. If we get into 100s of these kinds of templates then I think that's where I might start to worry and think we have to benchmark and find alternatives... but that's also the point where someone has gone well beyond a simple builder.

@flydev ?? Thanks for posting that, I've learned something new about editor.js. My experience with it is mostly limited to their own demo, so I'm really just looking at it from an outsider perspective. The tool is more powerful than it looks at first. I was particularly impressed with your integration of ProcessPageEditImageSelect. Nice work. It looks like you are pretty far along with this module and it also looks like it will be a great tool for PW users. When do you think you'll be releasing it? Interesting, what you mean exactly ? From what I can tell, editor.js is one big input element, kind of like a rich text editor, even if it also isn't. I think this is also compelling, and what makes one draw comparisons to CKEditor. So editor.js could be represented by a PW Inputfield, but it couldn't itself contain other PW Inputfields (as far as I understand it). Whereas something like a Repeater is an Inputfield that contains other Inputfields. If a block in a builder can be represented by a group of Inputfields, then that means that the types of blocks you can build can be very flexible and modular. The benefit being that it expands the means by which you can extend it. On the flip side, it also means that it's not something you'd ever compare to an RTE because it's just completely different. Editor.js seems to find a nice middle ground between RTE and block builder. It does appear that every block type is defined by a PHP class, but I'm not sure if that also corresponds to a template (?). Templates are a resource best limited to not use any more than necessary (since they all have to be loaded on every request), which is why RepeaterMatrix limits itself to 1. Though maybe something like block types aren't huge quantities, I don't really know. Such a solution would need to come with several predefined block types, just as editor.js does. I think this builder focus is important, otherwise it's becomes too abstract, at which point something like editor.js with plugins becomes a clearer answer. So I'm hoping that people could get up and running by selecting existing block types rather than having to always create them. Then they can create them when-and-if they need too. When it comes to code definition, it comes with its own benefits, and I think it's fine so long as the built-in defaults/types are strong enough to answer the most common needs. Getting into this level of stuff is where the RepeaterMatrix upgrades should help. But this level of complexity I think would hinder a simple builder for the larger audience. For this particular project, I think it's best if it focuses exclusively on content tools and doesn't get into layout and style aspects. This is one of the things Jonathan and I talked about. I'm investigating options for alternate storage methods of repeater items, such as the ability to save all the content JSON encoded in the 'data' column of the repeater table (rather than saving in separate pages). It would be an option you can choose in the field settings. I'm going to try and make it happen though it's possible I may hit a roadblock, so will have to get further along before I know for sure. I think editor.js is also an answer to what many people are looking for, so we have to be careful not to lose sight of what it does well. While there are things to learn from it, I agree it probably doesn't answer quite enough of what we are looking for. Good ideas. Improvements to RepeaterMatrix are part of the plan. But that's going to be a separate project. The $page->meta() method exists for this purpose, at least from the API side. Though the values are still stored in the DB, but not as field data, just as flexible unstructured data stored for each page. The Combo field might offer potential here too, as you can bundle as many inputs as you want within a single Combo field. Though it's still technically stored in field data, and still as searchable as any other field data. But without the being a separate dedicated field and having a separate DB table for each component, etc.

I wonder if anyone else can weigh in on directions here? I know a lot of people like the editor.js direction, but Bernhard has also posted what seems like a good direction. They are very different directions, but seem to accomplish similar things. Ideally I'd like the community to narrow in on what's best for their needs and for ProcessWire. I don't think I'm the audience for this builder (my projects don't use this approach), but I really want ProcessWire to meet this need and compete in this space. I trust the community advice on this more than my preferences so would like to hear from you. I've spent some time looking at editor.js, and here's a benefits/drawbacks list that I came up with: Editor.js benefits Easy for users figure out, but does require experimenting with it to find where the tools are. Tools only visible contextually so everything is very clean, no real baggage until you need it. From a marketing/appearance standpoint, maybe good for PW (?). Storage is simple JSON, which is easy to work with as a PHP array on the front-end. That's assuming you need the content separated like this in the first place, which presumably the developer audience for a builder would be. Since it's a modular/plugin system, it has potential to offer more down the road than it does now in terms of capabilities. To me it also seems like kind of a cross between a full builder and something like CKEditor, so it might appeal to some as an alternative to CKEditor for certain cases. It already seems to have wide adoption and be an active open source project with a good track record. Editor.js drawbacks Moving blocks is not as simple as drag/drop or cut/paste. Instead you have to click up/down arrows to move a block. Interface that while nice in many respects, is completely different and inconsistent from anything else in PW. You are forced into using HTML elements (like <p>...</p>) as blocks, rather than being able to have something like a "rich text" block. It seems to me like a "rich text" (CKEditor) block is more useful than assuming every block-level HTML element to be a builder block. There are surprisingly few plugins, and few (or none?) seem to go much beyond what you can already do in CKEditor. Maybe the potential for creating our own new plugins is greater than CKE, but it's all JS and we mostly work in PHP. Unclear if there are any tangible benefits to the user relative to CKEditor. I'm also guessing most clients would prefer CKEditor since it's more like working in MS Word. Maybe it doesn't matter since this is a different animal and you might not swap one with the other anyway. If we are to do anything beyond the basics with it, it looks like it would be a lot of work. The plugin system looks beautifully simple at its base, but the actual implemented plugins look surprisingly verbose/complex for what they do. We couldn't use our existing Inputfield modules for new blocks (like an Image block) and so would be starting from scratch on a lot. I've also spent some time with Bernhard's editor (he sent me a demo) so will also come up with a benefits/drawbacks list for that. Interested in any other approaches you think we should look at also. Regardless of direction, my plan is to bring live preview and auto-save into the core, as I think all builder directions would benefit from that. Also, I want to mention the RepeaterMatrix stuff discussed earlier is something we'll be doing either way, I consider that just part of regular updates to the module, and so that's a separate project.

@Zeka Currently you can create a class like BlogPostPage and it automatically be used as the class for all pages using template "blog-post". You mentioned the PagesType class, which is used by things like Users ($users), Roles ($roles), Languages ($languages), etc. as an alternative to the $pages API var. To make sure I understand what you mean, are you saying that you'd like to be able to create a class like this: class BlogPostPages extends PagesType {} And then you'd get this API var ($blogPostPages) that limits itself to pages using template "blog-post": $posts = $blogPostPages->find("date>last year, sort=date"); Is that what you mean, or something different?

I don't have any strong opinions here, just a few observations. I like the editor.js strategy, but I also like Bernhard's strategy. For example, I like the "something new and interesting" aspect of editor.js, and I like the "something clear and familiar" aspect of Bernhard's. His screenshot is immediately clear how it all works. I don't speak the language of the headers, content and buttons, but it's all still obvious how it works and what it does. That says a lot. To my eye it's more clear than editor.js at first glance, though I've used a lot of ProcessWire and very little editor.js, so I would trust others' judgement more. One major difference is clearly that Bernhard's approach uses pages in the same way that RepeaterMatrix does (I think?) whereas editor.js uses a block of JSON. There are benefits and drawbacks to each approach in terms of storage and overhead, but from a familiar API side, the pages approach is a good and known factor, even if it is likely a bit overkill for this type of storage (as it can be with many repeater cases). This already appears to be built in ProcessWire and already in use (?), that's quite a head start too.

@Ivan Gretsky Thanks for the suggestion, I actually don't have any idea about what it takes just yet. I was thinking we'd see what we can do without a budget and if demand is there for something more (but it's not possible without funding), then we'd cross that bridge when we come to it. Whether community funded or Pro module route or another, we can talk more when/if it seems needed. Part of our plan involves more support in RepeaterMatrix for this sort of thing, so that at least is already community funded. But for the core side of things where we are looking at an editor.js type strategy, I don't know how much resources it'll take to build, but I'm hoping it'll be manageable without needing to seek funding, since we're looking to integrate with an existing tool. @AndZyk Thanks, I know your intention wasn't set the standard from that. My reply was just something I meant to mention earlier to everyone, so this seemed like a good place to do so. But of course I think it's a good idea to look at everything out there, both free and commercial, this can only help. I'm going to explore what Kirby is doing in more detail too. But I also have to be realistic that our resources are limited relative to commercial projects, or commercial backed projects like WordPress. So we won't be able to build a direct Gutenberg competitor (not that I think anyone wants us to), but I do think we'll be able to build something great.

@LostKobrakai In addition to what I've mentioned above, I openly admit I'm not great at PRs, if that's what you are looking for an admission of. I try and make up for it in other areas. Nobody is perfect and one area I have work to do is getting better with PRs. I stated earlier that this is a priority for 2021. I will revisit the PRs that you mentioned. Maybe some think it looks bad to have open PRs, but to me it looks like enthusiasm, ideas and potential. I consider it an honor anytime someone would want to contribute in this way. I actually think the majority of PRs have a lot of merit and like what I see. I almost never would say "no" and close a PR in the way you are suggesting, because I almost never would feel that way. Instead, I look for the same crossover of priorities and timing that I do when it comes to adding new features. I like having a solid repo of PRs because it's stuff that is available for when the time is right and stuff I can refer back to and know someone else is also interested. All open PRs are a "yes" in my mind and just a matter of timing. Though going forward my hope is to find more time to cover open PRs even before the timing is right, since the community has indicated this would be helpful in appearances. PRs only don't age well if taken as literal code, which is not the way I work with PRs. It doesn't matter to me if the literal code has not aged well or not because it's the ideas that matter much more. Whether PRs or not, and whether my own code or not, I go through code additions line by line multiple times, often writing and re-writing, both for QA and to fully understand the logic... so I do not care about age of any particular code. I just care about the idea, getting it right and being able to support it for the long term.

@bernhard That looks awesome! @Kiwi Chris I'm sorry to hear about what you've had to go through there, and I'm glad that you made it through all that and are doing well. I didn't say never. We're all doomed. Every day is a gift. But if people are going to ask me to entertain doom and death, then after I do that, I think it's also honest and appropriate to state there's no known present danger, odds are good that it'll remain that way for the life of ProcessWire, and the reasons why. If I were battling some condition that changed the odds then I would also want to state that. @AndZyk Kirby is a commercial product so not really a direct competitor. In our case, we are talking about what can be built without a company paying for it, and without any budget for that matter. So while I think it's good to look at, I also would say to everyone that we have to be careful about setting core builder expectations from other projects, especially commercial and highly funded ones.

Yes, this is also what I was liking about it. I think the only thing that gave me pause is the development side of it. The plugins don't look as simple to develop as I thought they would be. At least, the learning curve there looks a bit high, and the amount of code to develop something simple seems more than I would have expected. But the same is true of developing CKEditor plugins, and none of those are deal breakers. This seems to be the nature of JS based plugin systems. I do feel like I need to find all the editor.js type options, as I'm guessing there are similar projects we should explore before picking one to build from; even if editor.js seems the most likely at the moment. Sounds awesome. I'd encourage you to release it as a module if you can. The reason I'm looking at two strategies is because I agree that the editor.js approach is great, and probably a good fit for many (or most). But there's also users like Jonathan Lahijani, where the editor.js/bard approach is not nearly powerful enough. The repeater approach does have the power, even if it's not as immediately intuitive. That's why my plan is to further develop RepeaterMatrix to better support those that want to use it as a builder, while also pursing a simpler strategy along the lines of editor.js. Does this mean that either approach is going to answer every need and interest for everybody? That's unlikely, but hopefully it'll be a good start and get the momentum going. If we were to use editor.js, then I wouldn't expect one's template code to consume JSON. We'd map the JSON to an object (or array) so that it could be used just as easily as page fields. Right, same kind in terms of what it stores. In terms of implementation, I think we are talking about 1 core direction, but 2 different directions overall. Neither direction at the expense of the other. A reasonable one that the core provides (editor.js approach or similar). And then upgrades to RepeaterMatrix for those that want to use it as a more powerful builder. So the 2nd option would simply be ProFields RepeaterMatrix, and it wouldn't even be a builder per se, but it would be ready to be used as a builder a lot more than it is now. Not flaws per se, but features that would make it better support use as a builder. That's what I'm looking to add. For a repeater matrix based builder, this would be at the discretion of the developer as to how and what they wanted to store. So in your case you might want to store something more abstract, whereas someone else might want something directly tied to their output framework. For the simpler/editor.js type builder, I don't think it would get into this type of layout thing at all. This is all true, I don't think you would be able to on the editor.js side. The elements are defined by editor.js plugins, static code. Just like CKEditor plugins. Though we'd probably bundle a lot of plugins and build some of our own. Ultimately the editor.js route will never be as powerful as the repeater route in this regard. But it will be very easy to setup and very accessible. This is something Jonathan and I discussed on our call last week. The storage behind Repeater/Matrix is overkill for the needs of a builder, so what would be ideal is if repeaters had an option to merge some of the storage needs. It's something I'm going to be looking into, though I'm not yet sure what's possible. This is basically what the new Combo field does. Though they are connected to the database, but a repeatable Combo field wouldn't require pages for storage the way Repeaters do. Nevertheless, for a builder, it seems that the underlying pages do bring a lot of benefits, even if they are overkill for the need. This is already true. But I still think the two-tier route offers the most benefits. On one side something simple like editor.js, and on the other side, something ready for more complex needs based off an existing Fieldtype like RepeaterMatrix. Also, Bernhard's solution in the other thread looked pretty great too; he said it was similar to repeaters in some fashion, also using pages from what I understand. Will do. That's true. Use ProcessWire (or any other tool) for what it has right now. You are right there are no guarantees about which features or ideas will be implemented, even for me. There have been cases where someone needed something and decided to sponsor it for the community, by hiring me or someone else in the community to build it. Outside of that, I have to find a crossover between feature requests and the needs of the projects that I work on with my clients, or with Pro modules. I can't afford to build features just for the sake of building them; I still have to find a way to fund them and then support them afterwards. The way I do that is by developing stuff that finds a balance between client needs and project needs. That way I don't have to bear all the development costs myself. The Pro modules also help to fund the core, though they also are significant projects in their own right, so I try to put much of Pro module budgets back into Pro modules themselves too. Though I put the question out there because I thought this year I could get into a couple of things that go beyond the usual development path. I'm admittedly cautious about what gets pulled in, and there's no guarantee that a PR submitted without prior discussion will ever be added. I'm also serious about supporting this project for 10, 20 years or more, so anything that gets pulled in also becomes responsibility to support it for life. The person that submits the PR does not have that responsibility. I need to make sure I fully understand and can support anything that gets pulled in. I also have to make sure it's worthwhile for the majority of users. So my preference is for PRs to be preceded by a discussion before someone creates it, so that we can evaluate needs and timing, etc. Sometimes something can be added very easily and without a lot of investment to review and understand it all, and I try to cover those once a year, or more if possible. The guidelines are here (https://github.com/processwire/processwire/blob/master/CONTRIBUTING.md) and while they do touch on this, they could go further. I will work on that. Thanks.

I'm not sure I understand what you mean. We've got templates which define a Page's type in terms of fields, behavior and access. Then we've got custom Page classes which define a Page's type in terms of its API, which can also extend other Page classes. Then we've got Page tree/hierarchy/parents, which define their type in terms of location. I'm not sure what's left. ? Is there some other kind of page type you are talking about? I will update the AdminThemeUikit repo. Unfortunately I've run into some npm error where it wants to do some kind of updates before it will update the UIkit version, but updates it wants to do in npm fail. This seems to happen every time I want to update something that uses npm, but I always eventually find a way around it. This last one has had me stuck for awhile though. I'll revisit it here soon. I've never liked these command line package installers/managers because they always seem to have some problem without a clear answer. I guess it's the nature of the beast. In this case, you've modified the core _masthead.php. Don't do that. ? The intention is that an admin theme would provide its own _masthead.php file (or whatever you decide to name it). Actually I was thinking admin themes would replace all of the markup files. That's in part why they are all split out on their own. The updates added to AdminThemeUikit last week make it so that you no longer have to provide your own markup files if you don't want to, but for your case where you are changing method calls and include statements in those markup files, you'll no doubt want to have your own markup files. This gets into more overhead than I'd want to be involved for rendering the admin theme... at least for the core default one (AdminThemeUikit). I've even tried to actively avoid the traditional type of hooks here, so that the admin theme itself doesn't add its own overhead to the request. There's nothing faster than include() of a php file to render something, so that's the strategy AdminThemeUikit takes. Admin themes use a different kind of hooks for adding markup in parts of an admin theme, and they actually aren't really hooks at all, even though I still think of them as being a type of hook. You can call $adminTheme->addExtraMarkup($name, $value); to add extra markup to various parts of the admin theme. Any module or admin template code can do this any time during the request, up until the admin theme gets rendered (at the end of the request). The $value is the markup you want to add, and the $name is a region name where any one of the following are currently recognized: "head" - adds markup before </head> "masthead" - adds markup in the div#pw-mastheads "notices" - adds markup after the notices/notifications "content" - adds markup in div#pw-content-body "sidebar" - adds markup in #pw-sidebar, only if theme uses a sidebar "body" - adds markup before </body> "footer" - adds markup in footer#pw-footer This is the strategy that the admin themes use to support other modules in adding markup where necessary to the admin theme output. This is faster and simpler than using a traditional hook. More region names can be added easily if/when we need more. If developing your own admin theme, then you don't need hooks or the addExtraMarkup() function because you can already override anything in the AdminTheme you are extending, you can provide your markup files as needed, and add your own methods as needed. Admin themes should still support markup added with addExtraMarkup() though, but it's easy, just $adminTheme->renderExtraMarkup($name); at the appropriate spots in your admin theme template files. If there's anything I can add to make it easier for people to have a dashboard page, I'm happy to. But I don't currently think it should be built into the core. The core doesn't have anything worthwhile to communicate to admin users in a dashboard, so it would just be extraneous fluff (i.e. "numbers", "more numbers", and "numbers again"), like it seems to be in most systems. The kind of stuff that makes a simple system look complicated. Others may have something specific they want to communicate to their logged in users, and that's where I think it becomes worthwhile. If there's demand for it, I'd be more interested in hearing not about a dashboard, but about what one is wanting to communicate with it. Thank you for continuing to develop this. I agree there are benefits. This may be something we should keep talking about for the longer term. With the exception of WireMail, all the classes you mentioned are intended to be available for standalone use. Though it's been a long time since I've used any of PW's classes in that way. This I think is likely an easily attainable thing to support though. Most of the mentioned classes just extend the Wire class, making it the only dependency (and Wire doesn't require a DB connection). A DB connection would be needed for WireMail because it is a module type. Installed modules are known from the database modules table. A WireMail module also maintains its settings in the database. Now is is true that the base WireMail class can operate without a database, but WireMail is only useful because it is a module type. Take out the module aspect and WireMail is just an interface to PHP's mail(). The core datetime field is meant to store a single date/time, but that's it. I agree that sometimes a need arises for more than a single date/time. ProcessWire core is meant to focus on the basics, while supporting modules to accommodate a broader set of needs when they occur. I think this is a good example of a need that is nicely accommodated by a module that you've developed. Thanks for sharing the strategy you are using here. It's great to see the different solutions people are working with these last couple of weeks. From the screenshots I really like the approach you are using here. It looks powerful while easy to understand and client friendly. Yet also looks very PW familiar as well. Visually it might be the clearest I've seen, even relative to something like The Bard. The means of definition does also look simple, though I think for something that other developers would use, they might prefer that the front-end rendering be isolated from the back-end component. Something that makes it easier for you to provide pre-written components, while they provide the front-end markup. For instance, maybe the render() method delegates to a front-end template file somewhere in a subdirectory off /site/templates/fields/? And if there is not file, then maybe it provides a default output. The reason repeaters store their pages off in the admin structure is to solve these things. But it does come with its own challenges as well. Most likely I wouldn't be able to make any more commits to the core if I got run over by a train. I've always thought this was one of the reasons to use open source, ensuring that when someone smacks the tracks, the code doesn't. But it's not just about being open source, the code also has to be clean and well documented so that others can easily take it on board. That's one reason why I put so much effort into code quality and code documentation. My intention is that the code is always ready for others to understand and work with. As for commercial services/modules, it's the same risk inherent with any product or service you pay for. While not open source, the Pro modules do have the same code quality and documentation as the core, and are not obfuscated or encrypted. If it sets your mind at ease, I'm 46 years old (not 76), and am very healthy. I run and lift every day, eat lots of salads, don't eat red meat, and don't participate in any dangerous activities. Most likely I'll be here for at least another 46 years. But if I'm ever derailed then I know the project would still be in good hands. Seems like it might be simple to do. Can you expand on this? When/where would you use it?

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?

Using text elements as an example, semantic would refer to the meanings, like headline, paragraph, list, blockquote, etc. Things that wouldn’t change and would be portable even if the whole site got redesigned. Whereas layout or style of the text would refer to where it goes and how it looks, columns, grids, fonts, etc. Things that usually accompany a site's design. It seems like some of these builders (like YOOtheme) might be blurring this line and mixing it up to some extent (?), and so I’m trying to better understand that, and if or where it makes sense for us to draw that line.

It makes sense in FieldtypeFloat because they both represent numbers with decimal points, they would share most of the same configuration options, and they would use the same Inputfield. A separate FieldtypeDecimal module is also good, but since that’s already a module that exists that people are using, I don’t want to cause trouble for anyone by getting into that namespace. I also like to avoid adding new modules to the core unless absolutely necessary. A FieldtypeNumber would be too broad and too much overlap with existing modules. Keep in mind we’re talking about the module class name here, not the module title, which could be something like “Float or Decimal”, rather than either/or. Thank you, that clarifies a lot. I can see how this would be just right for a marketing person at a company. It's been a long time since I've worked with a marketing person, so I hadn't thought of it. What I meant was, is there demand for a YOOtheme type builder in ProcessWire? Like, would anyone’s clients use that, or would it be another tool for us developers? It sounds like the answer is probably yes to both. But WordPress is conceptually very different from ProcessWire, where this mixing layout and markup and content might be fine. Whereas I think people look for ProcessWire to be a little more best practices oriented, in which case it might make more sense for the builder to be more semantic than layout oriented. Defining columns, grids and things of that sort seems more about layout than content? I’m sold on a builder, but trying to get more clear on where our boundaries should be.

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.

@szabesz Isn't there already a decimal fieldtype available? I thought there was already a solution for that need, though I've never had the need for a decimal fieldtype so I've not tried it and don't know if it's lacking anything. I guess I figure the ideal situation for something like this is if it's developed by someone that also uses it. But if there's not one available, or what's available is lacking in some way, or not maintained, etc., then I could look into it. Or maybe FieldtypeFloat could be updated to support either decimal or float column type (like FieldtypeCombo).

@Robin S I've pushed an update to the dev branch that makes it simpler to extend AdminThemeUikit. As far as I can tell, the reason you got the result you got before is because your admin theme was likely missing all of the other files that go along with an admin theme (?). So the reason you can't just extend AdminThemeUikit and be done with it, is because the module file is only one part of the admin theme. I've updated it so that AdminThemeUikit is now built expending that you might extend the class, without all the other files. So now you can create an AdminThemeUikit derived module like this: File: /site/modules/AdminThemeTest/AdminThemeTest.module <?php namespace ProcessWire; class AdminThemeTest extends AdminThemeUikit { public static function getModuleInfo() { return array( 'title' => 'Test Admin', 'version' => 1, 'summary' => 'Test extending Uikit admin theme', 'autoload' => 'template=admin', 'requires' => 'AdminThemeUikit', ); } } You'll also need this file in the same directory: File: /site/modules/AdminThemeTest/controller.php <?php namespace ProcessWire; if(!defined("PROCESSWIRE")) die(); require($config->paths->core . "admin.php"); The above would just be the same thing as AdminThemeUikit. But at that point, you can easily override and extend anything from the AdminTheme, AdminThemeFramework or AdminThemeUikit class. For instance, here the same module as above, but I'm extending the renderExtraMarkup() method to add some more markup to <head> to make the primary headline <h1> smaller (not suggesting this would be the right way to apply CSS though): <?php namespace ProcessWire; class AdminThemeTest extends AdminThemeUikit { public static function getModuleInfo() { return array( 'title' => 'Test Admin', 'version' => 1, 'summary' => 'Test extending Uikit admin theme', 'autoload' => 'template=admin', 'requires' => 'AdminThemeUikit', ); } public function renderExtraMarkup($for) { $out = parent::renderExtraMarkup($for); if($for === 'head') { $out .= "<style type='text/css'>" . "#pw-content-head h1 { font-size: 24px }" . "</style>"; } return $out; } }