LostKobrakai

Overhead means that repeaters are actually pages, which are stored somewhere in the admin section. But it's not the pages per se, but it should be something about the handling of them as I remember Ryan stating that pagetables are better in that regard. About your repeater problem: foreach($page->before_after as $r){ // This may be easier to set up instead of tagging every image $before = $r->Images->first(); $after = $r->Images->last(); $thumb = $after->size(300, 300); // Markup }

Looks really great. One really minor thing: Maybe the logo could be using svg if supported. For me the oblique lines look a little bit frayed, especially as all the other UI elements look clean and sharp.

Like you would do it on any other occasion: // category is the current page $gallery = $pages->get("parent=/, template=gallery, category=" . $page); // $pages->get() returns a NullPage if it doesn't find anything, // therefore the check for the id. if($gallery->id) $session->redirect($gallery->url);

I was talking about my own suggestion.

Maybe not the most suggesting thing UI wise, but what about something like this: for($i = 0; $i < count($page->Images) / 2; $i++) { echo "<div id='container1' class='twentytwenty-container'>"; echo "<img src='$page->Images->eq($i*2)->url'> "; echo "<img src='$page->Images->eq($i*2+1)->url'>"; echo "</div>"; } Just use the order to get images together.

To make this a bit more clear. You'd use the redirect on that parent page(s), that you don't want anyone to see. Changing the navigation to not show these pages in the first place is an entirely different matter.

I doubt that there would be enough rush to really justify a whole new subforum, but maybe a topic per cms could be a nice reference for new people around. Sometimes it's easier to explain things not only from the point "what ProcessWire does" but also from "what does it different than".

I don't know if that fixes anything, but you'd need to account for characters between the "…><…" brackets: https://regex101.com/r/qK8qA9/1

You can put this line almost wherever you want. Just make sure it only affects the pages where you want the redirect to happen.

The first one is simple. The host mentioned by the error message is the host you're accessing the installtion with, therefore this host needs to be set as one of $config->httpHosts, like it's described there. The other ones let it seem like your processwire installation has no access to the internet.

Without template file there's no way to check if a template is (should be) renderable or not.

Jep, like any other "field=page.somefield" selector does fail with it. It's not the fault of "somefield" but InputfieldAutocomplete does not parse the "page.somefield" part, but just reads it as textvalue. I posted my changes to github so we can see what Ryan thinks of it. https://github.com/ryancramerdesign/ProcessWire/issues/1179

At least it's only a single file instead of lots of them.

Just use the alternative template file setting for templates to let them all use the same file.

It works like this: Add image to ckeditor (markup pasted in from plugin) Potential jQuery stuff happens on the ckeditor Markup is saved to database as it's in the editor Markup is loaded for frontend access from the database Potential textformatters are applied at runtime by php (cacheable by markupcache) Markup is send to the user Potential jQuery stuff happens (frontend) In 1, 2, 5 and 7 are the common places where you could bring in your custom logic. Which one you take depends on the use case.

There's no UI to add Listers. That's part of the pro module. The core module is used in Pages > Find and for listing the users of your installation. You can also use it via custom modules.

Great to hear that and welcome to the forums.

This looks very nice. I really like consistent UI / UX and the image field did always lack by the tiny bits. My greatest bugbear was always the dropzones. E.g. if I not hit the input exactly it'll load the file as local resource and all changes to my page are gone. Also I've hesitated to use croppable image in the last months just because I really don't like the fact, that it needs to replace the whole UI, instead of gracefully building on it. Therefore I really like your proposed changes to the cropping interface. As you've asked for other opinions I've some thought for you: 1A Having tabs resolves the issue of showing the user his options, but I know it from myself, that it would bug me really soon (if I would use RTE's more often). If I want to add an image I click the image button in the ckeditor toolbar. While the modal opens I switch to Finder, drag my file to the browser and sadly notice, that the droparea is behind the tab. Then I'd try to not drop my image anywhere, where I would open it in the browser or to any wrong folder or the desktop. Change to the upload tab. Repeat first steps. Not very nice. 1B Your alternative would solve my issue with 1A, but it looks really imbalanced from a visual standpoint. Unlike all your other images this looks like a really rough mockup. Maybe a vertical layout would work better than side by side, but not necessarily. 1C Grids are nice to get an overview, but they lack to highlight the most important thing an editor need to be reminded of: descriptions. It also lacks tags, but I'm really not using those. But back to descriptions. I don't know about you guys, but I always use them for alt tags and these should really be filled if one cares for seo. I'm still not sure how this could be solved better, but I really think that only-image grids aren't the obvious way to go. 2 As said before I really like the cropping option on the side and the more tidy placement of all things. The only thing I have to critic about it are the buttons. There are two cancel buttons and the "Apply" button fails to communicate what it does. "Save and Replace" like the bigger button below? I also think the "replace" part should not be part of an button, but part of your options. The "Save" button should only have a single type of action – saving the crop with the current settings – while I may decide while cropping, that I don't want to replace the current crop, but save a new one.

CKEditor doesn't care about frameworks. You'd need to check that classes are allowed for lists, but then you can add all the classes you want to them. The downside of using only a single CKEditor is, that you've no easy way to edit the list via the api, as it's saved as big blob of markup. With repeaters or pagetables you've still all the options when accessing the infos via api.

Moved topic.

InputfieldAutocomplete won't work, because it's using the ajax api of the page search in the admin. There's certainly no page context there you could build on. Now I got it to work with some small changes: protected function getAjaxUrl() { $page = $this->page; $process = $this->wire('process'); if($process && $process->className() == 'ProcessPageEdit') $page = $process->getPage(); $selector = InputfieldPage::getFindPagesSelector($page, $this->findPagesSelector); // … rest of the function like it was } And additionally making InputfieldPage::getFindPagesSelector a public function instead of protected. This way the selctors "page.something" is evaluated and changed before the search url is rendered to the field.

You just listed all the step I took and it's working for me. Just to make it clear: The rootparent field is on the same page as the page field you're setting up. If the field in the backend shows the right value, then it should work. To debug this you could try replacing the reference field with a simple integer field, while I suspect that writing out the pages id in the selector does work as expected.

Seems like you already had a look at my module. It does exactly what you need, but I had an error in the README file. You'd need to use this selector: has_parent=page.rootparentfield

InputfieldMarkup is only the inputfield, but there's no corresponding fieldtype, that you could create a field from. It's more a tool for module creation and custom backends.

I meant the option to return a Page as parent instead of a whole PageArray.