Robin S

@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/

My gut feeling is that the Page Reference fields, repeaters, foreach nesting is not what is causing this slowness. For a listing of only 37 product pages there should not be that much of a delay. (How long is "abysmally slow", by the way?) I'm doing similar things for with page-per-image setups (although with PageTable rather than repeater) with much larger numbers of pages and there isn't a significant impact on speed. And for pages in the ProCache cache there should be no impact whatsoever. So I think you have some other issue going on. Not sure what though, sorry. If you're developing locally, try testing the site on a remote server and see if you experience the same slowness. Or vice-versa if you are developing remotely. Also: start commenting/cutting out blocks of your template code to try and isolate if one area is responsible.

Welcome to the forums @Henner7, The link @abdus gave is actually for bug reports. Feature requests go here: https://github.com/processwire/processwire-requests/issues There is already a request to remove the default truncation: https://github.com/processwire/processwire-requests/issues/83 Besides the solution from BitPoet that you'll find in the feature request, you can disable truncation for all File inputfields by adding a hook in /site/ready.php: $wire->addHookBefore('InputfieldFile::render', function(HookEvent $event) { $inputfield = $event->object; $inputfield->noShortName = true; });

Thanks for the feedback @alxndre. The module is about better efficiency for the "Add Template" workflow, and I don't think sorting the page list is related to that. I'd like to keep this module fairly focused rather than becoming a collection of general admin tweaks (we already have a great module for that). I agree with Soma's request though. He says his solution is a "dirty hook" but it actually looks very clean to me. I don't think I could come up with anything cleaner so I suggest sticking with Soma's solution. It doesn't need to be added in a module now that we have /site/ready.php.

Limiting and paginating would be sensible too. Even if the list is currently not very long, any time you list pages that a client may add to (I assume the client can add new products) you should limit and paginate because you don't know how many pages this may ultimately grow to.

Instead of the hook, wouldn't it be better to set this as the "Alternate template filename" only on the templates you need it for?

If you mean PW in general, then... Add Material Icons: yes Replace FA with Material icons: no While that long list of Material Icons looks nice at first (and I use them often) there is a heap of essential things missing. A couple of random examples: Facebook, external link.

I thought all the bundled actions were enabled for superuser by default on install, but now I see that superuser is preselected for all the actions but this doesn't actually take effect until you save the module config. Maybe that is intentional in Admin Actions, but in general I think that is something it's better to avoid. Users might navigate away without realising they need to save to confirm the settings on screen. And even if they later return to the module config, there is nothing to indicate that the settings they see on screen are not actually live. It can be a problem for the module dev too if you are expecting those default config values that show on screen to actually be available in the module. It's caught me out a few times in my own modules - I've learned now that a better approach is to define the config defaults in the construct() method so that the config that users see is what is actually in effect, right from the moment of install. Anyway, I see where you're coming from regarding the activation of actions, although personally I don't see any downside to having all the actions active and listed on the Admin Actions page (for superusers) so they can be explored. It's the step of adding actions to the menu where I would be limiting it to just regularly-used actions.

Not sure why you are seeing that. What you should see is an exception message that explains things pretty well: IDs are the way to go for that sort of selector, so I would stick to what you have changed to rather than install PagePaths. Edit: it just occurred to me that you may not be seeing the exception if do not have debug mode enabled. In /site/config.php: $config->debug = true; You should enable debug mode while you are developing a site and then disable debug mode when the site goes to production.

Nice. How about some radios for more focused searches? API reference - site:processwire.com/api/ Forums - site:processwire.com/talk/ Blog - site:processwire.com/blog/ I have these as keyword searches in my browser and they get a lot of use. (TBH, it's so easy to Ctrl+L focus the browser address bar and do a keyword search that I'm not likely to give the Tracy feature much use, but maybe some will prefer the Tracy option).

Hi @adrian, a few ideas for tweaks to AdminActions... How about adding a $title option inside the action class? To specify a title rather than deriving it from the camel-case in the action class name. It doesn't look quite right if there is a capitalised acronym in the class name. Maybe new actions should be automatically enabled for the superuser role? To save having to visit the module config and enable each manually. The "Actions" tooltip appears when hovering any part of actions list in the module config (it comes from the title attribute on the inputfield wrapper). This is a bit distracting so maybe remove that?

protected function defineOptions() { return array( array( 'name' => 'csv_upload', 'label' => 'CSV upload', 'description' => 'Upload a CSV file.', 'type' => 'file', 'extensions' => 'csv txt', 'overwrite' => true, 'maxFiles' => 1, 'required' => true, ) ); } protected function executeAction($options) { // If there was a file uploaded (Pagefiles object) if(count($options['csv_upload'])) { // Get the file (Pagefile object) $file = $options['csv_upload']->first(); // Parse the CSV data $handle = fopen($file->filename, 'r'); $count = 0; while(($row = fgetcsv($handle)) !== false) { $count++; // Process each $row // ... } fclose($handle); // Delete the uploaded CSV file (or else you will get an error next time you upload) unlink($file->filename); $this->successMessage = "$count CSV rows were processed."; return true; } else { $this->failureMessage = 'Please upload a CSV file'; return false; } }

This module corrects a few things that I find awkward about the "Add New Template" workflow in the PW admin. I opened a wishlist topic a while back because it would good to resolve some of these things in the core, but this module is a stopgap for now. Originally I was going to share these as a few standalone hooks, but decided to bundle them together in a configurable module instead. Add Template Enhancements A module for ProcessWire CMS/CMF. Adds some efficiency enhancements when adding or cloning templates via admin. Features Derive label from name when new template added: if you like to give each of your templates a label then this feature can save some time. The label can be added automatically when templates are added in admin, in admin/API, or not at all. There are options for underscore/hyphen replacement and capitalisation of the label. Edit template after add: when adding only a single template, the template is automatically opened for editing after it is added. Copy field contexts when cloning: this copies the field contexts (a.k.a. overrides such as column width, label and description) from the source template to the new template when using the "Duplicate/clone this template?" feature on the Advanced tab. Copy field contexts when duplicating fields: this copies the field contexts if you select the "Duplicate fields used by another template" option when adding a new template. Usage Install the Add Template Enhancements module. Configure the module settings according to what suits you. https://github.com/Toutouwai/AddTemplateEnhancements https://modules.processwire.com/modules/add-template-enhancements/