Ivan Gretsky

The great thing about Repeater Matrix way, is that a dev can create his own Builder (be it layout, content or full page builder). A content type can represent a section with all predefined components, just a section, or a column in a grid. And it is the dev who decides how it is rendered for the frontend. It would be great if we wouldn't drop that customization part. Some of the content types I build contain not just the simple markup like buttons, text and headers, but link to other ProcessWire content. Like a Page Reference field to define selected products to output. Or a selector field for that purpose. It is not shown in @Jonathan Lahijani's video, so adding this point. Some "components" of mine are just a content type without any fields attached to customize - like a "calculator" content type. The whole page here, for example, between the header and a footer is a single Pepeater Matrix field. As for me, the WHATEVER-builder field should be in fact а framework for constructing: a content builder (just the content that goes into <main> tag, like the bard field or this editor.js based field) or a whole page builder (like the YOOtheme builder example). Leaving the dev to construct all the possible types, their possible children/parents, the way they are displayed in admin and rendered on the frontend. Plus the way to easily reuse stuff within a site or on a different project. Sounds like an impossible task, but a lot of us here already done that mixing Repeater Matrix (or a couple of those) and Mystique (for adjusting little things like headline tag or margin/padding, that does not deserve their own regular fields). The thing that's missing is the js polish on top of that and handling of edge cases. And I am not too much pro leaving the repeater pages as storage (it really hurts the reusability part). I am for the presence of the ability of customization that it gives to Repeater Matrix as it is now.

Not so sure) IMHO, anything beyond the basics would require an SPA with webpack build. Vue (or Alpine as it's stripped down alternative) would not solve the problems we got if not used at full scale. But something like Hotwire can.

Wow! That is the best explanation possible! My thought on making the whole layout thing happen on top of RepeaterMatrix field, is using the second approach with levels, but allowing the matrix types to define allowed children. So you can only put a grid under a section, a col under a grid and a component under a col. All that should be definable in the field config. Other important thing to consider are: being able to easily move content types between fields/projects; being able to define which components are available on which template (in case we do not want top duplicate the fields; it kind of works with Matrix overrides, but is not so easy to customize); being able to copy the whole sections from page to page (kind of like this). We should not abandon the idea of not basing on Repeater Matrix though, if it removes its restrictions.

Just in case we really go that route with dynamic admin pages there is a way NOT to use a reactive JS still achieving similar results, staying in the realm of a server-generated html and avoiding complex build workflows. There is a mature Unpoly library and a new Hotwire stuff from Basecamp themselves. Using those might be an alternative, which would not require such massive changes, as switching to Vue or React (do not think Alpine is enough here)) Hotwire would be a great couple to ProcessWire due to it's name only))

I see there is a number of topics that are actively discussed in this thread. Maybe we could make a subforum with the selected 2021 roadmap features to be discussed with dedicated working groups? Not to loose the momentum we got here in this thread) And to nurture that community participation in the future of our beloved ProcessWire. I see these: A strategy/fieldtype for creating rich content. Making admin themes be extendable and/or adding features to them like a sidebar (might be it could be accomplished as an extension?) External API / using PW as a headless system out of the box. Central media/image manager for reusing images across pages Support for different file storages for image like Flysystem Growing popularity of PW (without sacrificing stability of course). Showing github contributions and such. Implementing admin forms in the frontend / making a limited admin for non superusers (pushing this as I am personally interested)) ...seven is a great number to deal with, but certainly there could be more)))

Regarding the ability to modify the admin theme... Look at Admin Theme Boss (the only custom admin theme I have ever seen used for PW3) thread, and at this particular post to start with. @Noel Bossis probably the man to talk about making extending Admin Theme Uikit a better experience. As well as @bernhardwith his RockSkinUikit and @tpr, who knows the admin inside out making his AdminOnSteroids. And @Robin S is already here, of course)

Happy new year and best wishes to you @ryan, and everybody here in PW community! Thanks for asking about user opinion on the features for the roadmap! There is a rather old poll on weekly.pw on the same topic. Some features from that poll are already implemented, and it is really cool! But some are still waiting to find their way into reality. My personal favorite is: Strategy for flexible content types in a template (https://processwire.com/talk/topic/7477-strategy-for-flexible-content-types-in-a-template/) (7.3%, 10) Additional wish from my side is the ability to build custom admins for non-superusers. One way I once tried to imagine it is this. There are a number of related features in the mentioned poll as well.

С Рождеством!

Was looking for this too) I guess this is it. Hope it will help someone as this topic is #1 result for the search "textformatter toc". Found the link with some nice extra content here.

I wouldn't ask to maintain multiple APIs. Just feel that making a link to Microsoft's github repo a required field is a bad decision. Like making github auth the default method for site authentication, not allowing email. What would happen to https://processwire.com/modules/pad-loper/ and alike, that cannot provide a github link? I would suggest making github a single option for automation, leaving plain textarea for description and url for project link a general option. That would probably suit everyone, making possible both code hosting platforms of choice and paid modules listing.

Great news! The thing that bugs me though is making github account mandatory. Feels kind of like proprietary vendor lock in. Shouldn't there be an option to use gitlab/bitbucket/own git or a custom download url on an own site?

Good day, @teppo! Thanks for this timesaver module of yours! Really cool! The topic is getting long. Sorry if I missed the answer scanning through. Is it possible to search by page id? Probably that means adding it to the indexable field, right? Maybe there is a hook for that?

Good day, @kongondo! I can see some great features (like extra_fields option) on a dev branch (added in version 0.2.7). Is there a reason for not releasing it yet for everyone to enjoy on a master branch, which is being installed by default?

So true! And I can't believe it is not in the modules directory yet))) Hope that Adrian will find time for it eventually. This module deserves its place in the top rankings (if not in the core).

You got to use $input->whitelist.

Hey, @jds43! You should be able to just add 'baseUrl' => '', to the options array above.

Just recently @ryan presented a little module for making batch user role assignment with lister easier. You can already batch send emails to users from lister. I am not sure we can expect such a module to be developed quickly, so would suggest adding functionality to lister with action modules. But you can probably hire Ryan to build this module (or some of its parts) if that is affordable.

Good day! I am putting @adrian's TracDebugger's bd() in a Hanna Code and it seem to be running 3 times while rendering only one Hanna code item. Why is that?

I've solved the issue. The problem was that I was hooking the wrong method. I've adopted the code from this post and everything started working properly.

One way would be to give them labels sorted in alphabetical order. Something like: 01 - Most used template (a label for most_used_template) 02 - Not so much used template (a label for not_so_much_used_template)

CKEditor 5 is a completely different kind of editor. It doesn't store the entered text/markup as is, but rather transforms it to it's in built data model. The transition to it would probably be pretty complicated if possible. Things like text formatters, image plugin and a lot of textarea-related stuff would probably have to be redesigned. So do not think it is going to happen soon (but Ryan can surprise us like he did a million times)))

1. Change this AOS module setting as you wish: 2. Add templates definitions to that file (as described here or here).

You can try CKEditor content templates. I think you can get it into your system with AOS module.

Sounds like a minor thing in the end just to finish the post, unless it's your issue, your site falls apart without it being solved) Thanks!

Those functions are needed in _main.php to render correctly. I think there must be some better solution. If I run $page->render() in the same hook, it works fine. Though it obviously also load both _init.php and _main.php on the way.