Ivan Gretsky

Good day! I discovered the Tracy Debugger console not so long ago and now trying to make the best use of it. It is quick and easy to run simple maintenance scripts in it (of course, I do all the debugging on localhost first). But how save is it? And how to make it as safe as possible? What would be my settings on the production server for this case?

Just found this topic while creating another one in the FormBuilder support subforum. If you like the requies, please give it a thumb-up on github.

Good day, @teppo! There is a rather empty Patterns and practices section in the docs. I got a suggestion for what to put there. Or should it be in examples? Anyway... Could you describe how does the template with a controller handle get variables and/or url segments? I do not quite understand that, as I have no prior experience with general purpose frameworks.

It seems not to work when not on https. Must be a youtube restriction. Maybe it is your case too?

This is a great topic! I would love to learn more about the features of Tracy Debugger. I did start to read the docs a few times, but never had time to proceed)) As for me, I actually do not have a lot to share, as I only seem to use: the great bd() and the dumps recorder, and the bluescreen (you can't avoid that, but it is really helpful anyway), and the console once in a while to test selectors or something minor like that, and the donate button every time I install TracyDebugger on a site, ...but nothing more advanced, really. Would love to learn new tricks though)

I like @bernhard's approach where every content block has it's own template (if I am getting it right). I also wrote that "Repeater Matrix should be PageTable Matrix" back in 2018 (though I never did try to fix that as @bernhard ?) This way you can easily move content-type-templates between projects. Though I am not that sure that on-code-only solution he proposes for quickly creating/duplicating/moving those templates would suit most of the users. A decent UI for that should be in admin too with the ability to be extended with hooks, but that is built-in anyway; RepeaterMatrix got it right with the ability to create types on the fly, but that at a cost of putting all the fields in the same template). There are other points not covered, like nesting, defining parent/child relations (for creating blocks with nested elements, like wrapping a header, a text and a calculator with some custom background like here), crafting a grid for column design (we can get around by creating a lot of custom sections, but would be great to do it more easy), copy-pasting content from one page to the other. I am not sure this can be done easily, @ryan but can we at least have another look at "The data storage" part of my previous post. If implemented, it could solve a lot of problems, making our builder a lot like editor.js while reusing a lot of goodness ProcessWire already has. If it is not possible at all I think that @bernhard's way is great (with UI improvements, some of which can be borrowed from RepeaterMatrix). Any way, editor.js or alike do not seem to me a solution to problems we are talking about. Let's just watch at @Jonathan Lahijani's video, the Bard field video again) Editor.js could be a one field inside of some blocks of our builder though.

@ryan is it possible that the community funds the development of the content builder? Can you think of a number we can set and try to collect? We can at least try this model)

I need a cli installer for setting up new ProcessWire sites with all the little tweaks I am doing every time quick and easy. For now I maintain my own ProcessWire profile, and use it during the installation process. But maintaining and especially source controlling a profile is hard. I would like to have a script to set up a new installation doing all my tweaks. The script should: Install PW with a Blank Profile. Install RockMigrations. Downloads a migration (a setup script) from git hosting platform and run it. To develop all this and particularly to test it I really need an automated way to install PW, getting all install options from cli arguments and/or from a config file. I guess the cli installation will be great for any testing tasks and CI.

A proper CLI installer is my dream)

Hi, @bernhard! The most important part for me is being able to install PW from the cli (maybe from a shell script) to automate the initial and subsequent configuration testing (implemented with RockMigrations, of course)) So basically the same need as you tried to solve with the kickstart.

Just maybe deleting the modules cache could help?

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!

First of all I want to say, that I am really enjoying the discussion about the flexible content builder or the WHATEVER-builder (as I accidentally named it earlier) we are having here. And now I am purposely not calling it more specifically Site / Content / Page / Layout / Theme Builder. I think that @kongondo made a really wise question asking to define the distinction between those. And to determine, what exactly do we want to build. Are we really talking about the different things? It seems to me that now we are contrasting the YOOtheme Builder from @Jonathan Lahijani‘s epic video labeling it as a layout editor or a site builder, to bard / editor.js calling them content block editor or something like that. And choosing between the two. But, as I understand, @Jonathan Lahijani never proposed a layout editor / site builder way in a sense that it should store the final html code and let the content editor to directly manipulate it. He intentionally made it clear, that he chose to show us YOOtheme builder because it “separates the builder-part from the actual content” doing it in a “ProcessWire way”. And he also stated, that he is not for tightly coupling to the CSS framework (Uikit in YOOtheme). But he would want the ability to define the layout IN SOME WAY, like being able to create a 2/3/4 column grid and place the components (I think that they are the same as content blocks from bard / editor.js) inside those columns. And to be able to move those components to desired slot in the layout. I would really want that part too) I think that the earlier mentioned “ProcessWire way” is actually the separation of content and presentation. When we use Repeater Matrix, we store the content and some meta information not directly in the html code, but in the Repeater Matrix Page’s fields. Actually, editor.js (do not know about the bard field, but probably that one too) is also storing the content separately from the presentation. Not in the separate database tables, but in one json object. So it is kind of doing it the “ProcessWire” way too))) One difference, is that in the case of editor.js we have to manually deal with json when generating actual markup, when Repeater Matrix provides us the comfortable PW API for that (making this way a little bit more ProcessWire). The other difference is that when using Repeater Matrix we have to manually create all the actual fields and assign them to content types, making this way more laborious. The coin has two sides. So, as I can tell, we all want the same kind of editor. The one that does not store the actual markup, but the one that stores data, that later we can render to actual html (or any other format really). What about the layout part? As I said earlier, I would really want to have the ability to define layout with the flexible content builder we are talking about. @Jonathan Lahijani showed 3 ways of doing it in current Repeater Matrix-based content builder, and all of them are kind of a pain. But I do not want our editor to actually store something like col-sm-6, but rather some generic layout information. Like having a grid block, that can only have col block as a child, which in it’s turn can store the actual components. In Repeater Matrix now we do not have a distinction between layout element and a component. We only have the ability to put one element inside the other (the ugly nested Repeater Matrix way or the repeater depth way which also has its flaws). But it is the developer who is responsible to make all the decisions generating markup. So the developer could choose to implement the layout part or not to do so, which is really a powerful stuff I enjoy and would like to keep. That’s why I was talking about the “WHATEVER-builder” or a “framework for constructing a content builder” before. To do so, our new flexible content builder should allow us to: define the allowed parents/children for the elements; allow to show the child elements side by side (to imitate layout); intelligently control the drag and drop, taking into account the allowed parents/children for the elements. As far as I know, editor.js does not allow the nesting of the elements. Creating custom elements from admin The other great thing about the Repeater Matrix-based content builders is that we can easily create new custom content types (elements, components…) right in the comfort of the admin. It is not really a quick thing, as we need to deal with creating the fields and assigning them, but it is rather familiar. And those custom components can use all the other ProcessWire data with Page Reference fields, Selector fields etc, which is cool. If we go with with editor.js, I am in real doubt we would be able to create the new elements in admin. The dev would probably need to develop a js plugin and install it in non-PW-standard way, making it unlikely to happen. The connection to other Processwire content from that custom element would be even harder to implement. Visual representation of the content Repeater Matrix-based flexible content builders in the mentioned video look nothing like the actual content. The left part of YOOtheme builder does neither, but it at least represent the layout in some way. Editor.js / bard do not do that too. From the other replies in this thread I see, that it is not that important and even not desirable. Repeater Matrix interface is kind of ugly, when representing content. But: at least is is familiar and in line with all the other backend; it could be improved to be more like YOOtheme builder: add icons for adding content types, remove or refactor the repeater elements “chrome”, allow showing repeater elements side by side for the layout thing; and it uses the standard admin form ui, which means it is easier for @ryan to deal with. As you see, I am for the native ProcessWire UI here) And one more thing. In the video we see the actual markup rendered to the right of the YOOtheme content editor. We can do that also, creatively reloading THE WHOLE PAGE on changes with Hotwire / Unpoly / Vue. Making the flexible content builder feel dynamic and not requiring those saves-and-reloads. And making the connections between the options in the builder part and the final markup obvious to the editor. The data storage Repeater Matrix-based flexible content builders store the data in pages and fields. This makes it laborious to create new content types (create a new field, or find an existing one to reuse it, assign it, override it…) This also makes it hard to duplicate, copy/paste content in the site or between the projects. But it also allows us to use the familiar API when generating markup. Editor.js’ data object is compact and probably easier to be reused. But it lacks connection to other PW data. And the UI is totally different. Could we combine the benefits of the two? What if we invent the json-based storage for the data gathered with regular ProcessWire inputfields? Something like Mystique field combined with JsonNativeField (so the content is even searchable). And what if we allow to create the Interface for the new flexible content builders components with “fake” fields, which have their inputfields only, and are not connected to the database? Kind of like fields for the Form Builder or the UI for the @adrian’s Admin Actions’ actions. Think about that. We could design elements with any fields we need not messing up the regular fields namespace. Those fields’ definitions would be stored in our flexible content builder’s options, as well as all the content types (elements) and the actual field data in json. The UI would be the same inputfields we already have. When working with this field from the API, the field could be accessible as a PageArray object where each Page is a corresponding element. Bringing it all together I think it is possible to build the flexible content builder (or the WHATEVER-builder) using a lot of the technology we already have in PW. It can be comparable if not better than all the other competition. It can be well integrated and totally configurable through the admin. It can be portable between templates and projects. And it can be visual and responsive. What do you think?

@bernhard, are those two publicly available? Could not find them nowhere)

I am thinking about it in the context of the page/content builder we're talking about here. Something like Hotwire (or Unpoly, or Vue if we go there) would simplify making it work slicker, without the reloads of the Repeater Matrix and with dynamic previews like in the YOOtheme example. So not the whole admin is the SPA, but just the edit page.

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.