Robin S

This is brilliant! Definitely deserves its own thread in the modules sub-forum. I only tested it briefly so far but I'm amazed at how fast it is - I thought the decryption would cause a noticeable delay.

You can set more advanced labels in a Page Reference field by using a hook. Not sure if there's a better way but here's how I do it. In your Page Reference field settings, choose "Custom format" for the "Label field" setting, and in the "Custom page label format" enter anything you want so long as it is unique to that field, e.g. pwrocks Then in /site/ready.php $wire->addHookAfter('Page::getMarkup', function(HookEvent $event) { $page = $event->object; // Each page that appears in the Page Reference field $key = $event->arguments(0); if($key !== 'pwrocks') return; // the label format specified for the Page Reference field // Now build whatever string you want to show using $page, $page->getForPage(), etc $string = 'Your string here'; $event->return = $string; });

Not saying it wouldn't be a nice feature to add, but if you know the start of the option you are looking for you can find an option in a standard select by just typing into the select box. On Windows anyway.

You can sort them in a saveReady hook. In /site/ready.php: $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); // If the page has the relevant template... if($page->template == 'exhibition') { // Sort the Page Reference field by title $page->works_id->sort('title') ; } }); This of course prevents you from applying a manual sort to the field, and does affect the sort order of the field value when you get it in your template. But it sounds like you are specifying a different sort (chronological) there anyway so that won't be an issue.

I rushed over the the PW repo, all geared up to star... oh, I already did that. Wish I could star it twice.

Would be cool to add support where possible. Not sure how you've handled the AsmSelect limit in the as-yet-unreleased AOS update, but maybe part of the JS could be broken off into a piece that is generic to all Page Reference inputfields. It would identify the underlying form element that contains the actual field value, and on change it would check if the limit is reached. If so it would add a class to inputfield container, and trigger some event for the container, e.g. 'limitReached'. If you go that way others can contribute pull requests for the remaining Page Reference inputfield types without reinventing the wheel for the limit check. I'd be happy to contribute here.

Awesome! Do you reckon you could do something similar for Page Autocomplete?

Why are you placing view restrictions on the "hide_year_of_birth" field? Isn't it the "birthday" field you want to limit view access for?

A general coding question I've wondered about for a while but never got around to asking until now. Suppose I'm writing some code in a template file, and I get some value from the database... echo $page->parent->title; Now later on in my template I want to use this value again, so my template file is now... echo $page->parent->title; // More code here... echo $page->parent->title; Is PW going to go back to the database to get this value? Or is it automatically kept in memory so that only the first usage results in a trip to the database? In most circumstances where I do this I would tend to put the value in a variable and then reuse the variable... $parent_title = $page->parent->title; echo $parent_title; // More code here... echo $parent_title; ...but if I didn't and instead did it like the previous example, would there be any performance penalty? Is there any documentation or forum post that talks about how PW handles this sort of thing?

That's added by InputfieldPage.js here. It's so that there isn't an option pre-selected in the inputfield, which is a good thing normally. If you want to remind users that they need to select an option for this field you can make the field required. I guess you could add some custom JS to remove the empty option if you really don't want it.

The suggestion here worked for me. If your CKEditor field is named "formula", create a file "config-formula.js" in /site/modules/InputfieldCKEditor/ with contents: CKEDITOR.editorConfig = function( config ) { config.keystrokes = [ [ 13 /* Enter */, 'blur'], [ CKEDITOR.SHIFT + 13 /* Shift + Enter */, 'blur' ] ]; };

Use the "Custom find" or "Selector string" options to define the selectable pages for the field, and specify a "sort" in the selector, e.g. "sort=title".

Nice tip! You can also turn autojoin on and off for selected fields whenever you need via API methods $field->addFlag(Field::flagAutojoin) and $field->removeFlag(Field::flagAutojoin).

It's just occurred to me that this opens up a lot of possibilities for getting dependent selects to work in situations where they otherwise wouldn't. Inside repeater items, or doing things like what you are trying to do @Zeka. You can hook before ProcessPageSearch::executeFor and manipulate the values in $input->get to make up whatever selector you want. Or alternatively hook after and manipulate what is returned in the matches array. To only affect requests coming from a dependent select you could look for the presence of limit=999 - not sure if that's used in other calls to the method though.

I'm pretty sure this part won't work. The value of the input in a Page Reference inputfield is an ID (or IDs for a multiple Page Reference field). That is what gets passed to the selector to find selectable pages for the dependent Page Reference field. So "page.product_shop_categories.name" is going to translate to something like "1234.name" which isn't going to work. If you want to debug this some more you can hook ProcessPageSearch::executeFor, which is what the dependent selects JS calls via AJAX. For example: $wire->addHookAfter('ProcessPageSearch::executeFor', function(HookEvent $event) { $get_vars = $this->input->get; $return = $event->return; $decoded = wireDecodeJSON($return); bd($get_vars, 'get_vars'); bd($decoded, 'decoded'); });

If these models/artists need to be able to edit their information then they must be created as PW users so they can log in. You can use an "Approved" checkbox field in the user template, or alternatively create an "Approved" role that may be added to the user, to determine which users are approved. The Login Register module could help with this project. See the blog post that introduced it. You'll probably want to customise Login Register (with hooks or whatever) for things like: 1. Show different fields in the register form depending on if Model or Artist is selected. 2. Maybe apply different role to new user depending on if Model or Artist is selected. 3. Show different fields in profile edit form depending on if Model or Artist is selected. If you get stuck on any of these things I'm sure you'll find help here in the forums. I haven't used Login Register myself. If information from the user profile is shown publicly on the front-end you could explore the possibility of using a different parent for users. Or you could use a single page for all profiles, pulling in the data for the relevant user via a Url Segment. I'd probably go for the latter myself. If all the users are stored under the Admin > Access > Users (as they are by default) then your client will be approving/activating Models and Artists via the Users lister. You can add a filter to the lister to make it easy to find unapproved users. Or maybe use Lister Pro to create a custom users lister showing unapproved users.

I mean inside a repeater field. Technically it will work there, but not in a useful way. The issue being that the names of inputfields inside a repeater item have a suffix according to the ID of the repeater page. So you would have to include the suffix in the selector for the dependent Page Reference field and therefore it would only ever work inside a single repeater item. Should be no problem if the pages that make up the selectable options in a Page Reference field happen to be repeater pages. They are treated the same as any other page inside the field.

$sanitizer->text(nl2br($your_text), ['allowableTags' => '<br>']);

Do you have the AutoExportTemplatesAndFields module installed by any chance? There are reports in the the support topic that it can cause issues with repeater fields.

@Macrura, glad you got it working eventually. I intend to work on an upgrade to this module sometime soon. Hope to add a feature allowing all dialog options to be configured from within a single hook, which will make things easier (for those comfortable writing code anyway). Will also look at adding some clarification that an attribute must first be declared before adding any of the "double underscore" enhancements.

I discovered Swoole via a Quora answer to the (silly) question "Will PHP die in 2018?". https://www.swoole.co.uk/ https://github.com/swoole/swoole-src It's way above my skill level so I only have the vaguest grip on what it's all about, but it sounds pretty wild. Just thought folks here might be interested in checking it out.

Here's one way to enforce only a single featured item while still enabling featured status to be set while editing an item (as opposed to using a Page Reference field on some other page to select a single featured item). In /site/ready.php... $wire->addHookBefore('InputfieldCheckbox::render', function(HookEvent $event) { $inputfield = $event->object; if($this->process != 'ProcessPageEdit') return; $page = $this->process->getPage(); // If this isn't the existing featured item... if($inputfield->hasField == 'featured' && $page->template == 'news_item' && !$page->featured) { // Add a note about the existing featured item $existing_featured_item = $this->pages->get("template=news_item, featured=1"); $inputfield->description = "Only one item may have featured status. Featuring this item will un-feature '$existing_featured_item->title'."; } }); $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); // If the "featured" checkbox is checked... if($page->template == 'news_item' && $page->featured) { // Remove the featured status of any other items $existing_featured_item = $this->pages->get("template=news_item, featured=1"); if($existing_featured_item->id) $existing_featured_item->setAndSave('featured', 0); } });

@OllieMackJames, just a note about Page Reference fields: Where you have a "single" Page Reference field... ...when that field has a page selected its value is a Page object. So rather than this... /* fill in pageid of page to be used for content homepage*/ if($page->id == 1 && $page->page2use4homepage) { $p = $page->page2use4homepage->id; $page = $pages($p); } ...you can just do this... if($page->id == 1 && $page->page2use4homepage) { $page = $page->page2use4homepage; }

I guess I should do the same. It's just that Google is so convenient. I can see some benefits in having some introductory documentation that skips over the details. The earlier documentation was a bit like that and it's still useful. But for the v3 API Reference I think the more comprehensive the better. Having detailed and comprehensive documentation is not only useful to current users but it also boosts PW's credibility for potential users, particularly for experienced devs who I'm sure would find PW a pleasure to use and could make some valuable contributions to the community. The richness of the API is something we should show off rather than hide.

Thanks @kixe! Why is this method undocumented I wonder? I'd love to know the criteria by which a method makes it into the API docs or not. I'd like to see all class methods documented. If the PhpDoc comments are already there (as they are in most cases) then where's the harm in making the information viewable in the API docs? @ryan?