Robin S

One more option: $matches = $pages->find("title~=$q, template=speech-archive-detail|training-detail"); $speech_archive_matches = $matches->find("template=speech-archive-detail"); $training_matches = $matches->find("template=training-detail");

Tabs 4 Life, brah! There is no more definitive authority than Richard Hendricks: (I've posted that before but could not resist) But seriously, the PW code style gets things so right. The braces style too. Some reasoned argument: https://github.com/php-fig-rectified/fig-rectified-standards/blob/master/Reasoning-Tabs-vs-Spaces.md https://github.com/php-fig-rectified/fig-rectified-standards/blob/master/Reasoning-Brace-Styles.md

The $options are used in the PageRender module. There isn't much documentation for them apart from what is in the module file.

At the top of your template file: if(empty($options['pageStack'])) throw new Wire404Exception();

Hi @kongondo, I purchased VPS this afternoon and have been having an explore of it. As always with your modules, it's impressive stuff! A question: is it possible to customise the columns that are shown in the inputfield list view? So if we're not using Tags but want to show some other custom field from the page can we show that? It would be really useful if we could. I want to give some feedback on some aspects of the appearance and workflow, and I mean this to be constructive so I hope it comes across that way. It's awesome what this module can do and it's obvious how much work you've put into it. It's just lacking a bit of the polish and attention to detail that I would expect from a pro/commercial module at this price point. 1. It would be nice if the Process module installed the Inputfield module ("installs" option in getModuleInfo) so it was just a one-step installation process. 2. Rather than users needing to type the name of the image fields used for thumbnails, could you change to an AsmSelect that selects from existing image fields? Also, the note here needs updating to reflect that image fields allowing more than one image can now be used with VPS. 3. If the option to allow users to edit pages from the modal is enabled, the page edit view replaces the add/remove lister and there is no way to return to it. I'm wondering if this option is needed actually - I couldn't think of many cases where you would want to allow page editing within the modal that has been opened to add/remove pages from the inputfield. 4. In the inputfield list view, the Description and Tag columns do not reflect changes to those fields made in the page modal edit (the inputfield reloads, but the columns don't update). 5. The spinner is cut off in the modal. 6. The tab layout in the modal is a bit messed up. 7. The position of the actions select/button looks off too - it's crashing into the grey bar above. Also, it's not possible to interact with the select because it is behind the WireTabs <ul>. 8. In modal edit view, some text is obscured behind the WireTabs. 9. The thumbnail appearance and layout could be improved IMHO. a) Show the thumbnail uncropped, so the aspect ratio of the image can be seen. b) Remove the rounded corner styling - it can be misleading (what if you had an image that actually had rounded corners), and it isn't used consistently (list view thumbnails are not rounded). c) Use the core default thumbnail dimension of 260px height and unconstrained width. In most cases this will also make the inputfield/modal load faster because the thumbnail variation will already exist from the time the image was uploaded. The existing thumbnails are too small. d) It's a tiny bit disconcerting seeing the thumbnail scale down when the pink "selected" border is applied. Perhaps consider a different CSS styling technique such as applying the border to a transparent element in front of the image. e) The thumbnail layout breaks at some widths. Also the thumbnail label line height is too low. f) Let the thumbnail container be the natural width of the thumbnail. So all the thumbnails just float left against each other (with some white space around them), similar to the appearance of the core Images field. I tweaked the VPS code a bit to get this: The thumbnail label could potentially be removed too, and shown in a tooltip on hover (I think in most cases users select an image from scanning the thumbnails rather than the labels). Or add an option for this. 10. If pages are removed from the inputfield (but the page is not yet saved), this is not reflected when the modal is opened. The removed pages are still shown with the border/opacity styling of pages that are added to the inputfield. I guess it might be difficult to avoid this. 11. In the modal, if the "remove" action is performed on a page that is not added or the "add" action is performed on a page that is already added, the error notice could be less cryptic: There is also an overflow issue possible here, and the appearance of the notices are somewhat ugly in general: unnecessary white border and border radius, unnecessary background colour change on hover, the text needs some padding. 12. Could the actions in the modal window (add, remove, etc) be smarter to streamline the workflow? For the lesser-used actions (delete page, delete image from page) the select dropdown is fine, but it is a bit awkward for the frequent actions of adding and removing pages. How about this: VPS knows whether each page is currently added or not (hence the different styling). So for pages that are not added clicking the thumbnail marks the page for adding (a plus icon or similar is shown in the corner of the thumbnail). And for pages that are already added clicking the thumbnail marks the page for removal (a cross icon is shown). 13. Some very minor appearance things: Inconsistent text size and divider appearance for the same controls in the modal vs the inputfield. The default focus style looks awkward on the Add Pages button after the modal closes. Using a large black h3 for the "Nothing added yet" text is a bit strong. I understand if you think some of these issues are trivial, but the truth is I wouldn't be entirely happy having my clients use this module in it's current form. But with a bit of polish it will be amazing, and I want to thank you for developing it.

@mke, there is a property and helper method in InputfieldFile that allows a maximum files size to be set but there is no config field for it in admin and you would need to set the max file size in a hook in /site/ready.php: $wire->addHookBefore('InputfieldFile::render', function(HookEvent $event) { /* @var InputfieldFile $inputfield */ $inputfield = $event->object; if($inputfield->hasField == 'YOUR_FIELD_NAME') { $inputfield->setMaxFilesize('2m'); // Set the max file size in bytes or use string like "30m", "2g" "500k" } }); Also, for some reason max file size settings of less than 2MB are not enforced - see here.

Related module:

Related module:

Some introduction... This module is experimental and there are probably bugs - so treat it as alpha and don't use it on production websites. I started on this module because there have been quite a few requests for "fake" or "invisible" parent functionality and I was curious about what is possible given that the idea sort of goes against the PW page structure philosophy. I'm not sure that I will use this module myself, just because I don't really see a long list of pages under Home (or anywhere else) as untidy or cluttered. I would tend to use Lister Pro when I want to see some set of pages as a self-contained group. But maybe others will find it useful. At the moment this module does not manipulate the breadcrumb menu in admin. So when you are editing or adding a virtual child the real location of the page is revealed in the breadcrumb menu. That's because I don't see the point in trying to comprehensively fool users about the real location of pages - I think it's better that they have some understanding of where the pages really are. But I'm open to feedback on this and it is possible to alter the breadcrumbs if there's a consensus that it would be better that way. Virtual Parents Allows pages in Page List to be grouped under a virtual parent. This module manipulates the page list and the flyout tree menu to make it appear that one or more pages are children of another page when in fact they are siblings of that page. Why would you do that instead of actually putting the child pages inside the parent? Mainly if you want to avoid adding the parent name as part of the URL. For example, suppose you have some pages that you want to be accessed at URLs directly off the site root: yourdomain.com/some-page/. But in the page list you want them to be appear under a parent for the sake of visual grouping or to declutter the page list under Home. Example of how the page structure actually is Example of how the page structure appears with Virtual Parents activated How it works This module identifies the virtual parents and virtual children by way of template. You define a single template as the virtual parent template and one or more templates as the virtual child templates. Anytime pages using the child template(s) are siblings of a page using the parent template, those child pages will appear as children of the virtual parent in the page list and tree menu. You will want to create dedicated templates for identifying virtual parents and virtual children and reserve them just for use with this module. Features Adjusts both page list and tree flyout menu to show the virtual parent/child structure, including the count of child pages. Works everywhere page list is used: Page List Select / Page List Select Multiple (and therefore CKEditor link dialog). Intercepts the "Add page" process in admin, so that when an attempt is made to add a child to a virtual parent, the child is added where it belongs (the next level up) and the template selection is limited to virtual child templates. Intercepts moving and sorting pages in the page list, to ensure only virtual children may be moved/sorted under the virtual parent. Superusers have a toggle switch at the bottom of the page list to easily disable/enable Virtual Parents in order to get a view of what the real page structure is. Usage Install the Virtual Parents module. In the module config, enter pairs of parent/child template names in the form virtual_parent_template=virtual_child_template. If needed you can specify multiple pipe-separated child templates: virtual_parent_template=child_template_1|child_template_2. One pair of template names per line. There is a checkbox in the module config to toggle Virtual Pages on and off, but it's more convenient to use this from the page list. Notes It's important to keep in mind the real location of the virtual child pages. This module is only concerned with adjusting the appearance of page list and tree menu for the sake of visual grouping and tidiness. In all other respects the virtual children are not children of the virtual parent at all. It's recommended to select an icon for the virtual parent template (Advanced tab) so virtual parents are marked out in the page list as being different from normal parent pages. Do not place real children under a virtual parent. There is some protection against this when moving pages in the page list, but when it comes to changing a page's parent via the Settings tab the only protection is common sense. https://github.com/Toutouwai/VirtualParents

From the documentation you linked to: https://processwire.com/api/selectors/#sort

Or maybe "tags" is a Page Reference field and you can do this... <?php $getCities = $page->find("template=t3Cities_list"); ?> <?php foreach($getCities as $city): ?> <div class="grid-masonry"> <div class="grid-sizer"></div> <?php foreach($city->tags->sort('title') as $tag): ?> <div class="grid-item"> <a href="<?= $tag->url ?>" class="img-hovered"> <div class="overlay"><span><?= $tag->title ?></span></div> <img src="<?= $tag->categorythumb->url . $tag->categoryThumb ?>" alt="" class="img-responsive"> </a> </div> <?php endforeach; ?> </div> <?php endforeach; ?>

This part looks like it could perhaps be optimised better: <?php foreach($order->order_products as $order): ?> <?php $product = $pages->get("id=" . $order->order_product_id); ?> Could you use a Page Reference field to hold the order products rather than a repeater that holds each product's ID?

@ZGD, this works well if you have a smallish number of pages that you will load into a memory without any limit/pagination. It is applying the sort to the PageArray produced by $pages->find() rather than applying the sort in the database query. It won't work if you need to apply a limit/pagination because each set of pages will be sorted separately. If you need to sort a larger number of pages by template then I recommend renaming your templates to align with the template label, as you cannot sort by template properties such as label within the $pages->find() - the template sort is handled as a special case within PageFinder.

foreach($page->template->roles as $role) { echo "$role->name<br>"; }

Thanks, for this project I'm pretty committed to my custom access module at this point, and it's working well. I did install that module just now to have a look. It isn't compatible with PW3 out of the box (needs fixes here and here), it caused the Pages tab to disappear for non-superusers, and the absence of even a module readme makes it difficult to get to grips with. Not sure of the advantages over Page Edit Per Role. Apparently you can allow non-superusers to administer the user groups, although without documentation it wasn't clear to me how to allow that. Interesting though.

I tried the idea of identifying groups of roles by custom permission and it seems to be working well. Only thing to watch out for is that superuser gets all permissions by default so wherever I check the user I do: if(!$this->user->isSuperuser() && $this->user->hasPermission('limited-page-tree')) { //... }

I think there will be a bit more to it than this, because there are quite a few places in FieldtypeInteger and InputfieldInteger where the value is cast with (int), which will truncate the value of high integers depending on platform. https://stackoverflow.com/questions/670662/whats-the-maximum-size-for-an-int-in-php/2842548#2842548 This one works well.

I have several roles that I want to identify as a group (they are all subject to certain access restrictions that I am applying with hooks). To save having to identify all these roles by name (I have to do this in several places) I'm wondering about how I could target them all as a group. I had the idea of creating a new permission that will not actually do anything, but I give this permission to all of the roles that I want to group together and then I can target users with those roles with $user->hasPermission(). It would be a little odd though because this permission would in fact identify users that are more restricted. Is this a good way to identify a group of roles? Are there alternative ways to group roles? Like some kind of roles hierarchy?

Try this: https://modules.processwire.com/modules/admin-page-field-edit-links/

Whoa, sweet! That one's not quite nonsensical enough for me. I don't want people to be in any doubt that it's dummy text.

I'm looking for suggestions of dummy text generators. Some things on my wishlist: Not the usual cod-latin "lorem ipsum" - you'd be surprised how many people out there have no idea that this is dummy text ("What's with all the foreign words? I want an English website"). Uses actual English words, but such that it is obviously nonsense text to be replaced. Nothing that is going to tread on any toes (e.g. I can imagine some clients not seeing the humour in corporate ipsum). I really liked the generator that Ryan used in the blog profile (it had a great "fairy tale" option) but unfortunately it has folded: http://duckisland.com/GreekMachine.php I have done some Googling BTW, just haven't found anything ideal.

Is "freeActs" an integer field? If so maybe you need to check this setting: I cropped it out of the screenshot but read the setting description for a good explanation of what this setting is for.

I'm confused by this - didn't you say that the maximum number of products you are currently listing is 37? 245 pages is more pages than you want to be loading without a limit. If you are later filtering these 245 pages down to 37 or whatever you should try and rework it so you are getting only the 37 in the initial $pages->find().

The solution from @abdus works well - you just need to change... $img = $page->randomImages[$page->randomIndex]; ...to... $img = $page->randomImages->eq($page->randomIndex); ...because Pageimages are indexed by basename not integer. This must be the result of some efficiency optimising in Hanna Code. To get around this, just add some attribute to each tag - you don't need to use this attribute anywhere in your tag code. So lets say the attribute is called "seed" (just so it looks kinda legit to the user - this attribute is not actually used to seed anything): [[random_image seed="546458"]] ...some content... [[random_image seed="afdasfd"]] So this attribute's value can be anything so long as it's not the same as another tag on the same page.

You mean the extra backslashes? Those are to escape the forward slashes. Read more here: https://stackoverflow.com/questions/10210338/json-encode-escaping-forward-slashes/