Robin S

Maybe I'm not understanding you right, but can't you search for pages that contain the repeater fields and then get the repeater items for those pages? I think (based on the code you showed in this thread) that the fields you are filtering and sorting on are fields in the get-for page rather than fields that are necessarily inside the repeater items so it seems like what you want to be finding are the get-for pages. Another general idea that might be useful: if you look at the page structure around repeaters in the Admin section of the tree you see that the repeaters parent name is "for-page-1234" where 1234 is the id of the page the repeater is on. So if you want to search for repeater items directly with a $pages->find() you could first construct an array of parent page names to use in the selector. Something like: <?php $get_for_ids = $pages->find("foo=bar")->each("id"); $parent_names = array_map( function($item) {return "for-page-$item";}, $get_for_ids ); $parent_names = implode('|', $parent_names); $repeater_items = $pages->find("template=repeater_my_repeater, parent.name=$parent_names");

See the screenshots below for a demo of how the Inputfield Selectize module can be used with getForPage()... Page with repeater field Page field using Inputfield Selectize Page field options (note: I'm recycling an existing 'headline' field as the attribute in the repeater) Edit: I'm a big fan of the new Inputfield Selectize, but if you want to use one of the other Page inputfields then have a read of this post - you'll see how the code could be adapted to use getForPage().

I don't have much experience with the PW3 front-end editing features, but this seems to work: <?php $heading_field = $page->headline ? 'headline' : 'title'; $content .= "<h1>$page->edit($heading_field)</h1>";

I think your question relates more to how PW sorts PageArrays created via find() rather than Hanna Code specifically. I guess you are doing something like this in your PHP: $my_pages = $pages->find("id=1086|1021|1053|1018"); I was surprised to discover, as you did, that the resulting PageArray does not sort the pages in the order the IDs were given. This is what I came up with as a workaround: $my_ids = [1086,1021,1053,1018]; $my_pages = new PageArray(); foreach($my_ids as $id) { $my_pages->push($pages($id)); } I'd be keen to hear if there is a better way to get pages into a PageArray while maintaining a given order of page IDs.

Ah, I see. If these values are being stored only for the purposes of displaying in the Page inputfield you could combine them into a single field in the repeater. Or potentially avoid the need for this hook by using the Inputfield Selectize module:

This isn't a direct answer to your issue, but do you actually need this hook? It looks like you want each repeater item to store some values from the page the repeater field is on (the "for-page"), but this seems like unnecessary duplication. Can't you just get the values from the for-page once and output it wherever needed? If you want the value from inside a loop that is outputting repeater items you can use getForPage(), but chances are you already have the for-page in another variable (e.g. $page). So in your template: <?php $type = $page->collections_detail_category->name; // similarly for other values foreach($page->collections_detail_images as $collections_detail_image) { // do what you want with $type, and any other repeater item fields }

Not sure this is the right place to report this, but I noticed that the "Related Forum Threads" links in the documentation for the Images fieldtype are broken.

I think you want <img src="<?php echo $config->urls->templates ?>images/b1.jpeg"> or with short syntax <img src="<?= $config->urls->templates ?>images/b1.jpeg"> And to be honest, I usually hard code the paths to my template images. <img src="/site/templates/images/b1.jpeg">

That would be a nice feature. I'm a strong believer in the benefits of minimising mouse usage. In the meantime... I'm not sure if this is a Windows or a Firefox thing, but if I click the select box and then start typing the highlight moves accordingly. So it's almost like an autocomplete. One catch is that you can't see the highlight on disabled items (i.e. those fields that are already added to the template) but you can type a letter or two and then use the arrow keys to complete the selection.

This seems to me to be pretty comprehensive: https://processwire.com/api/ref/module/ Also useful: https://processwire.com/blog/posts/new-module-configuration-options/ And there's good stuff in the Helloworld.module I'm learning development myself and so I understand how it can be challenging to tackle something more advanced like module development. But I think you also need to bear in mind that many of the things that need to be understood in order to build a module are not PW-specific but are actually require knowledge of PHP and object-oriented programming. We can't expect the PW docs to give us all of this on a plate.

mod_security blocks processing based on regex rules: exactly what rules are implemented is up to the host or the person configuring the module. Perhaps your page contains a string that matches some overly-broad regex rule. The intention behind mod_security is good but my experience has been that running the module results in many false-positives and the resulting problems are difficult to debug. On many hosts you can't even tell when mod_security has been triggered. My shared hosting enables it by default on every new account but I always disable it to avoid headaches.

If your host is running mod_security that might be the culprit. I've struck odd issues like this before that were resolved by disabling mod_security.

Great job on the new forum @Pete. Is there an account setting I can apply so replies in a Q&A thread are sorted by date by default? I find it hard to follow the conversation when they are sorted by rating and don't want to have to change the sort order manually for every thread.

A like is not enough! This is just awesome and opens up so many possibilities for page inputfield UI. :)

If you don't want to upgrade to ProCache v3 there are some htaccess settings shared by WillyC here.

It works okay for me with PW 3.0.21. Not sure why it's not working for you but as an alternative you could use: $users->get($page->settings->created_users_id)->name $users->get($page->settings->modified_users_id)->name

Echoing a comment above... In the image field 'list' view the size difference between landscape-format and portrait-format images can be extreme. In the screenshot below the two images have the same aspect ratio but the portrait-format is rendered much larger. Wouldn't it be better to define the thumbnail container as a square with the thumbnail centered and fitted to the container? Then each image row is an equal height.

I solved this - it was due to a module of mine in which I use the admin image thumbnails. I just needed to adjust the module code to account for the new default thumbnail height of 260px.

The module(s) is a helper for working with images in rich text fields. So part of the functionality is about inserting and applying attributes to images in the RTE and part is sizing the images and and generating markup based on those attributes via a textformatter. Currently I'm splitting this functionality into two modules, but I would rather do it in a single module with a single configuration page. Not sure why it should be forbidden to autoload a textformatter module. To work around this, if my module extends WireData instead of Textformatter is there a way to manually apply a textformatter method via a hook? Edit: thinking some more, the textformatter side really does need to be separate so it can be applied selectively to fields. So two modules it is.

I just needed to fiddle around some more to find my answer. $image_fields = $fields->find("type=FieldtypeImage"); Looking at the data for a field I guess you can also find fields by id, flags, name and label. Nice!

What kinds of things can go inside a $fields->find() selector? Can I use a selector to find fields of a given type? For instance, find all fields that are instances of FieldtypeImage?

Is it possible to have a module that autoloads so admin methods can be hooked and also works as a textformatter? Or is creating two modules the only way? Setting an autoload value in getModuleInfo() seems to have no effect if the module extends the Textformatter class. Two modules would be okay for installation as one can auto-install the other, but needing two module config pages is bit of a pain. And the only other solution I can see is having one module store config data for the other, and that seems wrong.

I am finally getting around to exploring PW3.x (3.0.20 to be exact) but the new images field is always showing 'older/low quality' thumbnails. When I first upload the images and have not yet saved the page the thumbnail quality is good. But as soon as I save the page I get low-quality thumbnails and the low-quality notice. Ticking the checkbox to recreate thumbnails and saving has no effect on the thumbnail quality and the message remains. Any ideas how to fix this? PW is running on XAMPP with PHP 5.5.33

included_file.php <?php $fruit = 'banana'; echo "<p>My fruit is a $fruit</p>"; main.php <?php $fruit = 'watermelon'; call_user_func( function() { return include func_get_arg(0); }, 'included_file.php' ); echo "<p>My fruit is a $fruit</p>"; Output: <p>My fruit is a banana</p> <p>My fruit is a watermelon</p> Credit

This works... $module_config = new MyModuleConfig(); $defaults = $module_config->getDefaults(); Does that look okay?? I'm an OOP noob.