PW 3.0.170 – Core updates

[ryan]

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/

[Robin S]

Quote

It’s been a year or so now that ProcessWire has been at a point where it does everything I ever wanted it to, and it’s got everything it was originally set out to do, and it's got the nicest and most skilled community in the world.

Hear, hear! ?

2 hours ago, ryan said:

In this post, there’s also a question for you: what would you like to see in ProcessWire in 2021?

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

[adrian]

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?

 

[Kiwi Chris]

46 minutes ago, Robin S said:

Hear, hear! ?

One place to find ready answers to this question is the requests repo: https://github.com/processwire/processwire-requests/issues

There's also the wishlist and roadmap on the forums here.

https://processwire.com/talk/forum/5-wishlist-roadmap/

@ryan from your perspective do you have a preference where people post feature requests, and is there a reason to use the forum vs github and vice versa?

46 minutes ago, Robin S said:

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

Interesting feature request. I could have used that recently, although in most cases the images I wanted to use were the only ones on the page they belonged to, so I just used a normal page reference and used the image from the page. For pages with more than one image though, it wouldn't work if I wanted to pick a single image.
Now that images support additional fields via a template, then I assume behind the scenes there is a page holding this data, so it should be possible use selectors like with regular pages on these fields to find images that match regardless of what page they belong to? That could apply not only for an images reference field, but also for the RTE when inserting images, to provide an image search functionality, like currently is possible when inserting links.

[adrian]

10 minutes ago, Kiwi Chris said:

Now that images support additional fields via a template, then I assume behind the scenes there is a page holding this data

They are custom fields (columns) added to the field_images database table.

@Robin S - have you seen this module: 

Is this mostly what you are looking for?

[markus_blue_tomato]

 

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

[Ivan Gretsky]

Happy new year and best wishes to you @ryan, and everybody here in PW community!

Thanks for asking about user opinion on the features for the roadmap! There is a rather old poll on weekly.pw on the same topic. Some features from that poll are already implemented, and it is really cool! But some are still waiting to find their way into reality.

My personal favorite is:

• Strategy for flexible content types in a template (https://processwire.com/talk/topic/7477-strategy-for-flexible-content-types-in-a-template/) (7.3%, 10)

Additional wish from my side is the ability to build custom admins for non-superusers. One way I once tried to imagine it is this. There are a number of related features in the mentioned poll as well.

[Robin S]

On 1/2/2021 at 2:34 PM, adrian said:

have you seen this module: 

Is this mostly what you are looking for?

Thanks, I did notice this when it was released and it looks like a nice module. It's only for single images though, and I'd still like to see image and file reference fieldtypes in the core. For some situations such fieldtypes are needed (e.g. avoiding duplication of images/files and associated data/descriptions when the asset is used on multiple pages, roles that may select files/images but not upload new files/images, scenarios where images/files need to be centrally managed, etc) and the fact that the core doesn't cater to this feels to me like a gap that should be filled.

[ryan]

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. 

Quote

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

Quote

from your perspective do you have a preference where people post feature requests, and is there a reason to use the forum vs github and vice versa?

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. 

Quote

My personal favorite is: Strategy for flexible content types in a template (https://processwire.com/talk/topic/7477-strategy-for-flexible-content-types-in-a-template/) (7.3%, 10)

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?

Quote

Additional wish from my side is the ability to build custom admins for non-superusers. 

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?

 

[teppo]

4 hours ago, ryan said:

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.

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

[teppo]

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

[adrian]

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.

 

[ryan]

Quote

Off the top of my head 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"

Yes the flexible content one seems to be a recurring theme, so I’m interested in that. 

Quote

…and "headless" (as in native, external APIs). 

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. 

Quote

…Modules such as AppApi and Process GraphQL 

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. 

Quote

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. We've been using RepeaterMatrix for this and for the most part it works, but I do have to admit that it doesn't feel as slick as some of the competition. Both Kirby and Bolt have some interesting ideas in this regard, and Gutenberg is starting to look very interesting as well.

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?

Quote

I really miss a sidebar. A proper one, one that stays in place, like the Reno theme had. I know I may sound like a huge WordPress fanboy, but this is something they got right early on, and based on user feedback I'm not alone.

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. 

Quote

Now, having said all that: I know this is nothing "unique" or "groundbreaking".

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.

Quote

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 in to the core this year

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. 

Quote

At least in the market I am in appearances and popularity matter a great deal, for clients as well as developers. 

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. 

Quote

I want to be able to justify why I'm not using the most popular platform out there, and sadly it's been getting harder and harder by year.

PW’s track record speaks for itself. 

WP’s track record speaks for itself. 

 

[Zeka]

Happy New Year all and thanks @ryan for all of your work.

There are already so many ideas and requests, but here is what my current clients asks:

• Central media/image manager for reusing images across pages 
• Support for different file storages for image like Flysystem

 

[Jonathan Lahijani]

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

[ryan]

Quote

 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)

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. 

Quote

 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. 

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.

Quote

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.

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. 

Quote

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.

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?

Quote

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.

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?

Quote

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

Quote

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

[ryan]

Quote

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.

Awesome! Thanks @Jonathan Lahijani that would be great. 

[ryan]

@Zeka

Quote

Central media/image manager for reusing images across pages 

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. 

Quote

Support for different file storages for image

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. 

[adrian]

1 minute ago, ryan said:

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. 

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.

4 minutes ago, ryan said:

There's nothing hacky about getting PW data into JS. It's very simple.

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!

7 minutes ago, ryan said:

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?

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.

10 minutes ago, ryan said:

What do you use a recurring date for on the front-end?

Displaying event calendars - usually things like weekly farmer's markets, open mics etc

12 minutes ago, ryan said:

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

19 minutes ago, ryan said:

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.

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 ?

20 minutes ago, ryan said:

maybe the AdminThemeUikit is starting to feel old since it's been around for a few years now

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 ?

[Robin S]

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.

[adrian]

2 minutes ago, Robin S said:

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.

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.

5 minutes ago, Robin S said:

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)

Agreed!

[teppo]

2 hours ago, ryan said:

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. 

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.

2 hours ago, ryan said:

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?

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

2 hours ago, ryan said:

This is subjective of course. I’m the opposite, a sidebar drives me nuts. 

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 ?

2 hours ago, ryan said:

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. 

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

[teppo]

2 hours ago, Zeka said:

There are already so many ideas and requests, but here is what my current clients asks:

• Central media/image manager for reusing images across pages 

1 hour ago, ryan said:

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. 

This has been a relatively common request for me as well. In fact a variant of the media library concept is on my todo list for tomorrow... ?‍♂️?

I've found that this becomes more important when a site has more content and more content editors: sometimes it's about not having to maintain a separate media library (in a traditional media library, somewhat like the one found from WP, they would just upload the materials once and then reuse them everywhere with ease), and other times it's about knowing where each material has been used / being able to update it in a central place if it needs to change.

In many (most) cases what we already have is more than enough, but regardless, I do run into this type of request every now and then.

[adrian]

4 minutes ago, teppo said:

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?

I actually like the way that @dg from Nette handles this - he uses the "adrianbj authored and dg committed" approach which I highlighted once before - this allows the committer to make changes to the commit, while still having the author recognized as the contributor.

[teppo]

9 hours ago, adrian said:

I actually like the way that @dg from Nette handles this - he uses the "adrianbj authored and dg committed" approach which I highlighted once before - this allows the committer to make changes to the commit, while still having the author recognized as the contributor.

Definitely one way to do it. My suggestion was largely based on the experience of working with code review in a previous job: CR is as much about education (nurturing a more productive team of contributors) as it is about making sure that the quality is solid.

Obviously these approaches are not mutually exclusive ?