Robin S

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.

I think I'll leave it for now unless I hear from others who are finding it confusing. I didn't know PW had that restriction. Thanks, have merged in v0.1.8.

This seems like a pretty good approach to both inline and CSS images: https://css-tricks.com/using-webp-images/ For inline images in a textarea a textformatter module could prepare the picture/srcset.

Probably not news to anyone familiar with webp, but I just tried it and the reduction in file size is impressive indeed. WEBP image on the left generated from variation with 100% quality, JPG on the right with default PW quality setting. Interesting that there is a slight but perceptible difference in colour though.

Maybe SessionHandlerDB will behave differently and therefore be an alternative.

I experienced the same issue using the PW Upgrades module. I think it is Windows-specific and relates to a bug introduced by Ryan trying to resolve this issue: https://github.com/processwire/processwire-issues/issues/704 In recent dev versions PW is not able to delete files on Windows. See also:

I can confirm the same issue on Windows with recent dev versions. I think the problem relates to commits made in an attempt to fix this issue: https://github.com/processwire/processwire-issues/issues/704

Thanks, I always forget about this possibility because in my default site profile I automatically derive field labels from names. Fixed in v0.1.7. It's actually deliberate the way it is. Title tooltips can be a distracting irritant when you don't have an intention to see them. I wanted there to be some intentionality required for them to appear, so you need to hover the field identifier (which is block level so it's pretty easy to mouse to) rather than having tooltips popping up whenever your mouse is anywhere inside "Field widths".

You mean fields inside a FieldsetTab? If so then yes, it works well.

v0.1.6 has a new config option to choose Name or Label as the primary identifier for fields. Whichever isn't chosen becomes the title attribute shown on hover. Thanks @tpr - in v0.1.6 I added your drag resizing code mostly unchanged. It's not something I think I'll use myself but very cool nonetheless.

You can achieve this using the "Custom PHP code" option for the Page Reference fields, but your site editors will need to save the page after making a selection in each Page Reference field in order for the selected items to be removed from the options of the other fields. Example hook in /site/ready.php: $wire->addHookAfter('InputfieldPage::getSelectablePages', function(Hookevent $event) { $page = $event->arguments(0); // The page being edited if($event->object->hasField == 'colours') { // Exclude options selected in field colours_2 $event->return = $event->pages->find("template=colour, id!={$page->colours_2}"); } if($event->object->hasField == 'colours_2') { // Exclude options selected in field colours $event->return = $event->pages->find("template=colour, id!={$page->colours}"); } }); Result in Page Edit:

This part doesn't look quite right for a couple of reasons... Firstly, the value of a repeater field is a PageArray even if the field is empty, so is_null() is never going to return true regardless of whether there are any repeater items. Secondly, if film_days is a repeater then you have to loop over its value - you can't get a field value of a child repeater item with $p->film_days->film_times So for that section of code I think you want something like: // remove all the old data (verbose) if($p->film_days->count()) { foreach($p->film_days as $film_day) { if($film_day->film_times->count()) { $film_day->of(false); $film_day->film_times->removeAll(); $film_day->save(); } } $p->film_days->removeAll(); $p->save(); } ...and to shorten it I don't think you need to worry about removing film times in film days you are about to also remove - just remove the film days and the film times will be gone too: // remove all the old data if($p->film_days->count()) { $p->film_days->removeAll(); $p->save(); }

Thanks @eelkenet, fixed in v0.1.4.

@breezer, like I said, your issue is not related to this module and you can confirm this by uninstalling TemplateFieldWidths. But your admin layout looks non-standard - compare with my screenshot above which does not have the grey background or space between inputfields. Maybe this is caused by some non-default option in AdminThemeUikit or you have interference from some non-core CSS somewhere.

Are we talking about layout issues in the "Field widths" field that TemplateFieldWidths adds to the Edit Template screen... ...or layout issues when you are editing a page/profile? Because TemplateFieldWidths doesn't have anything to do with the latter - the module just adds a quicker way to define field widths. You can check by uninstalling TemplateFieldWidths and seeing if you still have layout issues when editing a page/profile. If it's the latter problem you could ask a question one of the main support forums, but also check this loooong GitHub issue about column widths in AdminThemeUikit: https://github.com/processwire/processwire-issues/issues/480 Personally I recommend the following config option: Modules > Core > AdminThemeUikit > Layout + interface > Inputfield column widths > Percentage-based widths

Sounds like a CSS box-sizing issue. Are you using an unmodified core admin theme? All three core admin themes apply box-sizing: border-box to all elements so I'm puzzled why that wouldn't be working in your case. Maybe you can use your browser dev tools to investigate?

An updated version supporting both GitHub and GitLab: (not sure if the GitHub authentication works because I don't have the paid account needed in order to create a private repo) Sure, that's fine.

For those interested, here is a proof-of-concept Process module for parsing a module version number from a GitLab repo, public or private (if you have an access token). For demonstration there is a form for entering the module info and displaying the retrieved version, but for real usage you would send the module info to the Process page by POST and get the version number back in an AJAX response. Form... ...and with version number returned...