Robin S

If I have a variable that might be a Page or a PageArray, is there an elegant way to standardise to a PageArray? In other words, if $foo is a Page convert it to a PageArray containing just that one page while keeping the variable name. I know how to do it in several steps, but I feel like I've seen a nice one-liner somewhere, maybe in a module by @adrian or @kongondo?

Inputfield::renderReady was made hookable as Inputfield::renderReadyHook in PW 3.0.44. So the module could be updated to hook after InputfieldPage::renderReadyHook instead of before InputfieldPage::render - then it will work with repeater fields. That would add a requirement of PW >= 3.0.44, or else the module could check the PW version and hook different methods depending on the version.

The issue is that PW's .htaccess file contains mod_rewrite rules that get executed before any mod_alias redirects. This article explains: So that advice applies here - it's better to do redirects using mod_rewrite so that you can use the [L] flag to prevent other rewrite rules affecting the redirect.

I understand a little better now, but your usage is not how view permissions are intended to be used. Suppose you had a different setup for storing a user's date of birth: a text field for day and month, and a text field for year. I'm not suggesting that you do this - it's just to illustrate how view permissions typically work. In this alternative setup you might apply view permissions for the year field - so it would or wouldn't be viewable depending on role. But in your setup the "hide_year_of_birth" field is not a field that it is useful to limit the viewing of, because it only holds a 1 or a zero and not the actual value you want to hide (the year of birth). Hiding the checkbox field just confuses things IMHO, and would cause problems if any of the users with view restrictions need to edit the "hide_year_of_birth" field in their own profile (you can't edit a field that you can't view). I think instead you should create a new custom permission "view_year_of_birth" and apply it to the relevant roles. Then check for that permission (and the "hide_year_of_birth" value) to determine how the date field should be formatted.

New relevant module here:

Checkbox Reversed Modifies InputfieldCheckbox so that it shows the reverse of its true value. The checkbox will be unchecked when the field value is 1 and checked when the field value is not 1. Background The core FieldtypeCheckbox does not have a setting that allows a checkbox to be checked by default. One reason for this is that only a checked field saves a value to the database. An unchecked field does not save "0" to the database, but rather does not save any value for the field at all. Therefore there is no way to distinguish between a new field that has not yet been saved (and therefore could potentially get a default checked state) and a field that has deliberately been saved as unchecked. Because of this you sometimes have to use a checkbox in the opposite way than you would like. Suppose your client has requested a checkbox labelled "Bootylicious" that will be checked by default. This isn't possible with FieldtypeCheckbox so instead you have to convince them that a checkbox labelled "Not bootylicious" that is unchecked by default is just as good. This alternative will achieve the same thing, but it's not ideal. A solution This module doesn't change the limitations of the core checkbox field, but it provides a workaround that allows you to show the checkbox with the desired default state and label. So in the example above you would still name the field "not_bootylicious" (otherwise it could get confusing in your template files) but you can label the field "Bootylicious" and the checkbox will appear checked when its true value is actually unchecked, and vice versa. This allows new pages to show the checkbox checked by default. Clear as mud? Usage Install the Checkbox Reversed module. For any Checkbox field where you want the inputfield to show the reverse of its true value, activate the "Reverse the checked state of this inputfield?" option in the field settings. https://github.com/Toutouwai/CheckboxReversed http://modules.processwire.com/modules/checkbox-reversed/

Not sure I understand exactly what you're asking, but InputfieldSelect (and other related inputfields such as AsmSelect) has the addOption() method. So if you wanted your selectable options to be derived from all the pages using the basic-page template you could do this: $basic_pages = $this->pages->find("template=basic-page"); foreach($basic_pages as $basic_page) { // Page ID is value, page title is label $field->addOption($basic_page->id, $basic_page->title); }

On the topic of searchability of encrypted fields, as long as the number of encrypted pages you want to search across is not too huge you can load the pages to a PageArray and then search the PageArray. Using the auto-join tip mentioned recently here by @thetuningspoon... $decrypted = $pages->find("template=some_template", ['loadOptions' => ['joinFields' => ['encrypted_field_name']]]); $items = $decrypted->find("encrypted_field_name%=foo");

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.