Leaderboard

In this video, I demonstrate YOOtheme Pro's Builder (WordPress) and talk about its approach and benefits. I then demonstrate 3 different builder concepts in ProcessWire using Repeater/RepeaterMatrix, two of which are modeled after YOOtheme Pro's builder and their limitations along with some suggestions. ( @ryan ) (note: there are many more considerations when it comes to a page builder, but if there were some sort of css-framework agnostic layout tool, that would solve the biggest page builder problem) Please share your thoughts.

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

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

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

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.

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

What @szabesz said is what I'm thinking as well. There is an ick-factor among developers and page building tools because it crosses the line of keeping content separate from the structural display of that content, but it's incredibly useful for landing page type pages and the marketing people who often manage them. @ryan What approach did you take in building the ProcessWire.com Home page? Entirely hardcoded? Matrix for each main section (overkill since that hero is only used once)? If I wanted to add more text beneath the two buttons in the hero, how would I do it?

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

They are not synonyms and their loose definitions are sure to cause confusion. Here are my definitions: Site Builder (aka Full Site Editing / FSE): a no-code type tool that allows you to create a website, including global portions like header and footer. Good for basic websites and non-technical people. See brizy.cloud as an example. Layout Tool: something that allows you to create a section/container/grid/cell structure for a specific page in a visual, no-code way. Components: simple things like Headline, Text, Image to complex things like Table, Definition List, Video, Slideshow, Slider (ie, things that are basically repeating content). YOOtheme Pro: a mega-theme that turns a WordPress website into a Site Builder. YOOtheme Pro's Page Builder: it's the part of YOOtheme Pro that you encounter to build a page in WordPress, as shown in the video. It's a combination of what I'm calling Layout Tool + Components.

Hotwire is an alternative approach to building an SPA without having to do the whole API-first approach, whereby a frontend in React would consume some JSON API. Instead you just build a site the classic, server rendered way, sprinkle in Hotwire, and it makes it work like an SPA. Behind the scenes, it's working with actual HTML instead of JSON, which is the key difference. It was born out of Hey.com, the new email service from the creators of Basecamp. I strongly recommend listening to this podcast episode with DHH. He and Adam Wathan (creator of Tailwind) get deep into it: https://fullstackradio.com/151 As they say in the episode, it fits my mental model. I don't think ProcessWire from the admin side of things needs to be an SPA. However Hotwire could be used on the frontend if a developer decided.

For years, as a personal project, I've been documenting my little corner of the globe via my personal website www.marlboroughonline.co.nz, which also gets used as my testbed for new ideas with ProcessWire, SEO and other stuff, as I'm not going to have some client on the phone if I break something, but if I do it well, I can earn a few dollars from Google adsense. I've always had a bit of a passion for natural history, being introduced to David Attenborough documentaries when I was a teenager, and actually studying life sciences at university, so it's only natural if you'll excuse the pun, that a part of my site would be dedicated to documenting local plant and animal species in my part of the world. For many years, one of go to reference websites for information about native plants has been New Zealand Plant Conservation Network, and I often include a link from my site to details on a species on the site as an authoritative reference, and I use the site to help identify plants I've photographed. It was only recently that for some reason I decided to have a look at the source code of the site, and it looked suspiciously like it was made with ProcessWire. After a bit more detective work, I found out that it was made by @Robin S and is indeed built with ProcessWire. To get away from the computer, I also teach kids edible gardens at my daughter's school a couple of hours a week. It's part of a wider Enviroschools programme here in NZ, and among other things it covers is teaching kids to recognise noxious weeds. There's a really useful website Weedbusters that's supported by councils and used as a reference for many invasive plant species, and it turns out it's more of Robin's handiwork. I think it's a bit funny that even when I'm supposedly away from ProcessWire engaging in other activities, it seems to follow me around. ?

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

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

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

I often develop ProcessWire websites for large companies and organizations, where there are 20+ employees. In these scenarios, my point of contact is almost always someone with a marketing or managerial role. Here are the actual positions I just pulled from the email signatures of my go-to contacts of several of my clients... notice the similarities: SVP Marketing Marketing & Business Development Marketing Associate Director of Marketing Director of Marketing (again) Assistant Marketing Manager Marketing & Communications Coordinator Production Artist Office Manager These marketers are the ones who manage the day-to-day content needs of the site. They are not coders, but are generally technically savvy. They like ProcessWire, or at least the way I set it up. They oftentimes need to throw a page together that's not strictly defined by a template. They need some flexibility to express themselves. While this can be done with Matrix in its current state (say you made 20 different sections that they can choose from), it requires a lot of planning beforehand and can't handle edge-cases without developer involvement.

Sure, but to some extent, we have been locking ourselves to the future of some technologies for decades - PHP, MySQL, jQuery. This is not necessarily a bad thing. It depends on the maturity of the technology, I suppose. Sometimes it depends on the needs of the users of the tool you are providing, for instance, Bootstrap 5 removed dependency on jQuery having been 'locked' in for at least a decade, I reckon. GitHub did the same. Sorry, my examples are all jQuery-related - it is just a coincidence ?.

Off the top of my head if I had to name the things that are going to be — and, to be fair, have already been for some years now — potential "game changers", it'd have to be "flexible content" (as in some sort of page or site builders) and "headless" (as in native, external APIs). Neither of these is anything new, and both I believe have been mentioned here, and perhaps even existed on our roadmap in one form or another. In my experience the API part is driven largely by developer intent: there are many developers out there who prefer to work with something like JavaScript, or simply want to make a more clearly defined distinction between the data (API) and the application/front-end. WordPress has a native REST API, which (while not perfect) often gets the job done. Bolt has native REST and GraphQL APIs. And then there are all sorts of headless CMS' out there (Contentful, Strapi, Prismic, and so on) that have taken this even further, though I'm really not an expert on those myself. If ProcessWire wants to attract more developers, especially the types that enjoy working with modern technology and particularly JavaScript, this might be worth considering. Modules like AppApi and Process GraphQL have done a great job at providing an almost-out-of-the-box solution, and it's also very easy to build APIs on top of ProcessWire, but a native API would bring certain benefits that none of these solutions can do. That being said, it would also likely be a massive undertaking and would no doubt require a lot of planning: ProcesWire has a fantastic "internal" developer API, so the bar for a built-in "external" API would be pretty high ? As for flexible content, this is now something we use for pretty much every site we build. Unless it's a registry of predefined items (which is pretty rare), it's going to benefit from some sort of flexible content strategy. These days most content editors just can't be satisfied with "here's a CKEditor field, it works kinda like Word" — they demand quite a bit more than just that. We've been using RepeaterMatrix for this purpose and for the most part it works, but I do have to admit that it doesn't feel as slick and intuitive as some of the competition. Both Kirby and Bolt have interesting ideas in this regard, and Gutenberg is starting to look very interesting as well. Finally, a pet peeve of mine: the admin. While I really enjoy using ProcessWire's admin, there are also things I don't quite enjoy. For my taste it feels a bit overly verbose with all those lines, and when I look at the screenshots from something like Bolt, I really miss a sidebar. A proper one, one that stays in place, like the Reno theme had. I know I sound like a huge WordPress fanboy, but this is something they got right early on, and based on user feedback I'm not alone with that opinion. ... so that's one smaller-but-still-possibly-somewhat-meaningful feature I would like to see on our roadmap ? Now, having said all that: I know this is nothing "unique" or "groundbreaking". A lot of other systems are already doing these things. I would love to throw in an idea or two that no one has yet thought of, but honestly I think on the web today it's more about "who does it best" than "who has the most unique ideas".

Hear, hear! ? One place to find ready answers to this question is the requests repo: https://github.com/processwire/processwire-requests/issues That repo currently has 289 ideas for improvements, and it would be fantastic if you can find the time to do a quick first pass through the repo and add any comments or questions to the requests, and indicate which ideas you think are the most promising for developing this year. At the top of my wishlist is an Image Reference fieldtype: https://github.com/processwire/processwire-requests/issues/207 I'm imagining something that works much like a Page Reference fieldtype, with various options for defining which images are selectable and some elegant way of selecting from a large number of images (maybe a modal interface similar to Lister that lets you filter and select images for adding to the field).

I am thinking about it in the context of the page/content builder we're talking about here. Something like Hotwire (or Unpoly, or Vue if we go there) would simplify making it work slicker, without the reloads of the Repeater Matrix and with dynamic previews like in the YOOtheme example. So not the whole admin is the SPA, but just the edit page.

This is also really important to me - I don't always want the editors to have too much flexibility.

"Is there demand for that?" -- I would say this is a resounding yes. There are dozens of page builders out there, and many tied to WordPress: https://blog.hubspot.com/service/wordpress-page-builder Block Editor (Gutenberg) is more of an advanced version of TinyMCE/CKEditor, but it's quickly becoming more of a "page builder" in the next year or two.

Glad I am not the only - I was intrigued by what I read, but that video was confusing as hell. Either way, I have never been a fan of what the Basecamp guys do, so I would definitely be hesitant for that reason alone - maybe an unfair approach to judging Hotwire because I am sure they've learned a lot since they build Basecamp. This sounds a bit confusing to me. I feel like we either need a separate decimal fieldtype, or maybe a FieldtypeNumber that has options for all the numeric types that MySQL supports. Of course we also have a separate FieldtypeInteger, so maybe it will start to get confusing if they are all combined into one Numeric type now, although I think it might be the ideal option, although I haven't thought through all the possible issues with this yet.

No. That date has not yet been set :-).

Not sure where I want to take this... At least it will be a successor of https://processwire.com/talk/topic/18166-processwire-kickstart/; Maybe more... Anybody here still using wire shell and wants to share experiences/learnings? How were you using it? What was missing? What did you like most? etc

I see your point. However, it doesn't need to be an SPA. Webpack is a pain to configure, although there are various approachable alternatives out there.

Thank you for providing this great work, there's no doubt the forum is craving to install this module, me included. On the roadmap there is no mention of the proper release, you mention only soft and closed release for the selected few, am I right? Or the full release is going to be on Q2? I know dates are not fixed yet and I don't wont to be pushy, but demand for e-commerce is high now and we need to make decisions on which platform to use for our clients. Thanks!

Ha! Great minds! ??. I just beat you to it ?.

I agree that something like the YOOtheme Pro Builder would be the way to go. Maybe the next admin theme could be implemented form scratch, along with ProcessWire's frontend content builder, based on something like Alpine.js perhaps? See: https://www.youtube.com/watch?v=M3fY0E60cM0 Some sort of reactive JS library is surely needed for such a builder, especially if more that one person start working on its implementation. However, the issue is that locking the admin and the builder to the future of a JS framework is problematic, to say the least.

Thanks for the very insightful video @Jonathan Lahijani Flexible Content / Page Builders When it comes to this, if you look at what's out there, in many cases, you'll invariably end up in either of two places with respect to the technology behind the builders; Vue JS or React. A few examples: Statamic - Vue JS Gutenburg - React YOOtheme Pro's Builder - Vue JS Storyblok - Vue JS There is ?. It is called Vue JS (I prefer it over React). OK, there is no ready made tool solution but from my experience developing Padloper 2, I can say it is quite doable. If we are to build any sort of page/site builder, I'd highly suggest to look at either Vue or React - especially Vue. It will save you a lot of hassle. The biggest challenge I found with these frameworks if using the CLI versions (recommended) is that the 'app' has to be developed outside ProcessWire as they run on different ports. This means the app has to be 'built' in order to test it inside ProcessWire. This is a tedious process. I have never been able to develop a Vue app inside ProcessWire and still get the benefit of Hot Reloading. If we end up using Vue JS (or even React), then perhaps we need to pay a visit to our old friend jQuery (and its siblings - UI) to plan for their retirement? ?. It wouldn't make sense to have both. Even if we didn't end up with Vue, modern JavaScript has some great APIs that can replace the dependency on jQuery. I know this is a huge undertaking. I know both the modern and the old have their pros and cons. I also know that jQuery is not evil. I know the decision to use it or not can be subjective. I just prefer working with reactive frameworks (and vanilla JS). What do you guys think? @ryan, would modern JavaScript tools fit into this vision?

I think that would be really cool ? In my opinion, the page overview should be revised. The edit, move etc. buttons should always be displayed. Buttons should always be displayed. So you can call the function faster. Possibly a table view would be nicer here...

Unfortunately, PW only supports one dimension for arrays when using the API to process data. There's been some discussion on this topic at GitHub: https://github.com/processwire/processwire-issues/issues/387

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

It's true that this is not an easy topic. When it comes to the REST API shipped with WordPress... When it was initially added, we routinely disabled it from all the WP sites we maintained at the time. Mostly "just in case" and because initial versions (unless my memory fails me) had holes in them, but also because there was a very real chance of accidentally displaying content that wasn't actually intended as public. To my best knowledge it still doesn't ship with a very good native authentication solution. There's been some development in this regard and there are plugins for that, though — and again the API can be disabled if it's not needed. Even though it isn't without its issues (and even if it's not always particularly intuitive), it is now somewhat widely used, many plugins provide their own REST API extensions, and some plugins are even built on top of the API (though that might be at least in part due to WP's internal API not being all that great). The biggest benefits I see in a built-in API, even one that is disabled by default, would be that a) modules and other shared code can build on it since developers know that it'll be there and know how to operate it, and b) having a built-in API does sound better from a marketing perspective than "you can install it as a plugin/module". And it does give it some legitimacy too ? Anyway, definitely not an easy topic. If an API like this was to be added, I believe it should be disabled by default, there should be some sort of authentication mechanism built-in, and it would have to be very configurable regarding the data and operations that it would expose. Would also be interesting to benchmark what the "competition" is doing in this regard. @Jonathan Lahijani is definitely the one to talk about this, he's taken Repeater Matrix based content building to whole another level. Though I'd of course be more than happy to provide feedback and suggestions ? Oh, I can definitely agree with you here, design is always subjective. Personally I quite enjoy simplicity, but I also strongly dislike dropdowns — I'd much rather see all those top menus open (or collapsed and openable with a click) in the sidebar. It always feel it's a chore when I have to move a cursor over a specific item just to see what was under it... ? Interestingly the design of the admin was one of the first things our latest team member commented on when we were discussing the pros and cons of PW. I don't want to speak for her, but the gist was that perhaps PW would be a bit more "competitive" if the admin was easier for new users to grasp, and sidebar was something she specifically brought up. Again this is no doubt subjective, but I've heard similar comments more than once. It may be in part that folks are used to the admin in WP and comparing it to other systems they use, of course. Configurable sidebar would be a good compromise, something for everyone ? I agree with a lot of what you've said, and I very much appreciate your dedication to ProcessWire. That being said, the reason I commented on this was largely selfish: I've recently spent a lot of time and effort trying to convince folks both sides the figurative fence (devs and clients) of the fact that ProcessWire can indeed be trusted, and that the numbers they see (handful of devs here in Finland, small amounts of contributors in GitHub, etc.) are not all there is. The primary issue for me is not actually popularity. Personally I couldn't care less about that, but what I do care about is that recently the vast majority (at least half, but perhaps as much as two thirds) of potential clients have started with the demand that the project has to be built with a "popular" system (which usually really means WP). I can't speak for other markets, but here (and in the niche I'm in) it is already ridiculously difficult to convince buyers that the most popular option is not necessarily the best option. These buyers are often not especially technical and thus don't care that much about what goes on behind the scenes. What they do care is a) whether they can put their trust (and money) behind a less known platform, and b) whether they can be absolutely certain that there's always someone else to turn to if something goes wrong. Numbers work against PW in this regard, and while I'm well aware that challenging the role of the most popular CMS is not feasible (never say never...) an upwards trend would be a big plus ? When it comes to PR's, my suggestion would be to be as open as possible. I know that many of them are not "quite there", but perhaps you could provide some pointers, tell what's wrong and suggest some changes? It seems that many PR's are for minor things as well, typo fixes and such — I get that these don't really add a whole lot of value code wise, but the good thing about accepting them is that they do affect our numbers, and again that can be an important factor for getting new developers (and clients!) interested. (Some users may create certain types of "low value" PR's to get recognition for themselves, but personally I don't see much harm in that either. Mutual benefit and so on.) Anyway, just my five cents! I don't want to step on your toes here, just hoping that you can also see where I'm coming with this. I believe in ProcessWire, just trying to think of ways to convert non-believers (so to speak) ?

@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.

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.

Thank you @3fingers ! Your coffees will help me to stay motivated ☺️

Oh. One more. I get that this is literally something you said you're well aware of, but I'd still like to say that I would absolutely love to see more pull requests get pulled into the core this year ? This has been brought up many times over the years, but the truth is that "if ProcessWire is so good then why are only a handful of people interested in contributing" is still one of the FAQ's I ever so often find myself answering. At least in the market I am in appearances and popularity matter a great deal, for clients as well as developers. I want to be able to justify why I'm not using the most popular platform out there, and sadly it's getting harder and harder by year (and a rather low number of contributors isn't helping, at the very least).

@ryan Maybe also some Point to start: The Open Pull Requests: https://github.com/processwire/processwire/pulls

Hi @ryan - it's been a great year for the PW core - thanks for all your hard work as always and very glad to hear that pro module sales are doing so well for you! In addition to the requests repo that @Robin S mentioned, there is also of course the https://processwire.com/talk/forum/5-wishlist-roadmap/ thread. I actually think it would be best to start with the issues repo and once those are all fixed, then move onto those two requests lists. Lots of user input has gone into those lists and I'd hate to see that effort ignored or pushed aside in favor of new suggestions. I have lots of new suggestions / ideas, but I think they should wait so your efforts can focus on outstanding issues first - does that make sense?

@mke, there is a property and helper method in InputfieldFile that allows a maximum files size to be set but there is no config field for it in admin and you would need to set the max file size in a hook in /site/ready.php: $wire->addHookBefore('InputfieldFile::render', function(HookEvent $event) { /* @var InputfieldFile $inputfield */ $inputfield = $event->object; if($inputfield->hasField == 'YOUR_FIELD_NAME') { $inputfield->setMaxFilesize('2m'); // Set the max file size in bytes or use string like "30m", "2g" "500k" } }); Also, for some reason max file size settings of less than 2MB are not enforced - see here.