Weekly update – 11 July 2024

[ryan]

Fridays are always the days when I'm full-time on ProcessWire. Other days I may be doing client work, or ProcessWire, just depending on the week. This week it's been mostly client work. And I just learned that I'll have to be out of the office tomorrow (Friday) for a family commitment. So I'm writing this weekly update today instead, and just sent out Teppo's great ProcessWire Weekly newsletter with ProMailer today (usually it gets sent Friday). 

Because of this change in schedule, I don't have much new to report just yet. Instead, I wanted to start talking a little about future plans, so here's a few ideas. I think we should get another main/master version out, perhaps by September. Following that, I thought we should focus on ProcessWire 3.1, or maybe it's time for version 4. 

What would be in this next major version of PW? For starters, we'll finally drop support for older PHP versions and start taking advantage of all that's been added new newer PHP versions (8+). This will involve lots of updates to the ProcessWire core code base, while remaining 100% API compatible with PW 3.x. I thought that would be a good starting point into our next major version at least. In addition, we'll likely be trimming some things out of the core and into separate non-core modules, such as FileCompiler, CKEditor, the two legacy admin themes, and a few rarely used Textformatter modules. Most likely we'll also have an overhaul of this website and some nice improvements to our primary (Uikit) admin theme to accompany the next major version as well. There will be plenty more too, but this is what I've been thinking about so far. Your feedback is welcome. Thanks for reading and have a great weekend! 
 

[7Studio]

I would love to see some kind of a bare bones of e-commerce features in the core, that could help to build a basic small shop directly in PW, without the need of integrating with third party e-commerce systems like Shopify etc. Just thinking out loud ? Have a great weekend!

[David Karich]

I think the most talked about feature is an asset manager. The drilling down of file and imagefields so that you can choose assets from a global library that have already been uploaded somewhere, instead of having to upload assets multiple times. Actually, the approach using references is the best I've come across so far. The data remains where it was originally uploaded, but is only referenced in a file/image field on another page.

[Jonathan Lahijani]

Making ProcessWire stronger for full-stack web application development, allowing it to become an unassuming alternative to Laravel and Rails but from the origins as a CMS.  ProcessWire is the perfect CMS (there's no doubt in my mind about that), and it's actually already quite good for web application development (both natively and with 3rd party modules), but with some enhancements to make it more "batteries included", enhancing page classes and some tooling, ProcessWire can have its feet in both the CMS and full-stack framework buckets in a way that's perhaps unique.

I can elaborate on this further as that sounds a little too generic, but I've been developing a web application with PW for over 9 months (it's a very complicated project and it's replacing an existing, in-production system which makes it even more tricky and high-stakes) and when it's done I can share some ideas.  This one enhancement alone moved the needle quite a bit in making ProcessWire more web application friendly.

[Ivan Gretsky]

Thanks for this topic @ryan! Great to have a chance to look into the future and maybe even influence it a bit.

I agree with @Jonathan Lahijani, but we surely need to expand on that. I can understand his point quite well. ProcessWire taught me be a (somewhat) ambitious developer, that is ready for bigger projects. And some of those grew big enough I started seeing the limitations of PW. And though I think that PW might be not the best choice for some projects (bigger web apps, as Ryan himself pointed out before), it can have its sweet spot in between regular CMS and web frameworks like Laravel. I will try to point some of the ways I see to improve PW to move further into that sweet spot.

For now I can throw in this one:

• A better way to build custom user admin area. Reusing existing admin сomponents, but without the need to hide lots of stuff with permissions and hooks. So we could build something like /user-admin with limited functionality, but still using page edit module.

[szabesz]

I'd love to see an "officially supported and recommended (and even documented) way" of initializing custom page class objects, discussed and requested by us over the years:

• https://github.com/processwire/processwire-requests/issues/456
• https://processwire.com/talk/topic/30138-page-classes-diving-into-one-of-processwires-best-features/?do=findComment&comment=242737
• https://processwire.com/talk/topic/25342-custom-classes-for-page-objects-the-discussion/

[Robin S]

21 hours ago, Ivan Gretsky said:

A better way to build custom user admin area.

I'd like to second this. It would be great if the new/improved admin theme was built with maximum customisability in mind. One use case is so that we can more easily offer a "mostly-frontend" user an admin experience that's radically different to what a superuser or site administrator gets in the uncustomised admin.

Another admin customisation issue I've struck recently is when you want to customise markup for InputfieldWrapper. There's InputfieldWrapper::setMarkup() but this is marked as internal and isn't that practical to use because InputfieldWrapper::markup is static. That means any custom markup you set there persists for all InputfieldWrappers that are subsequently rendered, when what I want to do is customise markup for a specific instance of InputfieldWrapper. Edit: pull request

When the admin theme is revisited it would be great to ask of each component that's rendered, "Is there an opportunity to make this rendering customisable?"

Edited July 13 by Robin S
Added link to pull request

[szabesz]

On 7/12/2024 at 8:41 AM, Ivan Gretsky said:

A better way to build custom user admin area.

https://hamy.xyz/labs/2024-01_htmx-vs-alpine

Quote: "Low-js tools like HTMX and AlpineJS are the future of the web. They allow us to build modern web apps without the bloat of popular SPA frameworks."

What perplexity.ai says: https://www.perplexity.ai/search/explain-the-pros-and-cons-of-l-IrCeVWXSTAWsWJEv_GuNIA

Let's think forward...

[MrSnoozles]

Excited to see thoughts about starting work on ProcessWire 4. PHP 8+ bring so many improvements, would be nice to utilize them. My personal pain points and wishlist for ProcessWire:

- a global media manager
- more official integration of multi site / multi domain capabilities (in my case especially for the one database, multiple roots option)
- admin theme improvements: 
    - a permanently visible page tree to quickly jump between pages
    - more ways to customize it, depending on the applications needs. Like having a predefined place to add a "website select" for multi domain websites.
    - quick mockup, based on www.clickup.com. Clickup also has a "task bar" where you can put pages that you want to come back to. That's quite handy as well.
   

- from a tech point, some things that could be nice to have, but most likely not feasible and against the philosophy of ProcessWire because it would most likely make the project more bloated:
    - better utilization of composer, e.g. having the ProcessWire core and admin package as separate composer packages, so a ProcessWire installation would just have a "site" and a "vendor" directory
    - PSR standards / framework ineropability where it makes sense
    - some automated tests, at least for the core api

Quote

Making ProcessWire stronger for full-stack web application development

@Jonathan Lahijani+1. We're using it for application development and it works very well if there is not too much data involved (with 10,000,000+ pages you'll start to having to search for workarounds to keep things fast, in my experience). Would be nice to hear what would be your ideas for improvement. A more web-application like and customizable backend would be nice for us as well. In some projects we were able to hack and hide everything that was not needed. In other projects we build a custom admin panel. Then a way to render a form for a full template in the frontend would have come in handy several times already.
    

 

Edited July 14 by MrSnoozles

[MarkE]

7 hours ago, Robin S said:

I'd like to second this. It would be great if the new/improved admin theme was built with maximum customisability in mind. One use case is so that we can more easily offer a "mostly-frontend" user an admin experience that's radically different to what a superuser or site administrator gets in the uncustomised admin.

Hmm. I have a lot of sympathy with this, having created a number of quite complex apps, but wonder whether it can be done while maintaining what currently makes ProcessWire so distinctive. Would it lead to a more direct comparison with competitor “full frameworks” and possible future compromises?

I have managed to accomplish quite a bit of @Robin S’s objectives using process modules and my AdminInModal module. A more core way of doing it would be nice, however. 

[bvfbarten]

Something that would be nice is an easier way to handle multisites.  Something that could be useful is a sort of namespacing for databases.  The default namespace would be just like normal allowing backwards compatability.  However something like

// Render your multisite’s primary navigation
pages()->namespace('website2')->get('/')->children->each('<li><a href={url}>{title}</a>');

would be huge.  This would allow easy access to the primary database for configurations or anything needed there as well as possibly allowing to set permissions for users to just access to their namespaced database.

The namespacing I'd think could happen one of two ways, one would be table prefixing, the other would be creating a whole new database.

Another advantage of creating a whole new database would be that it would allow us to create a processwire instance in one database, but also have completely custom data in another database that is easily accessed would be nice.

Another thing that is on my wishlist for processwire 4.0 would be sqlite.  For me, processwire is a beautiful CMS / CMF because as a developer, if I can adjust my projects around processwire, it becomes a low code tool, great for prototyping.  Sqlite would allow me to bring up a processwire instance, create to my hearts content. Then just push this whole new project live.  I would think that this would require an additional $db abstraction.  It would definitely be harder to make this backwards compatible.  Maybe making this some sort of opt in with disclaimers everywhere saying that this breaks backward compatability with 3.0.

[MarkE]

46 minutes ago, bvfbarten said:

Something that would be nice is an easier way to handle multisites

Absolutely. I have one app where I have separaate sites for the public website and the admin website. I did it this way because the confusion of templates and fields would be too great otherwise, but the two sites need to interact (booking availability for holiday lettings). However I encountered a number of problems as a consequence and a neater way of doing it would be great, as well as fitting in with the suggested move to a more (or even more) 'app-capable' approach.

[HMCB]

On 7/11/2024 at 8:20 PM, Jonathan Lahijani said:

This one enhancement alone moved the needle quite a bit in making ProcessWire more web application friendly.

Wasn’t that linked enhancement already addressed?

[Pete]

It doesn't come up all the time for me (depends on the site) but often enough that I agree with others that re-using images on other pages is important.

I rarely insert them into the editor - that's my problem. How could we have an image from a different page's single/multi-image field be used in another page's single/multi image field because that's how I would need to use that feature?

Maybe next to the upload button have another button to select existing from another page (or media manager - I like that idea) and it's inserted into that field as a reference and can have it's own description, tags etc.

Likely others have already talked about this a lot over the years whereas I've just ignored it and duplicated my images quite a few times ?

I think though that this is where storing images in folders by page ID would maybe need to be replaced with something else to uncouple them from page IDs on disk, like maybe files/field id/ instead though granted that would be complicated for an existing site with thousands of images already on it. They'd also need to be grouped under the field ID as on a travel website /files/photos (as an example) could have 10k files or a lot more with variations under it easily. Not sure that's actually a problem though - feels like it might have been 10 years ago but maybe it's not now. If you wanted though you could have a subfolder per image ID for that field to store it and all variations neatly which somewhat alleviates the issue.

[bernhard]

23 hours ago, MrSnoozles said:

- proper autoloading, especially for writing more complex modules. Having to manually `require_once` files or adding a custom autoloader everytime feels dated

Anything wrong with this?

wire()->classLoader->addNamespace("MyModuleNamespace", __DIR__ . "/classes");

This will add an autoloader for all files in folder __DIR__ . '/classes' where all these files need to have the namespace "MyModuleNamespace". See https://github.com/baumrock/RockAdminTweaks/blob/a8b82fff339ecf403966d806db398d20286219cd/RockAdminTweaks.module.php#L28 for an example.

As far as I know require_once is problematic in multi instance usage, because you have different paths for the same class and that causes "fatal error: cannot redeclare class XYZ ..."

[monollonom]

My unsolicited opinion regarding a media manager: what I like about images / files being tied to a specific page is that it avoids creating clutter since the files are deleted when they're not needed anymore (the page is deleted) whereas if it was in a media manager you would probably end up with a lot of garbage. But I second the idea of maybe having something like @Robin S’ https://processwire.com/modules/process-media-lister/ to select an image from another page that would then be automatically duplicated on save.

[bernhard]

Before I find time to add my very own wishlist let's not forget the PW requests repository

[nurkka]

My suggestion would be to add a native global media manager and native multidomain support

Media Manager:
- Global management of images (also SVG) and Documents (e.g. PDFs) with a decent UI, Preview-Thumbnails, the possibility to organize the assets in folders, etc.
- A field to reference those assets, with a usable UI and the possibility to define starting folders, e.g. having a field which only allows to select from a folder with employee portraits, etc.
- References should be managed automatically, so one can't delete an image which is still referenced anywhere
- If an image is not referenced anywhere anymore, there should be a dialog which asks, if one wants to delete the asset OR there could be a cleanup feature to find and delete unused media items
- and so much more ideas, but the global management and the reference field with visual image preview in a clear UI would be great

Multidomain Support:
- Manage multiple Websites with different domains within one ProcessWire installation, with optional multilanguage support
- Every website has a root parent page in the page tree, where everything is defined: domain name, language, etc.
- Internal links will be managed by ProcessWire, so you can link between the domains. ProcessWire would determine if the links have to be prefixed with the domain name automatically
- The root parent pages will be fully abstracted away, e.g. their page names won't be applied to urls

I think that we really would need a native implementation of those features. Unfortunately, I don't have the time or expertise to develop them myself and make a PR, but I would like to add them to the wish list. And if they would be implemented, I would be happy to contribute ideas, feedback and provide beta testing.

[BrendonKoz]

This is likely more of a pro module type of thing, but I feel one area that ProcessWire is lacking from other comparable offerings out there is a site theme that is extendable and customizable from the admin backend. Tying a site-profile to the architecture of the site makes sense due to how PW is built, but being unable to switch a theme (even if temporary, to preview what the same content on a site might look like under a different skin), stylistically, after a site-profile is chosen is a little lacking. Even as a developer I like the ability to change things up now and then, but we don't really have a built-in way (that I'm aware of) a way to alter the frontend CSS via the backend using a known definition of basic templating to create themes. We can create one-off site-profiles, but not reusable themes.

Maybe @bernhard is getting there with RockFrontend(?) as a third-party offering, but it would be nice to see some way that this could be supported from a (potentially optional) core (or pro) module.

Similarly, I think it may be a good idea to start seriously considering alternatives to our richtext editor. I don't mean actually switching, I literally just mean considering. We switched back to TinyMCE because the newest version of CKEditor was no longer handling data in a similar way and it wouldn't be backward compatible, but TinyMCE is still handling data in the same way, but then after we switched, the company that now owns TinyMCE enacted a new licensing scheme. Although they're allowing an opensource license for now, that may not be the case, longer-term. Having a core proof-of-concept alternative (however the data is structured) would be lovely. No one wants to be caught off-guard! ?

3.1 or 4.0:
If only updating the core to support PHP 8+ capabilities, a 3.1 nomenclature sounds good. If in the process of doing that there were additional and significant enough updates applied, maybe a 3.5. If attacking even more functionality, then a 4.0 seems reasonable. ?

[FireWire]

Would be great to see .env support. I think this base change would level up ProcessWire and make it an increasingly viable application framework that fits into modern workflows.

On 7/12/2024 at 7:51 PM, Robin S said:

When the admin theme is revisited it would be great to ask of each component that's rendered, "Is there an opportunity to make this rendering customisable?"

I think this would be a great idea. It would greatly help module development where modifying or appending behavior to existing elements is needed. I could see that having been useful when developing my Fluency module.

I'll throw a thought in about multi-site capability after considering multi-tenancy for a Laravel project using a module. May be a nice feature but if there's a tradeoff for future features and development speed due to maintenance overhead, both for ProcessWire core and modules, it may not pencil out. I know it's not apples to apples, but creating two sites and a private API between them has worked for me in the past.

[psy]

No question, ProcessWire is fabulous for developers and the suggestions above would make it even better.

Customers who are not developers are increasingly giving me feedback about how unintuitive the backend admin/editor is, especially now with the proliferation of DIY pagebuilders. Clients don't understand or care about the consequences. They care about not having to learn code to easily update their sites. They want the backend to look similar to the frontend, the convenience of doing it themselves without having to pay a developer. Too bad if the site doesn't work on all screen sizes, light/dark modes, isn't accessible, the home page looks like a ransom note, whatever. They genuinely don't like the default PW admin UI/UX.

Pagegrid and RockPageBuilder modules are leading the way to solve this issue. Kudos to both developers BUT the modules are premium while a WP site gives customers basic WYSIWG page editing out of the box.

My vote is to overhaul the admin UI/UX to make editing pages more WYSIWIG. 

[Kiwi Chris]

Something that I might find useful would be database abstraction so that it's possible to use more than one database engine. mySQL/MariaDB works fine in the majority of cases, but there are times where licensing or functionality means that an alternative database engine would be preferable. The two that I have an interest in are PostgreSQL and Microsoft SQL Server with each of these having scenarios where I find them a better fit than mySQL/MariaDB.

Although not something that would result in a new version, improved documentation is another big one. Lots of great features have been added to ProcessWire over the years, but some of them lurk here in forum posts, or PW Weekly, rather than having everything in the main documentation site. Same applies for ProFields. It would be nice to have all documentation in one place.

 

[Kiwi Chris]

On 7/17/2024 at 2:19 AM, BrendonKoz said:

This is likely more of a pro module type of thing, but I feel one area that ProcessWire is lacking from other comparable offerings out there is a site theme that is extendable and customizable from the admin backend. Tying a site-profile to the architecture of the site makes sense due to how PW is built, but being unable to switch a theme (even if temporary, to preview what the same content on a site might look like under a different skin), stylistically, after a site-profile is chosen is a little lacking. Even as a developer I like the ability to change things up now and then, but we don't really have a built-in way (that I'm aware of) a way to alter the frontend CSS via the backend using a known definition of basic templating to create themes. We can create one-off site-profiles, but not reusable themes.

I think this might not be too hard to implement. Currently there's just \site\templates, but if there were something like site\[theme]\templates, then it would be possible to have multiple versions of templates. This could be potentially useful during development to test out a new theme while retaining the existing one, and if it were linked to roles so it's possible to specify what theme a given role uses, it would make it easy to provide completely different looks for different users. It could allow A/B testing with users to determine design preferences.

This would also be useful in a multisite scenario if different sites use common backend templates, but use a different theme to present on the frontend.

[Pete]

On 7/16/2024 at 3:19 PM, BrendonKoz said:

This is likely more of a pro module type of thing, but I feel one area that ProcessWire is lacking from other comparable offerings out there is a site theme that is extendable and customizable from the admin backend. Tying a site-profile to the architecture of the site makes sense due to how PW is built, but being unable to switch a theme (even if temporary, to preview what the same content on a site might look like under a different skin), stylistically, after a site-profile is chosen is a little lacking. Even as a developer I like the ability to change things up now and then, but we don't really have a built-in way (that I'm aware of) a way to alter the frontend CSS via the backend using a known definition of basic templating to create themes. We can create one-off site-profiles, but not reusable themes.

Maybe @bernhard is getting there with RockFrontend(?) as a third-party offering, but it would be nice to see some way that this could be supported from a (potentially optional) core (or pro) module.

Similarly, I think it may be a good idea to start seriously considering alternatives to our richtext editor. I don't mean actually switching, I literally just mean considering. We switched back to TinyMCE because the newest version of CKEditor was no longer handling data in a similar way and it wouldn't be backward compatible, but TinyMCE is still handling data in the same way, but then after we switched, the company that now owns TinyMCE enacted a new licensing scheme. Although they're allowing an opensource license for now, that may not be the case, longer-term. Having a core proof-of-concept alternative (however the data is structured) would be lovely. No one wants to be caught off-guard! ?

3.1 or 4.0:
If only updating the core to support PHP 8+ capabilities, a 3.1 nomenclature sounds good. If in the process of doing that there were additional and significant enough updates applied, maybe a 3.5. If attacking even more functionality, then a 4.0 seems reasonable. ?

 

On 7/18/2024 at 12:38 PM, Kiwi Chris said:

I think this might not be too hard to implement. Currently there's just \site\templates, but if there were something like site\[theme]\templates, then it would be possible to have multiple versions of templates. This could be potentially useful during development to test out a new theme while retaining the existing one, and if it were linked to roles so it's possible to specify what theme a given role uses, it would make it easy to provide completely different looks for different users. It could allow A/B testing with users to determine design preferences.

This would also be useful in a multisite scenario if different sites use common backend templates, but use a different theme to present on the frontend.

So I had to do this one recently - develop a new theme on a busy site so the staff could test it out with their live data and the solution was to add this into site/init.php:

if ($user->isLoggedIn() && $user->new_site_toggle == 1) {
  $config->urls->templates = "/site/tailwind/";
  $config->paths->fieldTemplates = dirname(__DIR__) . "/site/tailwind/fields/";
  $config->paths->templates = dirname(__DIR__) . $config->urls->tailwind;
  $modules->AdminThemeUikit->logoURL = 'site/tailwind/images/logo-white.svg';
  $config->AdminThemeUikit = [
      'style' => '',
      'recompile' => false,
      'compress' => true,
      'customCssFile' => '/site/assets/admin.css', 
	  'customLessFiles' => ['/site/tailwind/styles/admin.less'],
  ];
}

You might not need all that code but basically there was a checkbox field for certain users called "new_site_toggle" where they could login and toggle the new templates on and off and the template files just lived in /site/tailwind/ . "fieldTemplates" is for RepeaterMatrix template files in case anyone is wondering about that one.

The Admin Theme config stuff at the end of my code above was just because I like to customise the colours etc in the admin theme, plus in this case it helped reinforce which version they were currently about to view on the frontend. I think I also added a toggle button and some jQuery to the frontend to make toggling whilst viewing the site a one-click process.

Honestly the only problem with this approach was the new theme having different fields for some templates so old stuff had to live alongside new stuff, but as content was being updated all the time and I didn't really have time to do it any other way. In hindsight using some of Bernhard's modules would have helped as I ended up doing far too much dev on the live site instead of syncing changes ?

[ryan]

Thank you for all of the feedback! 

• Definitely want to build more e-commerce, but just not in the core. 
• I'm intrigued by what Jonathan mentioned and want to learn more. I suspect it influence the roadmap quite a bit. 
• Would enjoy building an asset manager but since my clients don't need it, I could only build it by self funding it. I don't have the ability to self fund it yet. 
• Agree PW should continue to grow on the framework side in the next major version. I don't know in what ways specifically just yet (feedback welcome), but am stating my agreement. I think we've been on a good path in this regard so far and should keep going / go further. 
• Don't agree that Page objects need more initialization methods, but let's duke it out. ?
• Agree we could use a new site profile, preferably a professionally designed one. 
• Agree we'll definitely continue improving the admin theme and maybe even add another.
• Prefer to avoid features that blur the line between content and style or front-end and admin, though there can always be exceptions. 
• The requests for Inputfield/InputfieldWrapper sounded good. 
• Supporting more DB platforms is also on my wishlist, but not sure it can be done in the next year as there are some challenges there. 

Note: replaced original/longer post with summary/bullet points.