Leaderboard

I think you need to click on the image to edit custom fields. Or switch to the detail view: Also, does your caption field use a rich-text editor? Back when custom image fields were introduced, CKEditor was not supported, although much has changed since then. https://processwire.com/blog/posts/pw-3.0.142/#considerations-in-the-page-editor

This week a need came up in a client project. The client's team wanted to be able to navigate to their tours (pages) in the admin page-list by different criteria (operator, brand, boat, etc.). You can do this in Lister already (filtering by page references), but the client was looking for some predefined navigation paths in the main page list, as they thought this would be a helpful and time saving optimization, as they spend a lot of time in ProcessWire. They don't always know the exact tour at first, so starting from an operator, brand or boat helps them get to where they want to go more quickly. Once implemented, I thought it was actually quite useful for a lot of situations so decided to develop it into a module on my own time, and that's now available for download in the modules directory. I've published a new blog post that describes it more and covers all the details— https://processwire.com/blog/posts/page-list-custom-children-module/

Hi, @Robin S! Just came to say thanks for this module. It is so cool to have when you need it!

I have resolved everything with children pages and a Page Reference field with single select *. I'm also using the PageEditChildren module. And with children pages I can use the VerifiedURLs pro module.

Yeah custom page classes are absolutely essential to everything I put together. It's really nice to be able to populate interfaces for different page types this way - e.g. I have a jsonld method I attach to various page classes that allow me to segregate the structured data and custom tailor it for each class - but in various templates I can simple $page->jsonld() and not think about the schema more than once for each page class. I already know the right fields for a given page type will go in the right spots in the schema output.

That’s great @ryan. You may call it a “simple” module, but it think it will be an important addition to ProcessWire’s capabilities.

Could it be that you acutally use a multi-image field aka an image field that allows multiple images? If so that image part needs to be in a foreach() or you need to use $image->first() and go from there. // probably easier to use first() here as you only want to show one picture $image = $content->$block->cover_img; // Access the block property dynamically if ($image) { $cover_image = $image->first()->size(0, 2000); echo "<a href='{$content->url}'><img src='{$cover_image->first()->url}' alt='{$cover_image->first()->description}'></a>"; }

This is great stuff! Thank you! @FireWire, As a beginner, I would love to learn how you usually set up a simple institutional website. It would be nice to see how you do.

there's a new version on github now that also installs a stack_prices repeater field and a ready-to-use product template. Hope that helps. I'm trying to give users with guest role permission to view (at least) the kiosk dashboard page on kiosk.datajungle.xyz, but don't know how yet. Any help is welcome. If you installed the first version and want to use the new one, uninstall while still on the first version because I renamed the templates and fields and whatnot to keep it more consistent. Sorry about the inconvenience, if there's a better way to do it? Still learning how to use the "update" functionality of modules.

@bernhard, thanks for the pull request. I've merged parts of that along with a few more of my own changes. But probably not necessary to do much more with this particular repo though because it really only exists to serve as a quick demo for people like yourself who might like to take the idea further. I'm not feeling possessive of this idea/code at all so anyone is very welcome to take it and use it for their own purposes in any way they like - further developments don't need to happen via my repo. To go further into something that would be more widely useful to the community, shared in the modules directory, etc, would require a new module that doesn't bundle any particular Process module like my demo does. I'm imagining something that would work with any custom Process module. And maybe focuses on the iframe approach because that seems the most promising (I was also playing around last night with the same JS library you mentioned). I might tinker around with something later but anyone is welcome to have at it and beat me to it. ? To respond to some of your points... Great, we don't want that exposed. I wish there was a better way than string replacement on the whole HTML output but there isn't any way I can see to set that part of the JS config object directly and I fear setting $config->urls->admin before the page render could have other unwanted consequences. The redirect isn't really about the ?modal=1 (although that is unwanted) - it's the Post/Redirect/Get pattern. If you look at the core Process modules you'll see that they all redirect after form POST submissions. In any case the specific code within the demo Process module is not something that anyone needs to use, it's just so the demo module renders something visible. What a person puts in their execute methods will depend on what they want their module to do. Incidentally, setting $this->wire('input')->get->modal = 0 unfortunately doesn't solve the problem for redirects as these still have the modal parameter forced onto them. I think the simplest solution for that is just to make sure any redirect URLs include "//" (e.g. use http URLs). I think it is too late within any Process module to throw a 404 exception. The best I could come up with is to check that any URL segment is valid and if not redirect to the 404 page. Maybe someone will discover a better way. Thanks to this post I think I have a solution for this, added in the recent commit. ProCache can run on any page where the user isn't logged in, which for guests will be all pages besides the ones executing a front-end Process module.

I built a simple cart system using JS + Local Storage; works perfectly and the cart contents last a long time; This is for visitors to collect swatch samples and then be able to request those samples in a form; there is no ecommerce in this case, but once you have the cart, it shouldn't be hard to use that data to interact with a 3rd party payment system.