Leaderboard

Recurring dates / calendar module A big +1 from me for this. A lot of sites need this kind of functionality. The key thing is solid RRULE support in a user-friendly interface. It's really common to have events that occur on a regular schedule (e.g. the first Tuesday of the month for now until eternity) but then occasionally have exceptions where the event is moved to a different day or cancelled for a particular date. The Recurme module had the right general idea but if you take a look at the source code you can see why it's not really scalable and needs a lot of tidying. A robust calendar module is not a simple thing so it would be great to have something that's built to the standard of Ryan's other Pro modules. Flexible content I find that Repeater Matrix is fine for when the content is divided into discrete conceptual and visual blocks on the frontend. It's pretty easy to make the mental connection between "conceptual/visual block on the frontend" and "Repeater Matrix item in the backend". Where it's not so good is when you have a long piece of text that is interspersed with different pieces of other content, e.g. text - image - text - graph - text - pullquote - text. In this scenario the editor/author wants to think of the text as one conceptual unit. Breaking the text across multiple Repeater Matrix items feels wrong, and it's difficult to locate and move paragraphs between the different blocks. For this scenario (which is pretty common now - think of Medium articles or other longform articles containing rich content) the Statamic Bard fieldtype looks like it nails the solution pretty well. The user wants to see a single flow of text with elements floating inside the text that represent the other pieces of content. These floating elements should reveal the content they contain (or at least the type of content) so that the user can understand what is what, but perhaps be edited outside of the text editing interface where that is more practical, e.g. click an element to edit it in a modal. I have actually made a couple of different experimental modules that expand Repeater Matrix in this direction but haven't found a fully satisfactory solution yet. Admin theme I'm pretty happy with AdminThemeUikit and don't think it looks dated. I've said before that there's too much padding between and around elements and the main page heading is way too huge (maybe this is where the "cartoonish" criticism comes from), but these things are very simple to fix with custom CSS overrides. I wouldn't want to see the admin styling change every year and I can't relate to the desire to be endlessly changing the admin to keep up with the latest fads. The admin is a place you go to do work, not to see pretty things. It should be plain and utilitarian, which AdminThemeUikit already is. Having said that, a couple of ideas that would make it easier for those who want to tweak the admin: 1. Maybe there could be more config fields in AdminThemeUikit to let people adjust things like spacing and font size without having to add their own stylesheet to the admin. 2. It would be pretty good if developers could more easily create modules that extend AdminThemeUikit so if they want a customised admin theme they only have to override certain specific methods rather than completely duplicating the module. Right now if you do... class AdminThemeFoo extends AdminThemeUikit ...the admin experience completely breaks so it's not currently a good foundation to build on. And it would be good if there were more hookable methods in AdminThemeUikit so that it becomes possible to manipulate the main menus for instance.

You can use a hook to replace all relative time strings in admin with a specific date format. Add the following to /site/templates/admin.php, at the top after the namespace declaration: $wire->addHookBefore('WireDateTime::relativeTimeStr', function(HookEvent $event) { $timestamp = $event->arguments(0); // If given a date string, convert it to a timestamp if(!ctype_digit("$timestamp")) $timestamp = strtotime($timestamp); $event->replace = true; // Set your preferred date format below $event->return = date('Y-m-d H:i:s', $timestamp); });

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) ?

Below are the style overrides that I apply, mostly just spacing changes and fixes for things that looked off to me. There might be one or two things in there that don't make sense out of context because I'm also loading some custom JS to change the icon of the "user" menu and have the primary link be to the site frontend rather than the user profile. The problem is that if you create the minimal module that extends AdminThemeUikit (i.e. just the class declaration and the getModuleInfo method) then what you want to see is everything displaying as per AdminThemeUikit. Then you would add custom CSS/JS and override any AdminThemeUikit/AdminThemeFramework methods as needed. But what you actually see is this: If that is expected then it would be helpful to have some documentation or a blog post about how to go about extending AdminThemeUikit, or what file structure is needed for a full custom admin theme if anybody is game enough to try that. The only hookable methods that I can see are AdminThemeUikit:renderBreadcrumbs and AdminThemeFramework::getUserNavArray. So for the thing I mentioned (manipulating menus) you can only customise the "user" menu. It's not possible to dynamically add items to the Pages, Setup, Modules or Access menus without resorting to JS hacks like AdminOnSteroids does. And on the topic of the admin menus, the caching is a bit of a pain and doesn't measurably improve performance according to my tests: https://github.com/processwire/processwire-requests/issues/268#issuecomment-464200684 Another menu related request: https://github.com/processwire/processwire-requests/issues/189 What would be great is if for each major part of the admin theme layout (e.g. header, menus, top of content, bottom of content, footer) there was some hookable method so it was possible to inject custom markup at those points.

This is tricky because for the database "1,5m" is neither a word nor a number, so the comma is treated as a word boundary. This is why can't use selectors that make use of fulltext indexes (*=, ~=). The only option in this case is a slower LIKE comparison (%=), but that isn't aware of word boundaries, resulting in your problem with matching "11,5m" as well as "1,5m". A quick and dirty solution would be to include the space in your selector, but I'm not even sure if ProcessWire won't filter out any leading/trailing spaces in selector values: 'title%=" 1,5 m" The best solution is to turn the height of the tree into its own field which can be searched and compared properly. For the height, a simple integer field containing the height in centimeters would be appropriate. Then you can easily search for trees of a certain height, or even within a certain range of heights: // all trees that are exactly 1,5m high $trees = $pages->find('template=tree, height_cm=150'); // all trees that are between 1 and 2 meters high $trees => $pages->find('template=tree, height_cm>100, height_cm<200');

Assuming I understood the question...one way to do it: <?php namespace ProcessWire; // init empty string to store markup output $out = ""; $events = $pages->find('template=calendar-post, limit=5, Start_date|End_date>=today, sort=Start_date'); // we found events if($events->count()){ $out .="<h2>My Header for events</h2>"; // my events code! // start list - just an example $out .= "<ul>"; foreach($events as $single) { $out .= "<li>{$single->title}</li>"; } // close the list $out .= "</ul>"; } // use this if you need to show 'no events info' else { $out .= "<div>There are no events at the moment!</div>"; } echo $out; Please note, I haven't checked the validity of your selector.

Just one thing to consider - it may result in some weirdness when both actual and relative versions are shown together, eg:

Just released version 2.1.4 with an improved documentation. I moved most of the contents from README.md to the repository-wiki. Everything is better structured and more readable ?

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

If you have the core ProcessPageClone module installed you can copy a page via Page List: But sometimes I don't want to hunt around through Page List to find the page I want to copy, and instead I have found the page via the admin search and have it open in Page Edit. So I used this hook in /site/ready.php to add a "Clone this page" button to the bottom of the Settings tab. // Add a clone button to the Settings tab of Page Edit if this page is allowed to be cloned $wire->addHookAfter('ProcessPageEdit::buildFormSettings', function(HookEvent $event) { $wrapper = $event->return; $modules = $event->wire()->modules; $page = $event->process->getPage(); /** @var ProcessPageClone $ppc */ $ppc = $modules->get('ProcessPageClone'); if($page && $ppc->hasPermission($page)) { /** @var InputfieldButton $f */ $f = $modules->get('InputfieldButton'); $f->value = 'Clone this page'; $f->href = $event->wire()->config->urls->admin . 'page/clone/?id=' . $page->id; $wrapper->add($f); } }); Maybe somebody else has this need and finds this useful.

Depending on how much mixing of relative and absolute dates occur on a single page, it might be possible to avoid those scenarios by excluding specific processes and/or URL segments, e.g. if($page->process != 'ProcessPageEdit') { $wire->addHookBefore('WireDateTime::relativeTimeStr', function(HookEvent $event) { $timestamp = $event->arguments(0); // If given a date string, convert it to a timestamp if(!ctype_digit("$timestamp")) $timestamp = strtotime($timestamp); $event->replace = true; // Set your preferred date format below $event->return = date('Y-m-d H:i:s', $timestamp); }); }

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?

A dedicated field for height is definitely the way to go, but just wanted to add that for the example titles you gave, the height follows the noun and if that applied consistently then potentially you could include the noun in the search text:

Perfect, thank you Robin! And thanks for the bit to consider, adrian!

And if you want the height to appear after the title in the page tree, you can use the "List of fields to display in the admin Page List" setting on the Advanced tab of the template's settings. And if you want to go even further and convert cms to decimal meters, you can use a hook something like this: $this->wire()->addHookAfter('ProcessPageListRender::getPageLabel', function($event) { $p = $event->arguments[0]; if($p->template == 'tree') { $event->return = $p->title . ' ' . ($p->height_cm / 100) . " m"; } });

Happy to help :-). Glad you sorted it out.

Thank you very much I already had everything just not in the right place. All I had to do was to place <?php $events = $pages->find('template=calendar-post, limit=5, Start_date|End_date>=today, sort=Start_date'); ?> <?php if(count($events)): ?> above everything. Figured it out thanks to your example ? Thank you R

For this need you should be able to import data from an existing SQL table into a Profields Table pretty easily - either via CSV with the Table CSV Import/Export module, or even with SQL. The other option might be to build a custom fieldtype that utilizes something like http://tabulator.info/ to connect directly to your existing table and manage its content that way. Would that be useful for your needs?

This is really well explained! I sometimes end up with "Text w/ Image", "Text w/ graph", "Text with quote" block types which works and helps with getting the css styles around these blocks to work as expected, but it would definitely be nicer to have a way to make interspersed content cleaner. Agreed!

He had already built the site in PW (and had it running for over a year) and then rebuilt it as described - that's the reason I brought it up - it obviously wasn't clear enough that he could use PW effectively in the scenario he wanted. Maybe "hacky" isn't the right word - I do it a lot and have my systems down, but I thought perhaps it could be improved and be easier for those who want to do all frontend code in JS (which isn't me BTW). I appreciate all your comments around the security issues for this though and as always you have that as the highest priority, which is great - thank you! I guess it's mostly the ability to edit all the fields on a page, including those that require JS (like repeaters, image upload, etc) so that frontend users can edit their content (think complex user profile data etc). It's doable already, but it involves ensuring key JS files are included and some relatively complex API logic to get everything working correctly. A way to make this really simple could be very useful. Displaying event calendars - usually things like weekly farmer's markets, open mics etc I don't agree that it wouldn't make a difference - I know my needs are more complex than some users, but I've seen enough likes / replies to many of my GH issues to know that these things are affecting others as well. I think lots of users would like to be able to expand/collapse all items at once, but they don't know they can because the UI for it is so hidden ? I don't think it's an age issue - unfortunately I think it's always never quite felt right - in some ways I actually prefer the tightness of the default theme but it's look is definitely too dated. Thanks for taking the time to think through all my suggestions and minor gripes ?

@ryan I can collaborate with you on improving Repeater Matrix and giving you a really deep understanding of page builders, issues that would be faced and my thoughts on a direction ProcessWire can take. I've built a module internally that demonstrates a lot of these concepts.

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.

Regarding @teppo's suggestion about a native external API - I know that we just lost one PW website to a JSON / GraphQL / Gatsby / React stack because the developer decided that was easier to do that than use GraphQL / Gatsby / React on top of PW. Personally I think his decision was misguided because now he is managing content in json files (he is the sole dev / content editor so he doesn't need an admin CMS), but I think he'd have done much better using PW for content management and generating JSON that can be pulled into the frontend. But maybe if PW had a native way of doing this, he might have stuck around and I am sure there are lots of other devs out there that ignore PW simple because they don't think it will let them use these modern frontend stacks. I do think an integrated javascript API would make lots of things much easier as it always feels a bit hacky to me getting PW data into JS - it would be great to have JS page object available on page load, but also to have a built in AJAX method to pull other PW data on demand. I do feel like we need to convince potential developers that PHP can work together with the rest of the tools they want to use - they don't need to use Node to integrate things. I am still baffled that companies are paying thousands of dollars a month for things like Contentful or ContentStack when PW can essentially do the same thing - I know there are other benefits to these services, but I find the downsides not worth the tradeoff. There are of course self-hosted headless CMSes out there, like https://strapi.io/ which has been around since the end of 2015 and has 32,000 Github stars and 600 contributors. I know you have constantly maintained that you don't care about popularity, but clients often do, and with good reason - they need to know that there are other developers out there to take over if needed. The other big thing for me is finding ways to make certain data queries more performant, perhaps with something like @bernhard's Rockfinder functionality built into the core so that we can pull large amounts of field data in a more performant way - we don't always need all the info contained in the PW objects that are returned by regular API queries. Honestly I haven't yet used Rockfinder in production - I've actually gone with custom SQL queries of PW field data to build up objects/arrays exactly as I need them, but some inbuilt methods for automating this (like Rockfinder does so well) would be nice. One thing I would like to see is a way to easily implement certain admin forms in the frontend - yes we can do this with the API, but having all the admin tools available in the frontend would have saved me a lot of time over the years essentially rebuilding functionality. Sometimes I can get away with the AdminBar module, but it's not always appropriate. If you want an idea for another profield, a properly working version of a recurring dates field would be awesome. Unfortunately the Recurme module just isn't a viable option - I do have it running in production, but it's not efficient and I have several hacky fixes in place. It's actually a difficult problem doing recurring dates well, but it is a common need for lots of sites and so a good implementation would be very popular. However, my biggest concern and bugbear has always been what some might consider little things, but these "little things" can sometimes cause lots of frustration - things like: https://github.com/processwire/processwire-issues/issues/550 - there are lots of other examples of these sorts of things that require hacky workarounds. It is much more important to me to find proper solutions for these than adding fancy new features. I'd also like to see the admin user interface tightened up - there are lots of areas for improvement and so this is just one silly example, but having the double-click to open/close all repeater items on the on/off toggle button is confusing and I think needs fixing. I have converted a local web dev agency to be exclusively PW (from Drupal), but whenever we chat, their main complaint is always the look of the admin - they feel it doesn't look modern and clean enough and makes PW look a bit cartoonish. Please don't take that as a personal insult - getting this right is difficult and in my mind take a very talented design person to get the details right - I can see the things that are jarring, but I am not good at figuring out how to make them right. I think this is really important in ensuring that PW continues to be something that we can convince clients is a modern platform. I do also think that the interface to RepeaterMatrix could be modernized. I am not a huge fan of fancy website builders, but I do think we need to find a middle ground between what RepeaterMatrix currently provides and the best of the new building tools out there, because eventually clients will complain that they don't have access to the shiny new tools - it hasn't happened to me yet, but I think that's partly because of the type of clients I typically have.

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

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?

Thanks @Robin S - should be fixed in the latest version.

Hi Adrian, I spotted a minor layout bug with the new editor links in the Dumps panel:

@LAPS form-builder.inc: /** * * Add custom scripts to the form. * */ $forms->addHookBefore('FormBuilder::render', function($event) { $form = $event->arguments(0); $config = wire('config'); switch ($form->name) { case 'name-of-form': $config->scripts->add($config->urls->templates . "libraries/chosen/name-of-js.js"); $config->styles->add($config->urls->templates . "libraries/chosen/name-of-css.css"); $config->scripts->add($config->urls->templates . "FormBuilder/custom-js-init-file.js"); break; // other forms can be added below... } }); in your init file: $("#Inputfield_name_of_input").chosen({ no_results_text: "The planet exists not", allow_single_deselect: true, width: '100%' });