Ivan Gretsky

Hi, @esspea! I might be that the install.php script does not get deleted (due to file permissions issues probably). If so delete this file manually.

@adrian, @teppo, thanks to both of you. I think I spotted the problem. There is the Page Edit Per User module installed on the same project that causes errors in some cases. I manages to get Admin Restrict Branch Select to work. But I now face another less mysterious problem with frontend editing. It is available only for the branch that is currently selected. So when I switch from Branch A to Branch B in admin, Branch A is no longer editable on the frontend. It must be the way the module is intended to work. But is there a way to make the Page List in admin show only the currently selected branch, but keep the edit permissions to all of the selected branches? I think that even seems to be more expected from the user point of view, so maybe a might be a good improvement for the module)))

Thanks for the tips, @adrian! My setting is User Specified Branch Parent, as it is on your screenshot. I am visiting /admin/page/. Didn't know I could even link to a specific branch via URL. I did everything to clear the cache if that could affect it somehow, but with no luck. Still getting this error.

Thanks, the module now installs from the directory as it should. But I must be missing something while configuring it. I assign two branches to a user, then login and get this error: AdminRestrictBranch: You don't have permission to view this branch of the page tree. I was thinking that the module will redirect the user after login to a branch he has access to. But this doesn't happen. Could you please suggest am I missing or misconfiguring something?

Good day, @teppo! I am having trouble installing the module from the modules directory. I am getting this error: ProcessModuleInstall: File could not be downloaded (https://github.com/teppokoivula/AdminRestrictBranchSelect/archive/master.zip) 404 Not Found: (tried: curl) Could you please check, if the download URL is correct.

Good day and once again thanks for the great module! Is it possible to use ckeditor as an inputfield for text? I am trying to create a readmore hannacode and need to provide a rich text input for the content to be only partly shown.

This module is exactly what I need on a current project. And did need on a number in the past, but had to cope without. Thanks, Teppo!

Sorry to ressurect this old topic. But I've got the same problem. For now I am fine going to Setup -> Sessions as @horst suggested in his original post. But it doesn't seem to work. I visit this page, but sessions do not get deleted (as I can see in PhpMyAdmin). There is no button to clear old sessions either. Is it some bug on my side, or the sessions are not supposed to get deleted in this case?

Good day, @ryan! I'm in! As for now I always used Repeater Matrix for content builders as @Jonathan Lahijani, my first approach would be to develop additional features on that side first. So lots of us already using this pro module could do it even better. I started a topic in Repeater Matrix forum to gather wishes you could help us with. Everyone else interested, please contribute!

Great! There are a couple of other superusers and a bunch of users with different permissions on the site. I am trying to make sure nobody will have a chance to ruin it (but myself))) I set these permissions: Enable Tracy Debuffer - true; Output mode - Development; Force superusers into DEVELOPMENT mode - true. Is this good enough? How can I hide Tracy from other superusers?

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.