Robin S

That's a special case because it's a module that is all about PW fields, templates and pages - indeed anything in the PW API. Generally speaking, if your publicly-shared module needs to collect and store some data then fields/templates/pages is not the way to go. It's messy, it's not self-contained, and it's liable to cause a headache for uninstalling and upgrading (what if a user adds or removes fields from your module templates?).

Sometimes a module does need to create fields, templates and pages but it would be the exception rather than the rule. Most Process modules, even complex ones with multiple (pseudo) sub-pages such as Admin Actions, do not create fields, templates or pages other than the single page used to execute the Process. Instead they use multiple execute() methods that work via URL segments. The forms on those pseudo sub-pages don't save data to PW fields but save all the module-related data to the module's config (stored as JSON in a single field in the database). The "nav" array in the module info takes care of creating the navigation to sub-pages. But perhaps you already know this if you've studied ProcessHello and other Process modules. Some off-the-top-of-my-head cases where you probably would need real fields/templates/pages for a module: You want to store files or images for use with the module. You want to use a Repeater and don't want the extra work to create to repeatable input type in the Process module. You want to store a larger amount of data than is allowed for in the TEXT column type used for module config data (although alternatively your module could create a dedicated table to store its data).

If all your variations (thumbnails and other variations) are corrupt you can delete them with the Pageimage Remove Variations module. The variations will be recreated next time they are requested.

There is no method call on the repeater matrix field value there - I think you meant to include ->find(): $items = $page->matrix_slider->find('start=1,limit=3'); That should work.

You can render the comments list and comment form for another page by calling render() and renderForm() on the value of the comments field of that other page. For example: // Get the page $p = $pages(1234); // Render comments list echo $p->comments->render(); // Render comment form echo $p->comments->renderForm(); If you have the "Redirect after comment post?" option checked then the user will be redirected to the page being commented on after the form is submitted. You probably don't want that so you could adjust the value of the hidden page_id field in the comment form. Unfortunately there's not much that's hookable in the FieldtypeComments module so you'd have to do this by editing CommentForm.php (first copy the FieldtypeComments module to /site/modules/) or use Javascript to change the field value. Alternatively you could disable the built-in redirect option and handle redirection after form submission via your own code.

Have a look at the Connect Page Fields module. This will let you simultaneously add conferences to speakers when you add speakers to conferences. You can also get pages that reference a page via the API with $page->references() since PW 3.0.107.

Good ol' ProcessWire - there's always a way! // Get the page to render $p = $pages(1234); // Set a page number $input->setPageNum(2); // Set a URL segment $input->setUrlSegment(1, 'my-segment'); // Set a GET variable $input->get->foo = 'bar'; // Render the page echo $p->render();

If I have a template "news_items" that has page numbers enabled and that lists child pages ("news_item") with a limit of 20 news items per page, is there a way I can use $page->render() to render the page with a page number other than 1? For example, what if I want to render page 2 showing news items 21-40? It seems like it ought to be possible to do this but I can't work out how. And similarly, is it possible to render a page with a particular URL segment or a particular GET variable?

Have you tried Fields > Manage Tags > [your tag] > Display as collapsed in fields list?

v0.1.1 released: if you select more than one bottom page per parent then their sort order in the page list will be the same as the sort order in the module config.

Here is a module: ?

Pages At Bottom Keeps selected pages at the bottom of their siblings. A "bottom page" will stay at the bottom even if it is drag-sorted to a different location or another page is drag-sorted below it (after Page List is refreshed the bottom page will still be at the bottom). Newly added sibling pages will not appear below a bottom page. The module also prevents the API methods $pages->sort() and $pages->insertAfter() from affecting the position of bottom pages. Note: the module only works when the sort setting for children on the parent page/template is "Manual drag-n-drop". Why? Because you want some pages to always be at the bottom of their siblings for one reason or another. And someone requested it. ? Usage Install the Pages At Bottom module. Select one or more pages to keep at the bottom of their siblings. If you select more than one bottom page per parent then their sort order in the page list will be the same as the sort order in the module config. https://github.com/Toutouwai/PagesAtBottom https://modules.processwire.com/modules/pages-at-bottom/

It's working for me using the code from your first post. ProcessGoodNews.zip If this module you're working on is going to be freely shared with community when finished then maybe it would be good to put your code into a public GitHub repo now so people can see the code and help you with problems that come up as you are developing it.

Times as strings are not supported for in-memory selectors, only PageFinder (database) selectors. You'll need to use timestamps (e.g. via strtotime).

If you don't already know the page and field name that $imageOK belongs to and have to work it out from the Pageimage then I suggest: $p = $imageOK->page; $field_name = $imageOK->field->name; $p->of(false); $p->$field_name->add('/full/disk/path/to/image_new.jpg'); $p->save($field_name);

Also take a look at Ryan's helpful ProcessHello demo module: https://github.com/ryancramerdesign/ProcessHello It's a lot simpler to use getModuleInfo() (or its equivalent if using the other module configuration options Horst linked to above) to specify the page used by the Process module because then it will be automatically created on module install and removed on module uninstall. See the ProcessHello example: https://github.com/ryancramerdesign/ProcessHello/blob/9c1aa18eb40d069c7fb227f09badddc90f0b3276/ProcessHello.info.php#L41-L46

The PageActionClearImageVariations module sounds very useful, thanks @ryan. I have a number of sites where I suspect I have a significant amount of wasted disk space due to orphaned image variations. Trouble is that I don't think I would able to identify the orphaned variations from attributes such as width and height. What would be ideal would be if there was some way to identify orphaned variations based on whether they are called within any site code (template files or modules). Do you think there would be any way to accomplish that? Another idea I had was to see if fileatime() could be used to check if a file has not been accessed in a long time (which would be configurable) but based on a quick test it seems that the last accessed time does not get updated when an image is loaded by a browser. Any other approaches that could be useful here?

Something that I found useful recently... Users can type a date/time directly into a Datetime field, which can often be faster than using the separate controls in the datetime picker. But the problem is that there's nothing built into the Datetime inputfield to let users know what the expected input format is for the date/time. You could enter the input format in the description or notes for the field, but you'd have to do this separately for every Datetime field and remember to update it if the input format changes for any reason. Instead, you can use a hook to automatically show the current input format in the notes for all Datetime fields: $wire->addHookBefore('InputfieldDatetime::render', function(HookEvent $event) { /* @var InputfieldDatetime $inputfield */ $inputfield = $event->object; $datetime_input_format = $inputfield->dateInputFormat; if($inputfield->timeInputFormat) $datetime_input_format .= ' ' . $inputfield->timeInputFormat; $ts = strtotime('2016-04-08 5:10:02 PM'); $inputfield->notes = 'Input format: ' . date($datetime_input_format, $ts); }); Or as the title tooltip if you prefer (you have to add the title to wrapper because a title on the input itself gets wiped out by the JS datepicker): $wire->addHookBefore('InputfieldDatetime::render', function(HookEvent $event) { /* @var InputfieldDatetime $inputfield */ $inputfield = $event->object; $datetime_input_format = $inputfield->dateInputFormat; if($inputfield->timeInputFormat) $datetime_input_format .= ' ' . $inputfield->timeInputFormat; $ts = strtotime('2016-04-08 5:10:02 PM'); $inputfield->wrapAttr('title', 'Input format: ' . date($datetime_input_format, $ts)); });

An update to the hook in the first post for PW v3.0.117 or greater. // Add a new 'chunk' method to WireArray, the equivalent of PHP's array_chunk $wire->addHookMethod('WireArray::chunk', function(HookEvent $event) { /* @var WireArray $wire_array */ $wire_array = $event->object; $size = $event->arguments(0); if( !((int) $size > 0) ) throw new WireException('WireArray::chunk requires an integer $size argument greater than zero'); $chunks = new WireArray(); for($n = 0; $n < count($wire_array); $n += $size) { $chunks->add($wire_array->slice($n, $size)); } $event->return = $chunks; }); This returns the chunks as a WireArray so you have the option of using WireArray methods. So if needed you could do something like: $items = $pages->find("template=foo"); $chunks = $items->chunk(5); $three_random_chunks = $chunks->find("limit=3, sort=random");

Such a cool wee surprise, love it.

Maybe you could if the number of items in the WireArray is fixed, but I'd say it's not the best approach if the number of items is variable or might change at some point. The slices() method divides however many items are in the WireArray into the given number of slices. So if there are 6 items and you do slices(2) you will have two slices of 3 items each. But if later there were 7 items you would have a slice of 4 items and a slice of 3 items, which would not be so good for the desired layout. Instead I think you want something equivalent to array_chunk() which will divide the WireArray into chunks of a given number of items. See here for a WireArray implementation of array_chunk():

Or rather not cast the version to int for use in the query string. I had to make this change in several of my modules after I switched to semantic version numbers.

It would be great to have a tool that takes the document as input and spits out an HTML flow diagram as output, where explanatory details could be shown in tooltips, modals, etc. Because to make sense of the language you'd have to spend a fair bit of time memorising the syntax and I can see that being a problem for non-devs (i.e. clients).

This looks really interesting! But I don't quite understand. The intro says: So does this language convert to some other format (like Markdown > HTML)? Does the language translate to some visual form like CSS does? Or is it executable like Javascript, PHP, etc? Putting it another way, is the end result something other than the document itself? Sorry if these are dumb questions - just struggling to get my head around it.

The issue seems to be fixed in latest dev downloaded today.