Leaderboard

This week I've been focused primarily on keeping up with the conversation about requests for 2021 and beyond, as well as doing related research here. We are starting to narrow in on ideas and plans, but there's more to cover still. Most of the conversation is happening in the PW 3.0.170 thread and last week's update thread. If you want to see what our preliminary roadmap looks like, Teppo did an amazing job covering it in the ProcessWire Weekly #348. I don't recall where it was or who asked, but I remember someone asking whether things like "thumbs up" quantities on GitHub issue reports and feature requests are paid attention to. And the answer is, not really so far. That's because GitHub doesn't display this info anywhere other than on the actual issue report. And even then, I often don't notice it. But this week I've been looking into it more and see that we can sort GitHub reports by quantity of thumbs-up votes. (Maybe the rest of you knew about this, but I guess I'm slow when it comes to GitHub). So it turns out that these thumbs-up votes aren't just social media fluff, they are actually very useful on issue reports and feature requests. Usually I cover these things newest-to-oldest, but now I'm going to start going through in order of votes, as this seems to make a lot more sense. Sorry I didn't catch this useful feature earlier. Please use the thumbs-up votes on GitHub for issue reports and feature requests that you value the most, and going forward, that will help us to cover them in a useful order. Next week I'm booked on a client project (working in PW), so it may be quiet for another week in terms of core updates, but then will be back to wrapping up our roadmap and ProcessWire development. Thanks for reading this far and have a great weekend!

Just my five cents (or fifty, looking at the length of this answer): There is zero interest here to move ProcessWire away from what it does now, or somehow get rid of the way it handles structured data. Absolutely zero. If you're worried that someone wants to thrash the system we now have and replace it with a Gutenberg clone, fear not: that will not happen, period. Now, as you've pointed out, there are different use cases. Almost all the sites I build and clients I work with nowadays require a "builder" approach: flexibility in terms of laying pages out. CKEditor goes to some extent here, but it's riddled with issues, and honestly the experience can be pretty horrendous: image management in particular is a lacklustre, and embedding any type of dynamic content (or anything CKEditor doesn't handle itself) gets difficult/technical (short codes with params etc.) A couple of reasons why comparing what we're doing to what WP is doing with Gutenberg makes little sense: In WordPress Gutenberg is going to replace the "classic editor", and it's also going to replace a lot of other built-in tools (such as menu management GUI) in the long term. The ultimate goal there is a "full site editor". This has very little to do with what we're discussing here. WordPress has never (natively) provided custom fields. Instead they have predefined fields and (freeform) page meta. ACF and similar plugins that make custom fields possible are popular, but page builders are even more so. It makes sense for the core team to extend the core with the tools that most users seem to want. I could get into the reasons why Gutenberg reviews are so bad — such as there being a lot of history, a lot of resistance to change, a lot of misunderstanding, likely mostly developer votes while the feature itself is aimed more at content editors, and so on — but I won't. My point is that improving the ability of ProcessWire to handle flexible layouts is not going to take anything away from those who don't want or need that. ProcessWire has many things that some users don't need or use. For an example, I've never used front-end editing for client sites. It's a feature I don't need, so I don't use it. It's as simple as that ? I'm going to cherry-pick one thing from this list: "I want to protect the entire site" ? I've worked on many completely non-public sites. While I believe I get the reasons @ryan has for not allowing the home page to be non-public, I would absolutely love for this to change. Even if it required a hook or config setting, that'd be a very nice addition. Currently I'm doing this with custom code, but there are some negative implications and I'm always a bit worried that it'll break: first of all it's (my) custom code and if something changes there's always a slight possibility that it won't work as expected, and second of all it needs to be done with hooks (to protect assets and make sure that nothing can interfere) and can thus sometimes get a bit complicated. TL;DR: if there was an option to somehow protect the entire site so that all non-authenticated requests (home page included) result in a login request, I'd be one happy user ?

I have a lot of thumbs-upping to do... ? Anyway, I couldn't find related request right away. I know this has been requested and discussed on various occasions but I assume it's not such a common need that anyone would've yet opened a request for it in the "new" repository, or perhaps those asking about it here or googling for this found an earlier answer and figured that it'll be unlikely to change. Here's a new request: https://github.com/processwire/processwire-requests/issues/376.

Is it in the requests repo yet? If not, if you add it I'm happy to give it a thumbs-up ? From now on, GitHub thumbs-ups are the way to go: Ryan says: "Please use the thumbs-up votes on GitHub for issue reports and feature requests that you value the most, and going forward, that will help us to cover them in a useful order." I guess it also means we should not use the heart or any other positive looking reaction as GitHub seems to be able to sort on one reaction only, that is why it is only useful to stick to thumbs-up.

Hi @ryan thanks for the great info about the future of PW from last week and thanks for the condensed list above. I agree with most of what's already been said, but want to add some points as I've been heavily working on several mentioned areas over the last year. IMPORTANT: Admin Theme As mentioned I've been working on a better admin experience for quite a long time. This is an example screenshot of RockSkinUikit (which I'm not using any more): My key goals have always been easy things: Make it easy to change ONE main color which does look good in most situations (because the secondary colors are gray) Make it easy to change the Logo Make it easy to add custom CSS/LESS -------- I am now using a custom Admin Theme module AdminThemeRock that does look similar to what I've built using RockSkinUikit: Again: Custom color, custom logo, that's it! -------------- Another one: Custom color, custom logo: ----------- Another one changing only the main color (page tree example): ------------- Learnings: If the core changes, my theme breaks!! That's a no-go. I've had to add several custom hacks to my theme that make it out of sync with the core. But important parts of the theme have not been hookable, so that was my only option meaning I have to pull all changes from the core into my admin theme module. I guess nobody else is as crazy as I am and that might be one major reason why we have not seen any other admin theme modules... My theme uses the old admin theme repo sources, because we do not have any source files in the core... https://github.com/ryancramerdesign/AdminThemeUikit/ PLEASE add the source files the core or in a separate repo that we can fork or help with PRs!! I've added you to my private repo on github so that you can see all the changes that where necessary for getting everything to work. For all others, here's an example of how my dirty core hacks look like: getNav() and getSearchform() are hookable methods that I added to my module. I've also built a frontend module that I'm using on my sites. There I use a simple but very effective technique that uses one single render() method to render several code blocks that I organize in files: // file structure foo |-- foo1.php '-- foo2.php bar |-- bar1.php '-- bar2.php // code echo $uk->render("foo/foo1"); echo $uk->render("bar/bar2"); This keeps the files organised and makes it very easy to do custom modifications before or after a file is rendered: $wire->addHookBefore("RockUikit::render(foo/foo1)", function ... ); $wire->addHookBefore("RockUikit::render(bar/bar2)", function ... ); Using a dom parser like https://github.com/paquettg/php-html-parser would even make it possible to modify/add/remove single html elements of the returned output! Of course having custom hooks would be more elegant and performant, but I wanted to mention this option nevertheless. Support for a Dashboard-Page That's another big thing for all my pages. I don't want to show the pagetree to logged in users unless they really want to see it! Take this simple example: Or this more beautiful one: The latter is taken from the Dashboard module which proves the big demand of the community for such a feature! I don't want to talk bad about this module here, I've shared my thoughts in the related thread with @d'Hinnisdaël and should maybe go for a beer with him when all this covid thing is over, but IMHO the module has two major drawbacks that would not be necessary! 1) It introduces a whole new concept to the PW admin that is already there. The PW admin is built upon inputfields and it would be very easy to build a dashboard (or to be more precise, the dashboard widgets) using these existing tools. (this is built using inputfields). 2) Making the admin show the dashboard instead of the pagetree feels hacky in several situations. We've discussed that here: One problem is, for example, that the breadcrumbs do not work as expected any more. Clicking on breadcrumb "bar" in " foo / bar / foobar " would take you to the dashboard and not to " foo / bar ". ############################################ Would be great: Migrations I think the core and all modules could benefit greatly from easy api migrations like I have built in my RockMigrations module. It's far from perfect, it's not very well documented, but it does some things right in my opinion and that's why I have it in all my installs and nowadays have it as requirement for almost all my modules that I build. Why? Because I want to have my fields under control of GIT Because I want to write an easy setup file that creates all fields/templates/pages that I add to this codeblock Because I want to push changes to my live server without exporting fields via mouseclicks, then updloading json files, then going through a migration click-marathon again, when I can simply do git pull & modules refresh Because I want to be able to create reusable components easily. I know that one can do all that using the standard PW API and creating a custom module, but take this example and see how easy and clear things get when using RockMigrations (or even better a solid core migrations API): I've recently added an example module that shows how I'm using RockMigrations now: https://github.com/BernhardBaumrock/RockMigrations/blob/master/examples/MigrationsExample.module.php ############################################ Brainstorming: ProcessWire without DB We all love ProcessWire and it's tools, but there's one drawback: The great API is only available if we have fully installed version of ProcessWire available. That has been a problem for me when I tried to work on a module that installs ProcessWire automatically (PW Kickstart and now working on RockShell). Examples of such classes that might be useful even without a DB connection could be: WireData WireFileTools WireRandom WireTextTools WireHttp Sanitizer I know that there are several cases where DB settings are absolutely necessary (for example page data or sanitzier settings), but there are other frameworks, that show, that such a concept can work and make a lot of sense: https://nette.org/ One might argue, that this might be going too far... But if we are talking about the future of PW, why not thinking of something like this: // copy files to root folder include("index.php"); $wire->install([ 'user' => 'demo', 'pw' => $wire->random->alphanumeric("8-12"), ... ]); Or take another example: https://processwire.com/api/ref/wire-mail/ There's no reason why we need a running PW instance with a DB connection for such a code example. Of course I know that it's technically required in many places in the core, but maybe these places could be identified and removed in the future?! Or maybe PW could support noSQL or something? ############################################ Would be great: A better Date/Time/Range-Field (dream: Support for recurring dates/ranges) I've started a discussion here and as you can see the post got a lot of attention: ProcessWires date field is nice, but it is a PAIN to work with date ranges, to build calender-like applications, to get the proper entries from the DB, etc... Why? Because the only option right now is to add TWO date fields to one template and there the problems begin... What if you want to make sure that one date is after the other? What if you want to show all events of one month? There's a HUGE potential for bugs like "foodate < $lastOfMonth" should have been "foodate <= $lastOfMonth" How to get the timestamp of $lastOfMonth properly? An API like https://carbon.nesbot.com/ would be great! What if events can have a range (like from 2021-01-10 to 2021-01-15), but can also be a single day event (2020-12-24). What if an event is on one day but has a start and end time (2020-12-14 from 18:00 to 22:00)? What about timezones? How to do the proper formatting? Showing a date like this "2020-12-24 18:00 to 2020-12-24 22:00" is a lot worse than "2020-12-24 18:00 - 22:00". This gets even more complicated when you want to show the days... What if you want/need to handle recurring events...? ############################################ PageBuilder I've taken several runs on that topic and finally (?) found a good solution during development of one large project last year. My approach was to make a new Fieldtype similar to Repeater and RepeaterMatrix, but with some big conceptual differences (it's more like Repeater than RepeaterMatrix): Every item is a single page in the tree and has a custom template Every repeater item can live anywhere in the pagetree Every item is defined in a single PHP file (using RockMigrations to make it reusable) This makes the setup very flexible on the one hand, makes it reusable across projects (simply copy the file and do a modules::refresh triggering the migrations) and makes it REALLY simple to use for the clients on the other hand: Setting up such a block is quite easy: class Headline extends \RockMatrix\Block { public function info() { return parent::info()->setArray([ 'icon' => 'header', 'title' => 'Überschrift', 'description' => 'Fügt eine Überschrift auf der Seite ein.', ]); } public function init() { $this->addHookAfter("Pages::saveReady", $this, "saveReady"); } // this method makes it easy to customize the item's edit-form // you can change labels, collapsed state, add notes or custom classes etc... public function buildForm($fs) { if($f = $fs->get('title')) { // dont show label for this inputfield $f->skipLabel = Inputfield::skipLabelMarkup; $f->wrapClass('rmx-pd5'); // add class to remove padding } } // the label of the repeater item public function getLabel() { return $this->title ?: $this->info()->title; } // migrations for this item public function migrate() { // the parent migrate creates the necessary template for this block parent::migrate(); // then we set the title field optional for this template $this->rm()->setFieldData("title", [ 'required' => 0, ], $this->getTpl()); } // code to use for rendering on the frontend public function render() { return "<h3 class='tm-font-marker uk-text-primary'>{$this->title}</h3>"; } // optional saveready hook public function saveReady(HookEvent $event) { $page = $event->arguments(0); if($page->template !== $this->getTpl()) return; if(!$page->id) { $page->title = "This is my initial headline"; } } } As you can see in the screenshot, I'm using CKEditor for editing fulltext. That's great, because I can remove all plugins that do usually need more education for clients (like inserting images) and build custom blocks solely for this purpose that every client can grasp a lot quicker and where I have a lot more control and freedom (since the block is a separate template). This means I've always had the freedom of custom image fields even before the image field supported them. Another example: A gallery block (headline + image field): I'm not sure about the scalability of this approach, but having all blocks as custom pages is a huge benefit in many ways. For example I could create a Matrix field having invoice items. Each item would be a page of type "invoiceitem" and then I could query all "invoiceitems" using RockFinder and build an average invoice NET or GROSS value of all invoices of 2020... Access control, page status, etc etc are still challenges though, of course. ####################### I hope that all makes sense and I'm willing to share any of my modules code if that helps. Or give you a demo/walkthrough via screenshare. One last question, as we are talking about the future of PW: One thing is what would happen to the core of PW if anything happend to you @ryan. But we could at least fork the core and do... whatever then would be necessary to keep all our businesses running and all our clients happy. But what about all the Pro modules? We could not get a copy of them and work on ProCache for example on our own (as a community). Did you think about that szenario and have a reassuring anwer for us? ? Of course, I wish you a long life and many happy years of developing PW - it's absolutely impressive what you have built here ?

Last week I asked you what you'd like to see in ProcessWire in the next year (and years ahead), and we got a lot of feedback. Thank you for all the feedback, we've had a lot of great and productive discussion, and of course feel free to keep suggesting things too. Below is a summary of things based on what I thought was feasible from the feedback so far. I'm not suggesting we'll be able to do all of this in 2021, but do think it makes a good preliminary roadmap of things to look closer at and start working on some very quickly. I'll keep working to narrow this into a real roadmap, but wanted to share where we're at so far (consider it preliminary/unofficial): Flexible content or page building One of the most common themes has been that people want more content building options as an alternative to using a rich text editor at one end, and page builder at another. This is a direction that some other CMSs have been going in (like WordPress), and one that many would like to see ProcessWire provide an option for as well. But the needs seem to come from two different angles, and it points to us pursuing 2 directions simultaneously: First would be a flexible content block style editor in the core as an alternative to rich text editor that supports pluggable block types while maintaining best content management practices. If possible, we'd use an existing tool/library like editor.js or another as a base to build from, or potentially build a new one if necessary. To be clear, it would not be a replacement for CKEditor but an alternative approach supported by the core. Second would involve improvements to Repeater/RepeaterMatrix that enhance its abilities in supporting those using it for building more complex content page builders. Since many are already using it for this purpose, the goal would be primarily to better and further support this use case, rather than make Repeater/RepeaterMatrix a dedicated builder. Jonathan Lahijani and others have pointed out some specific things that would help achieve this and I plan to implement them. Admin theme improvements We would like to add additional flexibility to the AdminThemeUikit theme so that people can further customize it how they would like it. What directions this will take aren't nailed down quite yet, other than to say that it's going to be getting some focus (and this has already started). At the very least, we know people want more sidebar options and the ability to tweak specific CSS, perhaps in a preset fashion. Improvements to existing Fieldtypes and Inputfields Things like support for a decimal column type, more date searching options and additional input level settings on other types. Though these are specific feature requests and our focus is more broad, so we'll be going through many of the core modules and adding improvements like these and more, where it makes sense. Pull requests and feature requests People would like to see us expand our code contributor base by merging more pull requests in cases where we safely do it. We will also be narrowing in on the specific feature requests repo to see which would be possible to implement this year. External API There are requests for an external/front-end API that would also be accessible from JS. I support the idea, but have security concerns so am not yet sure if or in what direction we might take here, other than that I would like us to continue looking at it and talking about it. File/media manager and more file sharing options There is interest in an option for a central media/file manager so that assets can be shared from a central manager rather than just shared page to page. There is also interest in the ability for file/image fields to reference files on other file/image fields. External file storage Some would like to be able to have PW store its /site/assets/ and/or /site/assets/files/ on alternate file systems like S3. That's something we'd like to use for this site too. To an extent, work already started on this last year with some updates that were made, but there's still a long way to go. But it will be great for sure. Live preview and auto-save There are requests for live preview and auto-save features to be in the core. Currently they are just in ProDrafts, but there are now more options and libraries that would facilitate their implementation in the core, so I'd like to see what we can do with this. More multi-site features There is interest in ProcessWire natively supporting more multi-site features, potentially with the option of working with our multi-language support.

The title field is already optional. You just need to make it non-global by editing the Title field and unchecking the Global checkbox on the Advanced tab. Then you can remove it from any templates where you don't need it. If you want to see the values of other fields (instead of Title) in Page List you can set that on the Advanced tab when editing the template.

That has to be me, because some/many other Open Source repositories handle requests this way, and thats how I have done it there. Let ProcessWires users decide, what is most important to them. Also the thumbsup/+1 is a better way to handle this instead of a "I also have this issue" comment, because else you would get nagged by the comments, and they provide no additional value. This is a good step to let the community know that their word and wishes also matter and they play a role in ProcessWire development. The README and issue/request templates should reflect this procedure.

This is EXACTLY what I had to hear. Thank you! ?? I'm open to any new approaches and improvements with .js editing/building as an option. Just don't want to lose my new, beloved home... ☺️

Version shouldn't matter, since this change has occurred on the YouTube side. If neither of these sites is using HTTPS, then I'd suspect that it's a caching thing: Textformatter Video Embed stores embed codes in the database, so if that other site has fetched the code via HTTP while it was still possible, it'll continue to work until you clear said cache from the database. Google has in the past also deprecated features in weird ways, so that they've kept working for existing sites/domains but not for new ones, though I doubt that'd be the case here ?

I dont think anyone here is wanting gutenberg. Take a look at this video. Its basically just the PW backend in a side window instead of full page so you can see what you are editing while you are editing. That way you dont scroll down to a box, save, get shot back up to the top, switch tabs, hit refresh. All that is wasted time. You just edit the box and see the changes. Now, once the editing experience is updated, I think it would be nice to be able to have 2 sets of children for each page. One for the page path/child pages/url, and one for the design rows/sections on that page. So the tree would have a page path mode, and a page design mode that shows children of the page, based on the mode you are in. In the design mode, children of that page would be rows on the page, path mode would be child pages. ie. When I edit a Category page in path mode, maybe it has a text field for Page Title and Page Description, which have nothing to do with design, and its children are the products in that category. If I edit that same category page in page design mode, the first child page is called Intro Section, and has fields for design related settings for that row. I think this would be the best approach becuase the api would have a clear support for adding fields for both view modes, but not force anyone to use anspecificic front end framework or theme. It would be nice to have a slider field time for font sizes.

If your module has a lot of config fields you might want to divide them into groups inside a tabbed interface. Here is a demonstration module showing how this can be done. https://github.com/Toutouwai/ModuleConfigTabs Thanks to @kixe for providing my starting point in this forum topic.

Shetland.org is a website run by Promote Shetland which inspires people to visit Shetland, encourages people to move to Shetland to live, work and study, and attracts people to invest in commercial activities in the isles. We (NB Communication) have run the Promote Shetland service on behalf of the Shetland Islands Council since 2017, and as part of the contract undertook a project to redevelop the existing Shetland.org website. In this showcase we’ll highlight a selection of modules we used and what they helped us achieve. Visit the site: www.shetland.org Pro Modules ProCache We use this on almost every site we build. Indispensable. The cache settings used are pretty simple – most templates are set to 1 week, with the entire cache being cleared on save. We use ProCache’s CDN functionality to serve assets from CloudFront via c.shetland.org. We also use the API provided by ProCache to compile (SCSS), minify and collate our styles and scripts via $procache->css() and $procache->js(). We then use the URLs returned to preload the assets, making the site even faster! ProFields: Repeater Matrix Again, we use this on almost every site we build. Another must have Pro module. This module allows us to create a really powerful page builder field (we call it ‘blocks’) that handles the majority of the content on the site. On a simple development, we just use two block types - Content and Images - the latter displaying as a gallery or a slideshow. On this site we have 13 different types, including ‘Quotes’, ‘Video’, ‘Accordion’, and ‘Links’. Additionally many of these are configurable in different ways, and some render in different ways depending on the template and context. Have a look at the links below for some examples: https://www.shetland.org/visit/do/outdoors/walk https://www.shetland.org/blog/how-shetland-inspires-me-artist-ruth-brownlee https://www.shetland.org/life/why/teach-shetland-school NB Modules We also used a number of modules we've authored: Instagram Basic Display API Used to retrieve the 6 latest images from instagram.com/promoteshetland. Markup Content Security Policy Used to implement a CSP for the site. Currently scoring a C on observatory.mozilla.org – not the best score possible but significantly better than all the other destination marketing websites I tested (all got an F but one which was a D-). Pageimage Srcset Used throughout to generate and serve images of different sizes via the srcset and sizes attributes. This module is really useful if you are looking to optimise the serving of images to improve page speed times/scores. Video markup for YouTube/Vimeo This module was developed specifically for use on this website, as we wanted more control over the rendering of the oEmbed data. In the example below, the video thumbnail is displayed with a text overlay – when clicked the video (YouTube embed) opens in a lightbox. And a big shout out to… Page Path History The previous site was also built by us in ProcessWire, but a number of years ago now. The new site has significant changes to the sitemap, but 1000+ blog posts were also migrated. Instead of an .htaccess file with thousands of 301 redirects, we were able to use the functionality provided by this module to implement redirects where required, and in the case of the blog posts which were migrated via an import script, implement the redirects via the API - $page->addUrl(). ... The above is just a fragment of the features present on this site, and the development just a part of a much larger project itself. We're really proud of what we've achieved, and we couldn't have done it without ProcessWire. Cheers, Chris (NB Communication)

@dotnetic, thanks for the clarification, but I must admit that I still see this mostly as a bad thing. I believe this would work best if issues were actively discussed by both users and maintainers, and/or maintainers were so busy that they were forced to focus only on those issues that attract a considerable number of new reports from users on a steady basis. In our case that's, in my opinion, not the case: an issue or feature request can be valid even if it hasn't received comments, or been acted on by Ryan, in months -- if not years. Anyway, that's just my take on this. It's not a bad idea per se, I just don't see a lot of value in it in our specific context ?

@teppo I modified my post about the stale plugin. You can configure the label and if the issue should be closed automatically.

I think you're better off not using FieldtypeCache. See this issue for some discussion: https://github.com/ryancramerdesign/ProcessWire/issues/1577 And I remember Ryan commenting somewhere that he's thinking of removing it from the core. The simplest thing if you want to merge multiple fields into a single field for search purposes is to use the SearchEngine module. Or if you want to go more hands-on it's not difficult to populate a hidden "index" textarea field from other field values using a Pages::saveReady hook. $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); if($page->template == 'your_template') { $index = $page->title; if($page->body) $index .= ' ' . strip_tags($page->body); foreach($page->tags as $tag) $index .= ' ' . $tag->title; $page->index = $index; } });

Interesting approach. It deserves further investigation, I think. If I understand it correctly, you propose another set of children – separated from the current set – which is used for layout only perhaps? Reading other's comments, I think most of us do not ask for a "Gutemberg only like" feature, instead, most of us need a way to implement a builder which is similar to the current repeater(matrix) based solutions others have presented in the forum, but geared towards layout + building. Editor.js could simply be another fieldtype, just an alternative to CKEditor. You and/or your client could decide which one to build upon your "RTE editing needs".

Just a quick heads-up that the hook I mentioned is now implemented in the latest release. There's a new method called ProcessChangelogHooks::shouldLogPageEvent() for this, and all the existing checks have been moved there as well: /** * Should we log this Page event? * * @param Page $page * @param Field|null $field * @param string $operation * @return bool */ protected function ___shouldLogPageEvent(Page $page, ?Field $field, $operation) {

@ryan, what follows is only about the idea of taking Repeater Matrix in a Bard-like direction for long-form content, as referred to in my earlier post. I don't have an opinion on the "builder" idea because it's not something I or my clients need. Looking at the Bard video you can imagine it as rich text field (i.e. CKEditor or maybe Editor.js) with Repeater Matrix elements distributed through it. You can add new Matrix items and edit them within the rich text interface. Here's a mockup of what a hypothetical "Repeater Matrix Bard" field might look like: But as far as I can see such an interface would be very difficult to implement. You'd have to somehow replicate the Matrix item interface inside CKEditor or Editor.js, maybe as plugins. [Actually, as soon as I made this mockup I suddenly had another idea for how it could be done, but I'll come back to that at the end of this post]. So when I first started thinking about this idea (back when Bard was introduced to Statamic) I wrote that option off as too difficult and turned to working with the existing CKEditor and Repeater Matrix fieldtypes. Of course this was going to involve compromises and the result was never going to be as slick as the Bard interface. My idea was to use placeholders for the Matrix items within the CKEditor field, in the form of CKEditor widgets. Each widget would correspond to a Matrix item, and a Textformatter module would replace the placeholders with rendered Matrix item output when the page is rendered for the front-end. This is easy to do via $matrix_page->render(). First I experimented with keeping the Matrix field visible in Page Edit, with the Matrix field in accordion mode. Hovering a widget placeholder in CKEditor highlighted the Matrix item (to help the user work out which placeholder is linked to which Matrix item) and clicking the widget scrolled to and opened the Matrix item for editing. But this takes the user away from CKEditor and disrupts the writing experience a bit too much. So then I changed to hiding the Matrix field in Page Edit so the user only sees the CKEditor field. When they add or edit a Matrix item a Magnific modal opens where they can work with the fields within the Matrix item. I added a dropdown to the CKEditor toolbar to let users add new Matrix items/widgets within the CKEditor field. This works okay but it's not fantastic - the main dissatisfaction I have is that my widgets are rather basic. This is because I'm no expert when it comes to CKEditor and its widget system. But looking at example widgets in a tutorial it seems that it's possible for them to have richer layouts and items like images (icons?) within them. I'm using the title attribute tooltip to show the text from the Matrix item header, but it would be great if the widget contained an icon corresponding to each Matrix type (sidenote: we really need a larger selection of icons available in the core) and perhaps some of the item content. Maybe the developer could specify code for each Matrix type that would render the HTML of the widget? I fear this is all beyond me but if you're interested maybe you could explore the possibilities of this? Or see if a similar approach would be more easily accomplished in Editor.js. A screencast of the system in action: Because the user doesn't see the Matrix field it would be possible for items to become orphaned there after their corresponding widgets are deleted from the CKEditor field. But it would be good to keep orphaned items for a short while to serve as disaster recovery. So perhaps orphaned Matrix items would be automatically removed after some period of time. Coming back now to the mockup screenshot and an idea of how to achieve it... What if there was a special rich text Matrix type available to be added to any Matrix field? This would consist of a CKEditor field in inline mode (to reduce the distraction of the toolbar) together with (optional) Files and Images fields to allow for linked files and embedded images (edit: it would be good if somehow a single Files field and a single Images field was shared between all rich text items). This matrix type would render differently within the Repeater Matrix inputfield - it wouldn't have a permanently visible header and the Files and Images fields wouldn't be permanently visible either. Instead a special toolbar would appear when the rich text item was hovered (probably at the bottom to avoid clashing with the CKEditor toolbar). This toolbar would include the standard Matrix icons (sort, copy, toggle, delete) and icons that make the Files and Images fields visible for when those need to be accessed. But when nothing is hovered it would render just as the rich text portions appear in my mockup. It would also be nice if the Matrix "add new" links were replaced by a "+" icon that appears when you hover between existing Matrix items, like in Bard. That would reduce some clutter in the inputfield and allow new items to be inserted in whatever position is wanted. This approach would not be quite as nice as a single rich text field containing Matrix items. Because I think the concept of multiple text fragments is not what users imagine for a long-form article. And it would result in more pages behind the scenes, although that probably isn't a big problem. But it seems like it might be relatively simple solution to the Bard idea.

I know some things I have struggled with in the past is exporting fields from one website to another to jump start a project, and option fields can't be imported in. I have to go to each of, say 20 fields, and manually copy and paste all options in for all of them. When I am working in a page backend in one tab, and have another tab open with the front end to see my changes, I can save the backend tab, and instead of staying where it is at, it shoots me to the top of the page. This isn't great. Would prefer it to stay there so I can tweak, save, tweak, save. Most other backend system I don't even need to hit save as changes I am making are live, but this is a step in the right direction! Also would be nice to have a way to not have to switch back and forth between tabs. Getting live editing would be even better! I even purchased the plugin for this and wasn't a huge fan of it.

Please... just... don't. ? ? https://wordpress.org/plugins/gutenberg/#reviews We've been there 3 years ago with WP. The same discussion, the same requests. The rest is history... or rather anoying present. I've started using PW because of its bare bone flexibility as a backend and text/content editor (not builder!). I don't know too much about all that PW API magic (which I truly admire) and barely scratch the surface, but that's more than enough to build a lighweight customized website with a desired design (here just customized Bootstrap + few js libraries). I don't need and I don't want any builders for that. Clients are extremely happy with very simplified admin dashboards and some of them ran away from Gutenberg and other WP builders last year. I'm perfectly aware that there are different clients, developers, trends and expectations. I just feel (and see) that we're overcomplicating and overbuilding websites (and tools) these years... Just sighing, Guys... All the best to Ryan and the whole PW Community in 2021!

We sort of have this already - take a look at the Custom Links section of the settings for the Processwire Info panel. You can add links to any page on the site, including items under Admin > Setup. Of course this doesn't allow for external links. For external links, I could add an additional settings field for storing these, or we could go with a separate Shortcuts Panel. Semantically it would be strange having external links under the PW Info panel, but maybe that's OK? Any thoughts? I use the Custom PHP code panel for such a thing ? eg.: return ' <a href="/admin/module/edit?name=ProcessPageAdd&collapse_info=1" target="_blank">Disable automatic publishing conf</a><br> <a href="/admin/module/edit?name=ProcessPageEditImageSelect&collapse_info=1" target="_blank">Image handling conf</a><br> <a href="/admin/module/edit?name=ProcessPageEditLink&collapse_info=1" target="_blank">Link generation of InputFields conf</a><br> <a href="/admin/module/edit?name=FieldtypePage&collapse_info=1" target="_blank">Orphaned page references check</a> ';

I'll have to think about it a bit more to be certain, but most likely it isn't a problem. And what's in your screenshot above definitely isn't a problem. If we get into 100s of these kinds of templates then I think that's where I might start to worry and think we have to benchmark and find alternatives... but that's also the point where someone has gone well beyond a simple builder.

Yeah - every block is a separate template (all having a prefix here): No idea how I could measure or tell about the performance impact of such a setup compared to other strategies, but it's nothing noticeable and I thought if that really became a problem I'd simply do some caching...

@flydev ?? Thanks for posting that, I've learned something new about editor.js. My experience with it is mostly limited to their own demo, so I'm really just looking at it from an outsider perspective. The tool is more powerful than it looks at first. I was particularly impressed with your integration of ProcessPageEditImageSelect. Nice work. It looks like you are pretty far along with this module and it also looks like it will be a great tool for PW users. When do you think you'll be releasing it? Interesting, what you mean exactly ? From what I can tell, editor.js is one big input element, kind of like a rich text editor, even if it also isn't. I think this is also compelling, and what makes one draw comparisons to CKEditor. So editor.js could be represented by a PW Inputfield, but it couldn't itself contain other PW Inputfields (as far as I understand it). Whereas something like a Repeater is an Inputfield that contains other Inputfields. If a block in a builder can be represented by a group of Inputfields, then that means that the types of blocks you can build can be very flexible and modular. The benefit being that it expands the means by which you can extend it. On the flip side, it also means that it's not something you'd ever compare to an RTE because it's just completely different. Editor.js seems to find a nice middle ground between RTE and block builder. It does appear that every block type is defined by a PHP class, but I'm not sure if that also corresponds to a template (?). Templates are a resource best limited to not use any more than necessary (since they all have to be loaded on every request), which is why RepeaterMatrix limits itself to 1. Though maybe something like block types aren't huge quantities, I don't really know. Such a solution would need to come with several predefined block types, just as editor.js does. I think this builder focus is important, otherwise it's becomes too abstract, at which point something like editor.js with plugins becomes a clearer answer. So I'm hoping that people could get up and running by selecting existing block types rather than having to always create them. Then they can create them when-and-if they need too. When it comes to code definition, it comes with its own benefits, and I think it's fine so long as the built-in defaults/types are strong enough to answer the most common needs. Getting into this level of stuff is where the RepeaterMatrix upgrades should help. But this level of complexity I think would hinder a simple builder for the larger audience. For this particular project, I think it's best if it focuses exclusively on content tools and doesn't get into layout and style aspects. This is one of the things Jonathan and I talked about. I'm investigating options for alternate storage methods of repeater items, such as the ability to save all the content JSON encoded in the 'data' column of the repeater table (rather than saving in separate pages). It would be an option you can choose in the field settings. I'm going to try and make it happen though it's possible I may hit a roadblock, so will have to get further along before I know for sure. I think editor.js is also an answer to what many people are looking for, so we have to be careful not to lose sight of what it does well. While there are things to learn from it, I agree it probably doesn't answer quite enough of what we are looking for. Good ideas. Improvements to RepeaterMatrix are part of the plan. But that's going to be a separate project. The $page->meta() method exists for this purpose, at least from the API side. Though the values are still stored in the DB, but not as field data, just as flexible unstructured data stored for each page. The Combo field might offer potential here too, as you can bundle as many inputs as you want within a single Combo field. Though it's still technically stored in field data, and still as searchable as any other field data. But without the being a separate dedicated field and having a separate DB table for each component, etc.

Hey, My 2 cents on the page layout / builder : about editor.js, I see it more as a nice-looking alternative to CKEditor than something genuinely different in what it offers (apart from for the structured data) and it seems a bit limited to be a page builder more than what is already available to us. And I agree with your pros & cons @ryan. But I do think that adding some improvements to the RepeaterMatrix module, which we all seem to use as a "page builder", is a good way to go. As much as I don't want my clients to have too much freedom when it comes to the layout, I think there could be a way to introduce a "layout abstraction" into RM, something simple and limited, but that could give more flexibility. In a (distant?) way, it would be like giving the user the ability we have, as admins, to define fields' width or group them in a fieldset. I drafted some screenshots to show what I had in mind, that could be "user-friendly" (close to what @Jonathan Lahijani showed in his video). The idea would be to have "layouts" which would be described just like RM items but instead contain abstract "containers". Just like you would with fields, you could change the width of said containers, and make sure they add up to 100%. Then in the page editor where your RM is, you would have the possibility to either add a "layout" or an item. A layout and its containers would reflect the way we described them in the settings, re: width. To show that the layout is something different, we could use the secondary color. And this could be how we translate that into (hopefully not with repeating parts like mine) code: <?php foreach($page->test_matrix as $item) { if($item->type == 'matrix_layout') { // reserved type name if($item->layoutType == 'two-columns') { echo '<div class="grid">'; foreach($item->subItems as $subItem) { echo '<div class="column-1-2">'; if($subItem->type == 'type_text') { echo $subItem->text; } else if($item->type == 'type_image') { echo $subItem->image->render(); } echo '</div>'; } echo '</div>'; } } else if($item->type == 'type_text') { echo $item->text; } else if($item->type == 'type_image') { echo $item->image->render(); } } A few notes : Don't be fooled by my screenshots, I just messed around with Firefox's dev tools. To keep things simpler a layout should not contain another layout. The page editor may become too dense, even unpractical, if there is too much containers. Maybe a toggle on a container to expand it along the horizontal axis could be a solution ? End of my 2 cents. (also : I like how @bernhard is removing the field's label to gain space and I think it could be nice to have such option in the core, like "☑️ Do not display the field's label". Of course it would then remove the ability to collapse the field, but it would be a conscious choice. Edit : this is especially useful in context where you use RM and have 1-field types, like I used in my example above)

Yes, something like this. Thanks.

@Zeka Currently you can create a class like BlogPostPage and it automatically be used as the class for all pages using template "blog-post". You mentioned the PagesType class, which is used by things like Users ($users), Roles ($roles), Languages ($languages), etc. as an alternative to the $pages API var. To make sure I understand what you mean, are you saying that you'd like to be able to create a class like this: class BlogPostPages extends PagesType {} And then you'd get this API var ($blogPostPages) that limits itself to pages using template "blog-post": $posts = $blogPostPages->find("date>last year, sort=date"); Is that what you mean, or something different?

Exactly what I'm working on, so I'm happy to share my knowledge (code) if there is interest! It seems that interest is there since 2015... https://processwire.com/talk/topic/9494-wire shell-an-extendable-processwire-command-line-interface/ Installation and usage are simple: Installation cd /to/your/project/root/folder # clone rockshell into the "rock" folder git clone git@github.com:baumrock/RockShell.git rock cd rock composer install cd ../ Usage # in your projects root folder # this will list all available commands php rock/shell ---- RockShell will then live in a separate folder "rock" beside "site" and "wire", so everything stays clean. Also it can run without processwire, which is necessary for installation (of course) but might also be helpful in case of anything pw related does not work (500 error due to wrong config or the like). That's why I'd be very interested in using WireFileTools etc. without a running pw instance. I'd be happy to get some hints how that can be done...

? ? ? ???? ?? ????????? ?‍♂️?‍♂️??‍♂️?‍♂️?‍♂️?‍♂️

I'm not sure I understand what you mean. We've got templates which define a Page's type in terms of fields, behavior and access. Then we've got custom Page classes which define a Page's type in terms of its API, which can also extend other Page classes. Then we've got Page tree/hierarchy/parents, which define their type in terms of location. I'm not sure what's left. ? Is there some other kind of page type you are talking about? I will update the AdminThemeUikit repo. Unfortunately I've run into some npm error where it wants to do some kind of updates before it will update the UIkit version, but updates it wants to do in npm fail. This seems to happen every time I want to update something that uses npm, but I always eventually find a way around it. This last one has had me stuck for awhile though. I'll revisit it here soon. I've never liked these command line package installers/managers because they always seem to have some problem without a clear answer. I guess it's the nature of the beast. In this case, you've modified the core _masthead.php. Don't do that. ? The intention is that an admin theme would provide its own _masthead.php file (or whatever you decide to name it). Actually I was thinking admin themes would replace all of the markup files. That's in part why they are all split out on their own. The updates added to AdminThemeUikit last week make it so that you no longer have to provide your own markup files if you don't want to, but for your case where you are changing method calls and include statements in those markup files, you'll no doubt want to have your own markup files. This gets into more overhead than I'd want to be involved for rendering the admin theme... at least for the core default one (AdminThemeUikit). I've even tried to actively avoid the traditional type of hooks here, so that the admin theme itself doesn't add its own overhead to the request. There's nothing faster than include() of a php file to render something, so that's the strategy AdminThemeUikit takes. Admin themes use a different kind of hooks for adding markup in parts of an admin theme, and they actually aren't really hooks at all, even though I still think of them as being a type of hook. You can call $adminTheme->addExtraMarkup($name, $value); to add extra markup to various parts of the admin theme. Any module or admin template code can do this any time during the request, up until the admin theme gets rendered (at the end of the request). The $value is the markup you want to add, and the $name is a region name where any one of the following are currently recognized: "head" - adds markup before </head> "masthead" - adds markup in the div#pw-mastheads "notices" - adds markup after the notices/notifications "content" - adds markup in div#pw-content-body "sidebar" - adds markup in #pw-sidebar, only if theme uses a sidebar "body" - adds markup before </body> "footer" - adds markup in footer#pw-footer This is the strategy that the admin themes use to support other modules in adding markup where necessary to the admin theme output. This is faster and simpler than using a traditional hook. More region names can be added easily if/when we need more. If developing your own admin theme, then you don't need hooks or the addExtraMarkup() function because you can already override anything in the AdminTheme you are extending, you can provide your markup files as needed, and add your own methods as needed. Admin themes should still support markup added with addExtraMarkup() though, but it's easy, just $adminTheme->renderExtraMarkup($name); at the appropriate spots in your admin theme template files. If there's anything I can add to make it easier for people to have a dashboard page, I'm happy to. But I don't currently think it should be built into the core. The core doesn't have anything worthwhile to communicate to admin users in a dashboard, so it would just be extraneous fluff (i.e. "numbers", "more numbers", and "numbers again"), like it seems to be in most systems. The kind of stuff that makes a simple system look complicated. Others may have something specific they want to communicate to their logged in users, and that's where I think it becomes worthwhile. If there's demand for it, I'd be more interested in hearing not about a dashboard, but about what one is wanting to communicate with it. Thank you for continuing to develop this. I agree there are benefits. This may be something we should keep talking about for the longer term. With the exception of WireMail, all the classes you mentioned are intended to be available for standalone use. Though it's been a long time since I've used any of PW's classes in that way. This I think is likely an easily attainable thing to support though. Most of the mentioned classes just extend the Wire class, making it the only dependency (and Wire doesn't require a DB connection). A DB connection would be needed for WireMail because it is a module type. Installed modules are known from the database modules table. A WireMail module also maintains its settings in the database. Now is is true that the base WireMail class can operate without a database, but WireMail is only useful because it is a module type. Take out the module aspect and WireMail is just an interface to PHP's mail(). The core datetime field is meant to store a single date/time, but that's it. I agree that sometimes a need arises for more than a single date/time. ProcessWire core is meant to focus on the basics, while supporting modules to accommodate a broader set of needs when they occur. I think this is a good example of a need that is nicely accommodated by a module that you've developed. Thanks for sharing the strategy you are using here. It's great to see the different solutions people are working with these last couple of weeks. From the screenshots I really like the approach you are using here. It looks powerful while easy to understand and client friendly. Yet also looks very PW familiar as well. Visually it might be the clearest I've seen, even relative to something like The Bard. The means of definition does also look simple, though I think for something that other developers would use, they might prefer that the front-end rendering be isolated from the back-end component. Something that makes it easier for you to provide pre-written components, while they provide the front-end markup. For instance, maybe the render() method delegates to a front-end template file somewhere in a subdirectory off /site/templates/fields/? And if there is not file, then maybe it provides a default output. The reason repeaters store their pages off in the admin structure is to solve these things. But it does come with its own challenges as well. Most likely I wouldn't be able to make any more commits to the core if I got run over by a train. I've always thought this was one of the reasons to use open source, ensuring that when someone smacks the tracks, the code doesn't. But it's not just about being open source, the code also has to be clean and well documented so that others can easily take it on board. That's one reason why I put so much effort into code quality and code documentation. My intention is that the code is always ready for others to understand and work with. As for commercial services/modules, it's the same risk inherent with any product or service you pay for. While not open source, the Pro modules do have the same code quality and documentation as the core, and are not obfuscated or encrypted. If it sets your mind at ease, I'm 46 years old (not 76), and am very healthy. I run and lift every day, eat lots of salads, don't eat red meat, and don't participate in any dangerous activities. Most likely I'll be here for at least another 46 years. But if I'm ever derailed then I know the project would still be in good hands. Seems like it might be simple to do. Can you expand on this? When/where would you use it?

It seems like we gonna have a fascinating year! I am enjoying being here since 2014, but feels like the most interesting part is just starting!

That's it. I just don't want to let my clients have the freedom to play with styles, at least not within boundaries I can manage by code. It would be such a pain if I have (as accountable/developer of the project) to fix the mess made by a client inside the editor. Moreover, from my experience, if I give a client some sort of freedom (especially inside the creative side of things) then he will ask me more and more (Can I do this? Can you add this for me?). The editor become their toy, and the front-end the crappiest as ever. On the flip side of the coin I would really love if we, as developers, could have the ability to let editors manage our pre-made components in a more compelling/modern visual way.

"Is there demand for that?" -- I would say this is a resounding yes. There are dozens of page builders out there, and many tied to WordPress: https://blog.hubspot.com/service/wordpress-page-builder Block Editor (Gutenberg) is more of an advanced version of TinyMCE/CKEditor, but it's quickly becoming more of a "page builder" in the next year or two.

In this video, I demonstrate YOOtheme Pro's Builder (WordPress) and talk about its approach and benefits. I then demonstrate 3 different builder concepts in ProcessWire using Repeater/RepeaterMatrix, two of which are modeled after YOOtheme Pro's builder and their limitations along with some suggestions. ( @ryan ) (note: there are many more considerations when it comes to a page builder, but if there were some sort of css-framework agnostic layout tool, that would solve the biggest page builder problem) Please share your thoughts.

Hey @kongondo I think the question was a page select field for products, eg featured products on homepage.

Hi @joer80 In the top of the post.php file, you can write your logic to check which user is allowed to post or not xhr request. Example : <?php namespace ProcessWire; // if the page is viewed wihtout ajax, return if(!$config->ajax) return; // if the user is a superuser, return if($user->isSuperuser()) return; // only editor can post request to this page if(!$user->hasRole('editor')) return; // other checks if needed, CORS check, Custom header check, etc // rest of code - access granted // ... then, for example in your component , but anyway you already know how to do it : // example editPage() { this.$store.dispatch('setEditPage', this.$route.path).then(() => { axios .post(config.apiEditPageURL) .then(response => { this.data = response.data }) .catch(error => { this.errored = error }) .finally(() => { this.$store.dispatch('loading', false) }) }) },

I prefer to change the pagination style on _init.php, or _func.php, for instance, to use Tailwind classes, using Ryan's modified example: