Leaderboard

EDIT: ************* Note that this OP relates to the original version of the module. Version 0.0.19 is now published to the modules library at https://processwire.com/modules/fieldtype-measurement/. As well as many bug fixes and small enhancements, it now also includes an 'in-field' interactive conversion feature and dependent-select in the config. See the readme on the module page for up-to-date details and see this post for a bit of a demo. ************* This fieldtype and inputfield bundle was built for storing measurement values within a field, rendering them in a variety of formats and converting them to other units or otherwise modifying them via the API. The API consists of a number of predefined functions, some of which include... render() for rendering the measurement object, valueAs() for converting the value to another unit value, convertTo() for converting the whole measurement object to different units, and add() and subtract() for for modifying the stored value by the value (converted as required) in another measurement. In the admin the inputfield includes a checkbox (which can be optionally disabled) for converting values on page save. For an example if a value was typed in as centimeters, the unit was changed to metres, and the page saved with this checkbox selected, said value would be automatically converted so that e.g. 170 cm becomes 1.7 m. A simple length field using Fieldtype Measurement and Inputfield Measurement. Combination units (e.g. feet and inches) are also supported. Please note that this module is 'proof of concept' at the moment - there are limited units available and quite a lot of code tidying to do. More units will be added shortly. See the GitHub at https://github.com/MetaTunes/FieldtypeMeasurement for full details and updates.

The way I've done things like this is to create a text field, use a hook to add a sort code to that field, then set each relevant parent template to sort its children using that field. The sort code would be whatever you'd normally sort by, but with a prefix that depends on whether the page has children or not. So, I'd use something like the following (not tested) in ready.php, here assuming you'd basically sort on title: $this->addHookAfter('Pages::saveReady', function($event) { $page = $event->arguments[0]; if(in_array($page->template, array('template1', 'template2', 'template3'))) { $page->of(false); if($page->numChildren() > 0) { $sortcode = "A-" . $page->title; ) else { $sortcode = "B-" . $page->title; } $page->set('sortcode', $sortcode); } }); Of course, you could use a hook in a module instead. And you can use the same basic technique to get just about any kind of sort order you want.

I'm glad to have found a really good answer to my question elsewhere here in the forum, thank you so much, kongondo. I should stop thinking too complicated, learn something more, an Array, a PageArray ,.. ? It's processwire after all .. It only needed a small change: instead of "name" it was set to "hasField", in my case.

Personally I wouldn’t use a hook for this. I would use a custom page class called EventPage and put the method in that. See https://processwire.com/blog/posts/pw-3.0.152/#new-ability-to-specify-custom-page-classes

Yes, I noticed that too in the post https://processwire.com/talk/topic/26947-craft-cms-and-processwire-– a-comparison/?do=findComment&comment=222902 (I assume this is the one you mean), although the exact statement is "borderline deprecated". I too was going to comment because language alternate fields are really useful and I make good use them. It's not just image fields, but other non-text field types. For example, there might be a checkbox that can take values specific to each language, or a localized URL for each language, or different attached files (e.g. PDFs in each language). In general, language-alternative fields become really valuable when producing different versions of output for each language, rather than simply having translations of text. Another purpose for which language-alternate fields can be better, even for text fields, is when building interfaces and outputs for translators - for example, if in the admin one needs to display versions of text in different languages side by side, or grouped in fieldsets by language. So from me it's a big vote for keeping language-alternative fields undeprecated!

@rick messaged me asking for advice about how to use dependent selects in a module config. That is, where the options of one select change depending on what is selected in a another select. I thought others might also find this info useful so I've put together a demonstration module: https://github.com/Toutouwai/DemoDependentSelects The general idea is that the dependent (target) select needs to include all the possible options, and then the options are hidden or shown by JavaScript depending on what is selected in the source select. See the source code for comments.

I have no idea why you have such a setup but anyway, here goes. As per the instructions, your Hook needs to return a PageArray. This is untested: $wire->addHookAfter('InputfieldPage::getSelectablePages', function($event) { if($event->object->name == 'result_judge_challenge') { $page = $event->arguments('page'); $event->return = $page->parent->parent_multi_page_field;// this should return a PageArray } }); You might want to add checks to see if the parent page actually has items in its page field.