ryan

@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; } }

Good, yeah I’m happy with it too. But I’m just thinking having a regularly updated fresh look would be helpful for attracting new users. It wouldn’t be at the expense of keeping a solid utilitarian theme for when more serious work needs to get done. Sounds good. If that’s the case, maybe a good place to start would be for some of the skilled designers in the community to propose some tweaks to what we already have. I personally would like to see something fresh on a regular basis, but again, not at the expense of also having something solid and consistent. PW supports multiple admin themes for many reasons. Sounds like a good idea. I wouldn’t know where to start with deciding what specifically is adjustable in this way, but I could certainly make it happen on the configuration side. I was not aware that AdminThemeUikit couldn’t be extended. It was intended to be extendable. Most likely there’s a simple fix. I will correct that. It’s already quite hookable. But if you can tell me more specifically what additional methods you’d like to be hookable, I should be able to do it. Can you give an example use case? In ProcessWire, all modules already have access to the internal API, which is always going to be more powerful than an external one could ever be. So I’m not sure I understand yet how shared code like modules would benefit in this case. So far as I understand it, this seems like it’s the primary benefit in the PW context. I think there’s likely a distinction between new users that are used to some other platform, and new users that haven’t spent a lot of time in other CMSs. In my experience, users new to CMSs (rather than just new to ProcessWire) figure it out very quickly, with little or no guidance. Whereas users used to something else (WordPress, etc.) encounter something entirely different, and everyone inherently prefers what’s familiar. But users are going to increasingly be "used to" something or another, and more likely WordPress than not. That used to be the case around here too. But today I’m finding more seem to be aware of the downsides of WordPress and the liability it brings. It’s seen as a target and a risk with baggage. At least if there isn't someone keeping an eye on it and taking care of it; so it's a responsibility, which means it's also a cost. But the fact that you can run any version of ProcessWire (even a 10 year old version), without worry, it says a lot. Meanwhile, ProcessWire has been powering websites for as long as WordPress has. But it’s been doing so without the risk and drama. Like I say, PW’s record speaks for itself, as does WP’s. Given a choice of popularity or long term security (which is what it comes down to), I leave that for the client to decide what's in their best interest. ProcessWire may have been a new player or unknown factor at one time, but that was a long time ago. Not only is it open source, but ProcessWire has more than a 10-year track record in open source, and a 17 year development record in total. It is used by tens of thousands of websites by thousands of web developers worldwide. It has been in active development the entire time. There is nothing proprietary about it (open source and PHP). It is well documented. It is coded in a manner that makes it accessible to any competent PHP developer. It is both developer and community supported. And when it comes to things going wrong, it’s far less likely to happen in ProcessWire in the first place. Other projects come and go. I think it's safe to say ProcessWire has been, is now, and will continue to be one of the most stable players in this space. Yes, again for appearances. But there's not much downside here. I’ll try to give this some more focus. How does that work? Is it anything other than dg just committing code from adrianbj (same as a copy/paste), or does it have something more technical going on with regard to the merge?

@Zeka Thanks, I still feel this is redundant in PW, but it's been mentioned enough times that I can't rule it out. So will keep eyes open here. Yes, if you mean things like S3 storage or similar, this is something I've been interested in too. This is definitely on my wishlist too.

Awesome! Thanks @Jonathan Lahijani that would be great.

Ouch. But this is really common. When it comes to a developer working at a company, new software is sometimes a threat. It's always easier to work with what you already know than to take a risk on something new. JSON files are nice and simple, so it's hard to argue with the sole developer and content editor; maybe PW is overkill for his needs. There's nothing hacky about getting PW data into JS. It's very simple. But I get what you are trying to say, is that PW doesn't do it, so it's the developer that chooses how to do it. Here's the problem, and reason why I haven't made PW do it, as simple as it is — the only real front-end input request that returns data from PW is the URL. And the contents of the returned data is at the discretion of the developer. That's it. It's incredibly simple and an amazing security barrier. Once you have a JS API to PW data, it sounds really cool... until you consider the security implications. What makes the PW API so useful is that you have access to everything as if it was already in memory. This is great in PHP because only PHP has access to it. But anything that JS has access to is also open to the world. Anything could slurp up anything from the API at that point, not to mention it would be a huge denial of service hole. The exception is if it's all behind some kind of authentication. But the vast majority of PW websites are not built behind a login wall. So then we might say, we just apply restrictions to what can and can't be loaded from the JS API. But at that point, it's taking just as much work as if we just output our own JSON, while still likely not as secure. I remain really interested in the idea, but so far have not been able to get the math to add up in being a worthwhile venture. I even built a module years ago called ServicePages that did some of this, and I got so disturbed by the potential implications of it that I ended up deleting the module permanently. Meanwhile, outputting just what you need for your JS remains 100% secure and simple. Maybe someday we can get the math to work here though. I think it's great he's building this. While I don't think the core needs to expand in this direction, I really like to see modules like this get built that can fill needs as people have them. The more the core can support people in building modules that solve their needs, I think the better. There are very good reasons why the admin and front-end are different environments that do different things. I think it's best if the core doesn't dictate much about the front-end, and always trying to keep PW as far from generating markup as possible. So I don't think it's likely PW would provide all of the admin in the front-end, other than the existing front-end editing features. But I don't think that's what you meant. Can you clarify about what you are looking for here more specifically? What front-end functionality have you built that you think should be in the core? Interesting, I don't know much about this, but it does sound like a good Fieldtype to have. What do you use a recurring date for on the front-end? I don't have a good answer for that particular issue report because it's asking to disable access control in a manner that I just don't know how to do safely. But I'll look at it again. There will always be little things, especially for people like you and me, who work in PW more than the most here, and probably represent less than 1% of the PW users. But I have to balance time between the little things and the big things in order to keep everyone happy. Likewise, when it comes to prioritizing issue reports, I have to consider how many people are affected by an issue and whether workarounds are possible. Hundreds of minor issue reports were resolved in 2020, and likely 1-2 months worth of hours getting through them. This is part of the job that I do every year and will continue (and actually I enjoy it). I could spend 6 months doing nothing but issue reports, but it likely wouldn't make any difference to 99% of users and would hurt the rest of the project. So I try and find the right balance. I don't know who would need that feature other than you and I didn't even know it was there, but if this is a major pain point, maybe we can build you a voice command for it. ? Kidding aside, I agree that it's good to start thinking about new stuff in the admin theme in 2021. I like the current Uikit admin theme, but I also used to like the old AdminThemeDefault too, and now it looks so primitive and behaves so clunky relative to AdminThemeUikit. So I imagine to some users, maybe the AdminThemeUikit is starting to feel old since it's been around for a few years now. Ideally we'd have a new admin theme design every year, and maybe someday we will. I'd like to stick with Uikit 3 as the underlying framework, but the look/feel can be a blank slate.

Yes the flexible content one seems to be a recurring theme, so I’m interested in that. As far as non-external headless, ProcessWire was the first to do this, at least as far as I know. The admin was later built in as an application in ProcessWire. For external API headless, this has been something I’d planned to do years ago (per old roadmaps and JS APIs). But, when it came to actually starting to implement it in the way I thought it would be useful, I found it opened a can of worms in terms of security. And security is one thing that you can trust I won’t make compromises on. I’ve come to settle on being comfortable with an external API so long as it is protected by very strong authentication. But then it also becomes less of a common strategy to build around, and more of a specialist thing… maybe useful to a small percent of users. Maybe there’s a middle ground and it’s worth revisiting this year. I've recently been in contact with @Brett who is is working on some really cool stuff with GraphQL (and more) and ProcessWire, which I'm following very enthusiastically. I definitely wouldn’t expect it to feel as slick as anything built for the purpose, as RepeaterMatrix was not intended for that. But the fact that it can be used at all for that need means we’ve probably got a good head start. Since this strategy doesn’t really fit in the projects I work on, it leaves me at a bit of a disadvantage in being an expert on it. Nevertheless, I’m interested in building it, but might need someone else work with. It sounds like you have a lot of experience here, interested in collaborating on it? This is subjective of course. I’m the opposite, a sidebar drives me nuts. But I’m not against sidebars, just against sidebars for when I’m using PW (or anything else where I have to be productive). I’m simple minded and easily distracted, and focus on one thing at a time. I can't do the multiple-monitors thing, and whatever window I'm working in is always maximized. Sidebars always compete for my attention in a way that other things (like mastheads or footers) don’t. But I'm probably the minority in this preference. When it comes to our next admin theme (or evolution of the current) I think it makes sense for something like a sidebar to be a configurable option. I’m too many years beyond my graphic designer days now, so I don’t think I should lead the next iteration of the admin theme. But I do think it’s a good time to start thinking about the next iteration of the admin theme, as well as dropping the older ones. I think you are providing good answers to the question. Unique and groundbreaking are not requirements by any means. The core is in a really great place right now, the foundation is solid, more so than the other projects out there. So now’s the time to start looking for what’s going to the most helpful to current and future ProcessWire users going forward, and start implementing them. This is the drawback of having a developer that’s committed to a project for life. I could be wrong, but I don’t think there are many projects like PW where the developer has been working on it for nearly 20 years, and is committed to working on it for at least another 20 or more. Not to mention, committed to make it easy for others to work on as well. Most people work on stuff and then move on to other stuff. I don’t do that. So I look at every PR a lot more critically than I think most projects do. The PR submitter submits the PR and that’s the end of their responsibility. Whereas, every bit of code that gets added to the core is something I accept responsibility for. It's something PW users and my clients trust me to vouch for. I look at new code in the core through the lens of supporting that code for the next 20+ years. Nevertheless, I do try and identify PRs that can be added and supported, and then take the time to understand how they work, and even recode them if necessary to fully understand how they work, so that I can support them in PW’s core for the long term. It takes awhile to work through them, but I’ll continue to do that. My preference is always that we talk about the PR before someone takes the time to code and submit one, so that we are on the same page about the goals and timeline for it, and getting all the details right. PR's that come in unsolicited are fine too, but they do take me a lot longer to get through. PW will always be a project that puts security, stability and long term sustainability above appearance or popularity. I understand there are times where a project calls for using what’s popular, and I see no harm in doing that, so long as you are also committed to supporting that decision as being in the best interest of your client. PW’s track record speaks for itself. WP’s track record speaks for itself.

Thanks for the feedback. Just to be clear, this question is not looking for answers about the location of issue reports, wishlists, PRs, or feature requests. All of that is already clear, always important and ongoing — great stuff, but also information we already have. It never hurts to be reminded, and of course we'll be working with much of that in 2021. But that's not what I was asking about. Zoom out and look at the bigger picture, and look towards the future—what's game changing and "next level" for the years ahead that we might not already know about? It doesn't have to be unique to PW either; maybe you see another project doing something major that would be nice for PW to also be able to do. I might be unique in this respect, but when I develop sites in PW now, it doesn't feel as though I'm lacking or compromising anything at all; everything I want and need is there. But my needs are also pretty simple. I do know that in the last couple of years, Markup Regions and custom Page classes were the two most recent game changers [for me at least]. But that's all the past. There will be more game changers for you and me, I have some ideas about things, but nothing concrete. I recognize this is something that's going to be personal and different for everyone. For the majority, I really doubt that any single product meets every need you have, whether ProcessWire or something else. But the intention is that ProcessWire can meet most of them, and better than other projects, for our current and future users. I'm trying to put together a long term, big picture roadmap (2021 and beyond) that keeps us focused on that. I have thought this sounds interesting no doubt. I'm interested. I'll catch up with it again. Not speaking of this particular feature request, but more in general. Unless it's something most people need, I look at a lot of specific feature requests more from the perspective of "how can the core best support someone in being able to fill this need?" (from a module, hook, etc.). For stuff where the need doesn't also surface in my own projects, I'm not an expert on it, so I'm not as likely to be able to please the people that do have the need. But making the core flexible enough to accommodate some need with module or hook, or something else—that's where I am an expert and can provide a lot of value. Improving the core by expanding its flexibility in accommodating things for people that wanted them, and not necessarily expanding what it does on its own. I like the GitHub requests repo or the Wishlist forum. But if you already have a GitHub account, I think it's a little easier to keep track of there. I'm not all that familiar with this as it seems to be a strategy that doesn't really meld with the types of projects I work on. But I've always been interested in it, and it seems to fits the big picture role I'm talking about. It's something I'd like to spend more time with in getting to know better. I know a lot of people use various strategies here already. But it's adapting things like repeater matrix to fill the need rather than something more designed for the purpose. I'm curious if you could expand more on why this is your personal favorite and how you would use in in your projects? I think this is something that might be too specific of a need (I'm guessing not many run into it). But it is actually a need I have had here. I've always answered it just by building whatever feature was needed into the front-end of the site. So the front-end basically has a custom-admin portion, for logged in users that have a particular role. Usually it's publish/unpublish/approve/disapprove something or another, list reservations, toggle things, etc. Simple stuff that needs little explanation. Though when the need involves full page edits (body copy, images and such), that's really what PW's admin is for, and that's where I'll put them. But if a user doesn't need to be using the page editor, then I don't bring them into the admin at all; and instead use the API to for simpler admin functions built into the front-end. Is this similar to your use case, or are you thinking of something different?

Happy New Year! Today I’ve bumped the version on the dev branch to 3.0.170, and it’s quite a lot of updates. This post covers most of them. In this post, there’s also a question for you: what would you like to see in ProcessWire in 2021? https://processwire.com/blog/posts/pw-3.0.170/

This week I’ve been doing some work on the core, but it’s been a short week with the holidays, so I’m holding off on committing the updates till I can test and tweak them a little more next week. I’ve been working on some upgrades to the core Fields editor (Setup > Fields), as well as some improvements to our Inputfields system, among other things. Next week I’m also planning on working through some of the GitHub issue reports and some other parts of the core as well. With it being Christmas today, I’ve barely been at the computer and I’m guessing not many of you are either, so I’ll keep this short and wish you and your family a Merry Christmas and/or Happy Holidays!

I see, yes that's true. If you move all the subfields out of it, then it's basically just a non-visible placeholder at that point.