Robin S

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?

Is there a WireArray equivalent of PHP's array_search() function? In other words, if I have a value and I want to know the key of that value (if any) for a given WireArray, how can I do that? I checked the WireArray docs but didn't find any equivalent, which surprised me because array_search() is a pretty commonly used function. Would the only way be to convert the WireArray to a plain PHP array with getArray()?

As before, you can't easily modify ProcessPageList for this purpose. But you can use Lister (Pages > Find). So in your case you would filter according to some parent or some template, plus filter by "title starts with" some character. I have a module under development that will allow for a list/tree that dynamically changes the selector used by Lister. Not sure when it will be ready but that might end up being helpful for your scenario.

Yeah, that module wouldn't really be practical if you need more than one or two virtual parents. The Virtual Parents module was an experiment to answer the question "To what extent is it possible to trick ProcessPageList into showing a page structure that isn't real?" And now that I've tried it I can answer with "To only a very limited extent". ProcessPageList just isn't designed to support anything other than the real page tree and forcing it do otherwise is pretty painful. There have been several requests for a way to browse an alternative page structure. It will require a module that builds its own tree from scratch and doesn't rely on ProcessPageList. It's on my to-do list but it will be challenging and I'm not sure when I'll get to it. And bear in mind too that any module like this will come with other limitations - for instance, it wouldn't be possible to sort or move pages like ProcessPageList can because the page structure shown might have no resemblance to the real structure.

@adrian, I created a pull request for adding support for Repeater Matrix to the "Copy Repeater Items to Other Page" action. It only required a small modification to the field select options so I thought it best to keep this within the existing action rather than create a new action just for copying Repeater Matrix fields. I thought about allowing all fieldtypes that extend FieldtypeRepeater but decided it would be better to add fieldtypes on a case-by-case basis just in case someone has a custom fieldtype that extends FieldtypeRepeater in some weird and wonderful way that wouldn't be compatible with the action. I also added a couple of other enhancements to the action - failure conditions for if the selected repeater field doesn't exist on the source or destination pages (previously the action reported a success in those cases). And copying repeater items now also copies any files or images included in the repeater items. One last thing I added, to the module itself this time, is a link to the module config settings in the notice that advises that new actions are available. I think it would also be handy to have a link the config settings in the process page - I often want to jump there to adjust allowed roles and the "in menu" option. I didn't include this in the pull request though - just something for you to consider.

@Zeka, maybe you can use the filename, prependFilename or appendFilename properties of the TemplateFile to limit where your hook applies. E.g. $wire->addHookAfter('TemplateFile::render', function(HookEvent $event) { $template_file = $event->object; $proceed = false; foreach($template_file->appendFilename as $filename) { if(substr($filename, -9) === '_main.php') $proceed = true; } if(!$proceed) return; // Your code... }); I'm curious - what's your reason for hooking after TemplateFile::render? If you are targeting non-admin template files inside your /site/ why wouldn't you include whatever logic you need inside the template files rather than via a hook?