Leaderboard

Wow its funny you added this... I created something just a few months ago using CSS to achieve this... wish I'd waited! Mine...

@ryan I'm not sure how ACF Extended is doing previews, but let's just assume it's rendering frontend code in the backend (iframe). The specific matrix-item previews would have to be from frontend code (so as a result, inside an iframe) so it utilizes the frontend css and js. I experimented with a concept a couple years ago (go to around 2:48 in this video -- notice the preview iframe changing there as the dropdown changes). With that being said, when switching from editor mode to preview mode, it would have to save the content in the repeater item so that the preview shows the up-to-date data. Perhaps this could benefit from the new snapshots feature that you've been developing separately? Regarding your concern about it being a lot of developer work, I think leaving the intricacies up to the developer is fine as long as ProcessWire provides some basic guidelines and makes it easy to pipe it all together. Because page builders can get ridiculously complex (I've gone DEEP down this rabbit-hole) and ProcessWire doesn't force a specific frontend approach (good), I believe providing the minimal foundation for letting developers decide how they want to go about it is the best approach. There are a lot of developers on here trying to twist RepeaterMatrix to work a certain way, but with a few more adjustments I believe it will be in a perfect spot. To recap the last few years of "page building" with regards to ProcessWire, here's what really drove it forward: the Repeater Matrix fieldtype nesting repeaters inside repeaters repeater depth family friendly option (being able to drag a "parent" item and it takes the children with it) Mystique fieldtype (for being able to define option type fields that don't warrant the use of "real" ProcessWire fields since it would get unwieldy -- I love this module) new methods by which a matrix-type can be chosen (developed this week) repeater lazy parents (developed this week; big efficiency gains) --> matrix-type previews (or some sort of preview system) ? ? ? THE END. ? There is a client of mine where one of the editors (a marketing person with a good eye for design) has been using my advanced RepeaterMatrix setup with great success. The pages he's created are outstanding and he doesn't require any of my help (I'll demo this later this year). While the page building experience won't match an "inline" type page builder (WP Block Editor and the million other ones out there), I've found that this approach is "good enough" and the pages made will be very consistent.

@Jonathan Lahijani Thanks, yes your description explains it perfectly. I understand how it works now. Where does one define the preview view? The preview seems like it is prepared for the admin, and presumably is something different than what appears on the front-end. If that's the case, this approach would also work for Repeater Matrix (like with custom preview render files like I mentioned in my previous message). It seems like a lot of work for a developer to set up, but if it's what sometime wants then maybe they don't mind. How does ACF work in this respect? It looks to me like developer-defined admin previews, but I don't know for sure. Then there's the potential where the preview is the literal front-end view of the element (and surrounding document), like you guys mentioned. Since front-end output in PW is entirely up to the developer, I'm not sure how much Repeater Matrix can do here. This would be more of a separate "live preview" option for the entire page rather than something specific to repeaters. PW just renders the whole page, though maybe the developer can implement their own method to selectively render one component or another (alongside the mentioned htmx), but that might be asking a lot of the site developer to implement it. This also requires that the preview be in a separate window or frame, since the full document has to be rendered, at least initially. A tool like htmx is cool and might save time relative to jQuery'ing it. But like ProDrafts preview, the underlying issue of having to render the full document remains. Htmx does have the hx-select to facilitate this, which would likely be better than the homegrown method ProDrafts uses for inline replacement. Though ProDrafts inline replacement at least doesn't require one to code for it, but I'm guessing htmx is more consistent/reliable across a much broader diversity of situations.

Yea, preview can be done either in the ProDrafts Live Preview way, or the ACF Extended way. I haven't given it much thought but with the ACF Extended way, you save a lot of horizontal space in the page editor, which is especially important if you have a lot of configuration options for each matrix-type. With the ProDrafts Live Preview way, it gets squished (although resizable). ProDraft's Live Preview way does however provide a more realistic (not chopped up) live preview. Pros and cons. Would be nice if everyone had an ultrawide monitor. ? HTMX is freaking awesome and I'm currently using it heavily on a site for filtering and such. It's made me 100x more productive for the repetitive fancy JS type things while still being able to use regular HTML (no JSON and brittle SPA nonsense). If that could be leveraged in some way it would save a lot of headache, although Ryan seems very comfortable with jQuery. @ryan I think looking into HTMX is worthwhile. It's going to stay around for a long time if I were to make a prediction.

I was too, but @Jonathan Lahijani's explanation cleared things up. We only have to look at the thing inside a screen mockup (see my screenshot). We can interact with it create new blocks and toggle the edit/render state of the blocks. This thing can be a better UI for a RM-based content builder, but when dealing with a lot of blocks it can get in the way taking too much space. Anyway, I think there is a rather not-so-hard way to implement it not changing everything in PW admin (not rewriting it as a SPA) - using something like htmx (see example in the end of the linked page). Htmx is getting a lot of attention in Django and Flask communities lately. Maybe we could use it for these kind of things.

is_callable doesn't resolve namespaces. It should work if you use "ProcessWire\\custom_debug_if". I'm not sure why ProcessWire.php doesn't use wireIsCallable() at that spot. Might be worth raising an issue.

I get you. Commit's don't always increment the version though ?. When Ryan bumps the version he'll clearly state that in the commit.

Update: Looks like it's all working now, but still checking. Will verify ASAP.

Ok sorry for hectic updating, I did figure it out! Turned out to be quite simple! //Techniques $techniques = $pages->find("template=Technique"); $selected_techniques_raw = $sanitizer->array($input->get('techniques')); $selected_techniques = $sanitizer->options($selected_techniques_raw, $techniques->explode('name')); foreach($selected_techniques as $selected_technique) $selector .= ", relation_document_technique.relation_document_technique_select= $selected_technique"; Thanks a lot for your help!

@kongondoyes its a bug in the core since a couple of versions. https://github.com/processwire/processwire-issues/issues/1447

Thank you very much, i have to correct: i didn't searched very well. This was too obvious..

https://github.com/processwire/processwire/tree/dev Welcome, @vangeesonto ProcessWire and the forums ?.

Im relatively new to proccesswire, but my current and first project is very fast in development thanks to this project. Im in love with ProFields and Repeater Matrix, completely rebuilding an outdated CMS my customers used before. What i wanted to ask: I have 3.0.187 installed and cant find this option in the Details tab. Am i missing something? Couldn't find a dev repo for PW, too.

Thank you so much! You saved me ahah I implemented it and it works well! I also made it so it includes different Page Reference fields! But another challenge for me is to use the same logic but for the Repeater fields. Each Repeater includes two Page reference fields. And I can't seem to even first print out the info I need from them (to build a selector). The structure I have looks like this: And I tried to use the code from the documentation, but it only works with simpler fields like text. Otherwise gives the id of the right page, but refuses to access the name/title of it. <h1>Relations</h1> <?php foreach($page->relation_document_technique as $relation_document_technique) { echo "Other name: {$relation_document_technique->other_name}<p>"; //gives me text echo "Technique:{$relation_document_technique->relation_document_technique_select}<p>"; //gives id of the right page echo "Type of relation: {$relation_document_technique->relation_document_technique_type->title} </p>"; //gives nothing } ?> Maybe there is a simple mistake I'm making, but I would be super grateful if you see the solution for filtering based on Repeater structure! Have a neat day! Kseniia

The short answer is: don't use a lifetime in calls to $cache->get(). Somewhat longer: it looks like a bug to me. It certainly doesn't do what the docs say, namely check the age of an entry. The behavior is a bit different if you specify a template function as the third value, as that uses the lifetime to fill the cache with the function's return value, but that's neither here nor there. In your case (unless I'm misinterpreting what you wrote), the only call that needs a lifetime is the one to $cache->save() in your cron job. The other parts can just call $cache->get('cachetest') and be happy (unless the cache wasn't updated within the last month).

thanks @kongondofor getting back so quickly. pw is 3.0.187 as mentioned, we use multilanguage indeed. we also use multisite (so basically we change the root-homepage with https://github.com/somatonic/Multisite/ based on domain-name) but my guess is, that its not relevant for backend. but you are right, the standard page-lister from the pages menü cant switch to page 2 either, so its a pw or setup issue... i will try to figure it out with ryan. also thank you for the doc-link i indeed missed that. perfekt ?

Hello @dotnetic and @Sebi, Thank you for your quick reply! @dotnetic I already read the first two posts while I had researched. Very interesting, especially the Vue.js feat. ProcessWire case study. I'll take a look to the other modules, maybe they will help me to accomplish me needs. @Sebi I think you basicly understand the concept: The page is like an invitation for a Christmas-Party or similar events. The customer can modify some party of the invitation like background image or font-color and can publich the SPA with their own configs. Ok, that was my initial idea. There shouldn't be any probleme that one customer can see the other pages if he edit his invitaition if I hable the right correct, right? No, it doesn't have to be headless at all, just steped over the "new and modern" headless CMS approches. Maybe the mentioned way will cover all my needs.

Hey @Red_nipon! Nice to have you here! Can you please explain this in more detail? What exactly do you want your client to be able to do? As I understand it, the customer gets a login from you for the ProcessWire admin interface and can then publish one or more SPAs there themselves with their own configuration. Then it would make sense to create a ProcessWire template for it with the configurable parts (fontcolor, dates, ...) as fields. If you or the customer then create a new page with this template in the pagetree, it can be called in the frontend. Of course you can also put a javascript file from a SPA into the corresponding template PHP file and just let PHP write the few configuration parameters into a <script> area, which the SPA then reads when loading. That would be the simplest way I can think of. This concept isn't strictly "headless" then, but it doesn't have to be, does it? Headless to me would be an approach where the ProcessWire resides somewhere else and completely independent of the frontend. I'm actually working on an SPA with Angular/Ionic right now as well. The javascript application is at a hoster under its own domain, the ProcessWire backend is somewhere else entirely. I really like ProcessWire and have already done a lot with it, so it was my first choice as headless CMS for my project. If there are better headless alternatives I can't tell you, only that it works well with ProcessWire. The SPA then constantly requests data (e.g. a configuration, the contents of lists, blog articles, users, ...). The AppApi module is very good to create a JSON api for this [Disclaimer: I am the author of this module :D]. But if you don't need such a constant data exchange, this concept is probably much too cumbersome...

I think I remember @ryandid write about implementing something like ProDrafts' live preview in the core everywhere, so we can change a page in one part of the screen and see it dynamically update in the other. I think this might be another way of doing UI for this, maybe even a better one (or complimentary to the one mentioned before), as we can see the changes not in some pseudo-markup, but in a real one. And do not have to create this pseudo-markup and styling in the 1st place. By the way, I can see how htmx can help here too.

I just tested the repeater storage option and it's working nicely. This behind-the-scenes tweak was really important in terms of efficiency, so thanks for implementing it. As for the ACF example, what you're seeing on that page is basically the equivalent of a matrix field with 3 matrix-types already added ("Header", "Hero" and "Cards") in a "preview" state (remember, this is inside the WordPress admin area, not frontend). (Note: ignore those 8 vertical tabs on the left, that's just marketing material) If you click on the rendered content of one of the matrix-types there, it will switch to "editor" mode and allow you to edit the content. Once done editing, you can click the "Close" button to go back to preview mode. If you click "Add Row" at the bottom, it's the equivalent of the newly created images approach to selecting a matrix-type. Hopefully that clears it up.

@Jonathan Lahijani The png is just an example and it supports any common image extension: gif, png, jpg, svg. I'm cool with a preview option, but just didn't want to mix preview with editor. But a preview that appears above or in a modal or something has potential. We may be able to provide an option for developers to provide their own preview render files, like we do for the preview images. The acf examples look interesting, but admittedly I'm lost in them like a nuclear power plant control room, likely because I'm not so familiar with the wordpress tools. By the way, the option we talked about earlier (repeaters with fewer pages) is now committed in the dev branch and you can enable it by opening the "Repeaters storage" fieldset that appears on the Details tab when editing a Repeater or Matrix field.

Hi @lele_ballack, I've merged your thread to Blog's support forum. This bug has been reported in the issue tracker. I just never got time to investigate it. I'll find some time this week to fix this. Sorry for the inconvenience everyone. Thanks.

Hi Ryan, Just gave 3.0.187 a whirl along with the new version of Matrix and it's looking really great. I wanted to get your thoughts about a potential optimization to repeaters (which would also apply to matrix). Right now, if you add a repeater field (let's call it 'my_repeater') to a template, then create a new page (let's call it 'p1'), ProcessWire will create a "for-field" page and "for-page" page in the following fashion: /admin/repeaters/for-field-123/ title = my_repeater /admin/repeaters/for-field-123/for-page-456/ title = p1 That's all good, but when utilizing RepeaterMatrix as a page builder in the way that I do, it can get a little insane with how many 'for-page' pages get automatically created, even if a repeater field is not being used for a particular matrix-type. In my advanced setup, if I apply a single matrix type to a page, then as a result of having 6 different repeaters as part of my overall matrix field, 6 'for-page' pages will get created behind-the-scenes no matter what. Now imagine a page with 20 instances of various matrix-types used, that means there will be at least 20*6 pages that have been utilized behind-the-scenes which can lead to performance issues (deleting a page like that takes some time). I could demonstrate this with a video, but I think you know what I mean. So in short, is it possible to somehow improve repeaters so it's more efficient with the creation of 'for-page' pages?

knowing page categories and child pages - or the usage of templates and pages as contentcontainers for everthing you ned - is essestiel!! this is a great startpoint for learn this very very important thing - processwire manage the content you need - with simple PHP solutions you get get the content in your templates...i created a complete blog logic without a special module or something else - but you have to know to use pages and fields and learn this things.

You can always reset your password just by pasting this temporarily into any one of your templates, and then viewing a page that uses the template: $u = $users->get('admin'); // or whatever your username is $u->of(false); $u->pass = 'your-new-password'; $u->save();