Leaderboard

With huge amounts of gratitude for everything you do to make PW as great as it is: I know this is not in the intended spirit of this thread, so apologies for that, but honestly what I would most like to see is fixing all of the current Github Issues before anything new is implemented. I personally still have 49 open issues, many of which require ugly hook workarounds, some result in things being broken for site editors, and others are inconsistencies in the API which continue to trip me up. I am honestly struggling to put energy into thinking of shiny new feature ideas with these things always impacting my workflow.

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.

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!

I'd love to suggest other things as well, but for now I'll just say that this is also my experience. Sorry in advance if this turns into a rant, but I feel that this is an important topic ? Past few years we've shifted our focus so that now we mainly use ProcessWire for sites with heavy focus on application like features and structured content, while "regular websites" are more often built with WordPress. There are cases where ProcessWire is stronger, and it can be used to build flexible, content block based sites using something like Repeater Matrix, but to be fair Gutenberg (which I/we use solely, no other page builders) is on another level when it comes to built-in flexibility and WYSIWYG. With one exception: you can't have multiple "Gutenberg fields" on single page, which can, in fact, be a pretty big bummer in some cases; and that could also be a potential benefit if we did have some sort of block builder in the core. (... and if ProcessWire, on a core level, wants to focus more on directory / application type sites, there's nothing wrong in that either. It just means that we, as a group of ProcessWire developers and enthusiasts, will be "losing" a large — and likely increasing — amount of potential clients and projects for other systems.) The work done by Bernhard and jploch is fantastic, but for me the biggest question mark is probably that these are not core features, meaning that they are not something that is "officially supported" by the core / core team. They are also not free / open source software, which means that the community directly participating in their development is not really an option, in my opinion. I'm not sure what the best solution, especially since this is clearly not a common need/requirement for Ryan, but I do hope that we could eventually have some level of support for this at the core — even if it's not "full-featured", but rather a framework that can be expanded / built on top of. Using Gutenberg as an example: I don't have a real figure, but I can tell that a team has worked on it for many years now, and continues to do it on a daily basis. It's not realistic to assume that a single developer could truly compete with that. And one thing I've learned about page/block builders is that there's a lot of nuance and the architecture is a major question that could make or break it, so doing it without solid understanding of what the results of each choice is way down the pipeline would be a huge gamble. (In case of Gutenberg the architecture is a hot mess: there are no dedicated data structures, and they keep changing and breaking internal code all the time. But, again, they have enough resources to handle that, and the project has so much momentum that while developers may complain, eventually they'll have to go with the flow.) As for Ryan's point about preferring to "avoid features that blur the line between content and style or front-end and admin", which I assume was related to this request (to some extent at least), I'm sure there are ways to handle content block GUI in the admin without putting too much focus on how they look like on the front-end. E.g. tje editing interface could be more like a wireframe with some similar structure than "the final product". Front-end editing is an option, but... I must admit that I like the "middle ground" that Gutenberg has, where you're still editing content in the admin. Obviously introducing front-end styles for the content in admin is not a nobrainer, which is why many sites — in my experience — won't even aim for fully stylized (custom) blocks in the admin. WYSIWYG is a big topic in itself ?

I'd like to highlight this because it only requires willingness and nothing more, but it would streamline upgrading efforts significantly. Enforcing it on 3rd party modules would also be welcome. See: https://semver.org/ The current versioning chaos is a drawback for sure.

Overview The TextformatterTokens module allows other modules to register tokens and replace them with actual values. Installation Enable the TextformatterTokens module. Enable the SiteTokens module. Enable the TextformatterTokens text formatter for a field. Usage Use tokens provided by the SiteTokens module inside a field that has the TextformatterTokens text formatter enabled. Save and display your page. The tokens should be replaced with the actual content. Example Tokens [site:name] [page id=123] where id is the ID of the page you want to embed its body field. Debugging You can view logs under your ProcessWire admin dashboard at Setup > Logs > tokens. Writing own tokens To create custom tokens, refer to the SiteTokens.module file for an example implementation.

Thank you for all of the valuable comments last week! I'll reply to several of the comments soon in last week's thread. A couple months ago a new addHeaderAction() method was added to to our Inputfields JS API, enabling you to add custom header icon actions to any Inputfield (more details here). A short while later, the same method was added to our Inputfield PHP API. This week it's been expanded so that now you can also add drop down menu header actions to Inputfield, like the one in the screenshot below. Though this is just a simple example: Here's how we defined that action and menu in JS: $f = Inputfields.get('checkboxes_field_name'); Inputfields.addHeaderAction($f, { name: 'tools', icon: 'fa-wrench', tooltip: 'Select or unselect all', menuItems: [ { name: 'select-all', label: 'Select all', icon: 'fa-check-square-o', // called when the user clicks on the action callback: function() { $f.find('input[type=checkbox]').prop('checked', true); $f.trigger('change'); }, // called to determine whether action is available to click on (optional) active: function() { return $f.find('input[type=checkbox]').not(':checked').length > 0; } }, { name: 'unselect-all', label: 'Unselect all', icon: 'fa-square-o', callback: function() { $f.find('input[type=checkbox]').prop('checked', false); $f.trigger('change'); }, active: function() { return $f.find('input[type=checkbox]:checked').length > 0; } } ] }); For more details on the options, see documentation here in the inputfields.js file where the addHeaderAction() function is defined. How does that JS code get called in the admin in the first place? Well there's a lot of different ways you could do that, but in my case, I hooked after ProcessPageEdit::loadPage in my /site/templates/admin.php file and added a custom .js file (containing the code above): $wire->addHookAfter('ProcessPageEdit::loadPage', function(HookEvent $e) { $page = $e->return; /** @var Page $page */ $config = $e->wire()->config; if($page->template->name === 'tour') { $config->scripts->add($config->urls->templates . 'scripts/admin-tour.js'; } }); Have a great weekend!

Version 2.2.11 contains a new feature: Use FrontendForms inside CKEditor fields This new feature allows you to load forms inside CKEditor fields via the usage of placeholders. It supports the loading of the same form multiple times in one or more fields. Short description: Use placeholders like {{myform}} inside your CKEditor field. The placeholders will be replaced with forms during the page render process on the frontend. A more detailed description about how it works and containing a code example can be found inside the docs. This is a brandnew addition, so test it carefully before using it on live sites. Jürgen

I lost 85% of our clients to WordPress due to page builders like Elementor. They aren't concerned with code clutter, page speed and SEO disadvantages. I would love some offerings in that direction, I am aware that this maybe will open Pandora's box. Some praise here for ProcessWire: ProcessWire is unbeatable for websites that almost work as applications. We coded the whole backend office management for our web design firm with ProcessWire including tons of SEO-, Data protection-monitoring- and wp-plugin-updates-montitoring crawlers and checkers: We kind of remote control WordPress from ProcessWire. Clients can log in and see everything they booked at a glance, and can order things directly from ProcessWire, and it is directly connected to the invoicing app. This is a unique system, 10 years of work in it and now makes the entire company manageable by a minimal team, unthinkable without ProcessWire. Thinks I would like in PW4 are things I am used to from WordPress, a full switch to utf8mb4, those needed GDPR utilities out of the box, modules can be "deactivated" leaving the settings intact, and "removed" to make troubleshooting modules compatibility issues much easier. Some image optimization capabilities would be great, the existing 3rd party modules do not meet our expectations yet. Also a good monitoring/curation of outdated/abandoned modules, with supplied warnings, would be great; there are a lot of those old modules, unfortunately.

@Ivan Gretsky @cb2004 @David Karich Sorry, I must not have written it very well. I'm tired, but wired from coffee at the same time, maybe not a good combination. In any case, I'm enthusiastic about most of the suggestions, even if I can't implement them all. I've updated the original post to just summarize the main points instead.

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.

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.

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!

I tend to agree with some of the previous posts: ProcessWire is doing a lot of things right, but it feels like there's some catching up to do in terms of open issues and general level of polish. Some of these are making ProcessWire look a bit long in the tooth compared to other CMSs — catching up with the ecosystem here would be a great signal that it's a mature and stable project keeping up with the times. Full composer installation: all core files living inside /vendor, any user files and modules outside of it Automated test suite: at least for the critical parts like the selector engine and php version compatibility Extend image format support: WEBP, AVIF, JPEG2000, etc as input and output formats, as well extensibility for future formats without major architectural changes Semantic versioning: there's currently no way of knowing if an upgrade brings bug fixes or new features (and possibly new bugs), they're all patch releases lately Environment variables: read config from .env files to avoid editing/overwriting config files for each environment nginx support: Apache is showing its age somewhat, and a lot of deployment solutions target nginx by default

@Juergen amazing stuff. Thank you very much.

Just sharing my personal thoughts and what would be incredibly useful for a lot of my projects...: Very basic page builder functionality / WYSIWYG Especially something to build basic layouts with sections, rows, columns. I know there are third party modules and it can be achieved with repeater matrix but it get's unintuitiv very fast. That's actually the main reason to not use processwire for some of my projects.? Additional text fields for images fields alt text, title and caption is something that is actually constantly needed and i personally think that it could be the default (instead of setting up custom fields) Native .avif format support The .avif format would be a great addition and has a better compression compared to .webp full nginx support Have already hosted a projects without any issues but as far as i know it is not fully supported?! field type "date multiple" I guess that's a pretty specific one, but would be really helpful to me so i share it anyways.

I do not think anyone suggested having "more" initialization methods. Instead, it would be nice to see fewer of them while still being able to initialize everything necessary. Most importantly, the documentation could be extended to show real-life examples of how to use Custom Page classes, including implementing some form of abstracted page request handling (both get and post) without having to use if/else trees at the top of template files. Regarding adding hooks, I use a static method, which should not incur any overhead. I explain it in this post of mine: Quote: /** * ... page specific hooks. This method is called from site/init.php from my custom loop * that runs for each frontend template based page. * if (in_array($templateName, config()->noneFrontendTemplates)) { * if ($templateName === "user") call_user_func_array("{$namespace}{$className}::initiate", []); // UserPage needs special treatment. * continue; * } * if (class_exists($namespace . $className)) call_user_func_array("{$namespace}{$className}::initiate", []); // Page classes register hooks in their initiate() method this way. */ public static function initiate() { parent::initiate(); wire()->addHookBefore("Pages::saveReady(template=product)", function ($event) { ... more hooks go here .... Having the code of hooks in the same file as the custom page class is a productivity booster for me. After all, in those hooks, the object we deal with is (mostly) a page object of that type. I would be happy to put that code in some other equally well-organized "spot" but putting hundreds of hooks directly into init.php and similar files is a big mess in my opinion.

I would like to see SEO support integrated into PW by default. I know that there is the SEO Maestro module, which is fabulous, but I think every CMS should have a good SEO support by default. So it would be great if a new tab will be added to the pages like this: In addition to this, there should be a new property inside the configuration file to disable/enable the tab globally in the way like this. $config->seo = false; // or true And in the settings of the page, there could be a checkbox to enable/disable the SEO tab per page. The content of the SEO tab could be as it is in the SEO Maestro module.

@ryan reading your reply makes me realise you are such a master of your craft, but you can't take all this on by yourself to grow the project. Rather than the community telling you what they want, tell us how we can help you.

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 ?

Please check out the new version on the dev branch which will be merged begin of next month: // site/ready.php wire()->addHookAfter("RockFrontend::addLiveReload", function ($event) { // if the current user is a guest user we override the // original return value and set it to false // which will tell RF to not add livereload markup if(wire()->user->isGuest()) $event->return = false; });

Hello @dotnetic Version 2.2.10 contains your feature request. Read more about it in the changelog.md. Jürgen

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

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.

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.

Thank you! I have just published this module to Packagist. It can be obtained through Composer with the following command: composer require zigit-dev/textformatter_tokens

Inspired by @horst's helpful post above, here is some code for preventing guests from accessing original images that leverages more of the PW API... In .htaccess, just after "RewriteEngine On" # When original images are requested, rewrite for PHP user verification # If a matching file exists RewriteCond %{REQUEST_FILENAME} -f # And the file is within the /site/assets/files/ directory RewriteCond %{REQUEST_FILENAME} (^|/)site/assets/files/(.*?)/ # And the file extension is for an image type that we want to restrict access to RewriteCond %{REQUEST_FILENAME} \.(jpg|jpeg|gif|png)$ [NC] # And the filename portion of the path contains less than two dots (i.e. is not an image variation) RewriteCond %{REQUEST_FILENAME} !^(.+\/)?[^\/]+\.[^\/]+\.[^\/]+$ [NC] # Then rewrite to a hooked URL for user verification RewriteRule ^(.*)$ index.php?it=/original-image/ [L,QSA] In /site/ready.php // A URL hook for verifying that the user is allowed to view original images $wire->addHook('/original-image/', function($event) { $path = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH); $ext = pathinfo($path, PATHINFO_EXTENSION); $filename = $event->wire()->config->paths->root . ltrim($path, '/'); $allowed_exts = ['jpg', 'jpeg', 'png', 'gif']; // Optional: get the Pageimage and the Page it belongs to // if this affects whether the user is allowed to view the file // $pm = $event->wire()->pages(1)->filesManager; // $pageimage = $pm->getFile($filename); // $page = $pageimage->page; // Send the file if the user is allowed to view it if( // The file extension must be one of the allowed extensions in_array($ext, $allowed_exts) && // The user must be logged in $event->wire()->user->isLoggedin() && // The file must exist is_file($filename) ) { $event->wire()->files->send($filename); } // Otherwise, return a 403 Forbidden response header('HTTP/1.0 403 Forbidden'); die('403 Forbidden'); });