Leaderboard

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.

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 ?

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!

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

Not it seems that those settings are not part of the Docs (at the moment). Have a look in inside RockPageBuiler.module.php on Line 257. There you will finde all attributes that you can change in the markup: // setting specific to rockpagebuilder blocks 'noBlock' => false, // prevent block icons if true 'addTop' => null, // set to false to prevent icon 'addBottom' => null, // set to false to prevent icon 'addHorizontal' => null, // shortcut for addLeft + addRight 'move' => true, 'isWidget' => $isWidget, // is block saved in rockpagebuilder_widgets? 'widgetStyle' => $isWidget, // make it orange 'trash' => true, // will set the trash icon for rockpagebuilder blocks 'clone' => true, // can item be cloned? 'widgetable' => $widgetable, // can be converted into widget?

Did you try hooking after ProcessPageView::finished? That's what LazyCron does. You may want to add a check for regular page views like LazyCron does here.

Why not combine something like PageRender::renderPage() or whatever is closest to your needs and LazyCron in this case? Or trigger it with something in your template or a global include. What do you want to achieve with this?

That looks good! I have just finished a project with some complex layouts that required some nested RockPageBuilder blocks. And I did it the same way as you. I have multiple layouts block that just render the markup: A layout block looks like this: <?php namespace ProcessWire; use RockPageBuilderBlock\LayoutA; /** @var Page $page */ /** @var LayoutA $block */ ?> <section class="rpb-layouta" <?= alfred($block,["trash" => false, "clone" => false, "widgetable" => false])?>> <div id="div1" class="col-2x1"><?= $block->rpb_cell_2_1_a->render(true); ?></div> <div id="div2" class="col-1x1"><?= $block->rpb_cell_1_1_a->render(true); ?></div> <div id="div3" class="col-1x1"><?= $block->rpb_cell_1_1_b->render(true); ?></div> <div id="div4" class="col-2x2"><?= $block->rpb_cell_2_2_a->render(true); ?></div> </section> Inside there are some nested - custom - RockPageBuilder fields. Inside these fields you can insert various other RockPageBuilder content blocks. Like Text, Images, whatever. This is especially neat when editing the site in the frontend. The "naked" layout block looks like this: Then you can insert content to each of those cells via the nested RPB fields; However I have to say that the backend editing of these blocks is a bit "convoluted". When the project reaches a "final state" I will explain the details in a showcase here in the forum in more detail.

Logs JSON Viewer Formats JSON data in ProcessLogger for improved readability. Because log files can only contain strings, it's a common practice to use json_encode() to convert an array to a string when you want to save the data to a log file. But the resulting JSON is not as readable as it could be when viewing the log in ProcessLogger. The Logs JSON Viewer module uses the json-viewer library to improve the readability of JSON data in ProcessLogger and add some useful features. Before: After: Configuration You can set the config options for json-viewer in a textarea field. See the json-viewer readme for information about the options. There is also an option to set the width of the column that contains the JSON data. This setting exists because otherwise the column jumps around in an inconsistent and distracting way when changing from log to log or between paginations. Features You can switch the view of the JSON data between formatted and unformatted using the toggle button at the bottom of the data. The viewer has a number of useful features such as: Progressively expand or collapse levels in the data. View the count of child items and the data type of each item. Search for a string within the data. Copy all or part of the data to the clipboard (requires the HTTPS protocol). https://github.com/Toutouwai/LogsJsonViewer https://processwire.com/modules/logs-json-viewer/

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

Hmm. As far as I understand, none of the proposed goes straight into next major version roadmap. Or am I wrong? @ryan, please direct us. Should we write more proposals? Which direction should we move?

Version 0.2.2 of the ProcessWire IndieAuth Module is released: Admin tools to support the Client Credentials flow and manually adding a token when testing Added an Introspection endpoint Updated client information discovery. It now prefers the JSON document and falls back to parsing microformats2. Scoped dependencies so this can more easily run on the same site with ProcessWire Webmentions without conflicts More in the changelog

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.

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.

I would say the easiest is to add an "edit bookmark" to this page, it requires no module or hook nor moving the page in a specific location. Go to modules page Click the tab Configure Find the module Page Edit and click Configure Check to enable bookmarks Go to menu Pages > Edit > Bookmarks Add the bookmark for your page with the corresponding user role (select everyone if no specific role is necessary) Now you can access this page with menu Pages > Edit > Your page

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

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.

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.

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.

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.

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!

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'); });

@joe_g, you could use a similar approach to that used by the Repeater Images module. Demo... Repeater Matrix field config: Hook in /site/ready.php: $wire->addHookBefore('Pages::saveReady', function(HookEvent $event) { /** @var Page $page */ $page = $event->arguments(0); if($page->template == 'demo_matrix_upload') { // File extension to Repeater Matrix type and subfield mapping $matrix_types = [ 'jpg' => [ 'type' => 'jpg', 'subfield' => 'image', ], 'mp4' => [ 'type' => 'mp4', 'subfield' => 'file', ], ]; // For each file in the "Upload files to Matrix" field foreach($page->upload_files_to_matrix as $pagefile) { // Skip file if it does not have an allowed file extension // It also makes sense to configure the upload field to only allow // the extensions you have matrix types for if(!isset($matrix_types[$pagefile->ext])) continue; // Add a Repeater Matrix item of the matching type for the file $item = $page->matrix_files->getNewItem(); $item->setMatrixType($matrix_types[$pagefile->ext]['type']); // Save the item so it is ready to accept files $item->save(); // Add the file $item->{$matrix_types[$pagefile->ext]['subfield']}->add($pagefile->filename); // Save the item again $item->save(); } // Remove all the uploaded files from the upload field $page->upload_files_to_matrix->removeAll(); } }); Result:

Welcome @Rasso! While ProcessWire doesn't have built-in support for migrations or version-controlled field definitions, it already supports export and import of field definitions via JSON, albeit only manually via the admin interface. However, it being JSON-based should be a good enough base to start automating some of this, e.g. by saving and reading the JSON from disk. That would also make them version-controlled as well. I agree this should be part of the core. Most CMS have solutions for this and it'd be a useful feature to advertise. The landscape of modules here is somewhat splintered. The module that integrates best with the core, Migrations, has unfortunately been deprecated. I haven't fully tested RockMigrations yet, but from what I've seen it seems to be doing a few things too many (snippets, "magic pages", "files on demand") and I'd prefer a module that limits itself to migrations, if not just for performance. +1 for a ProMigrations module from @ryan to ensure the best level of integration into the core.

As it happens I was just last night tinkering around with a module for this: info here.