Robin S

Are there any JS errors in the browser console? I just tested it with embed option C and it's working for me here.

Hi @adrian, My standard settings when using this module are "Automatically rename the name field to match the title" and "Initial differences protected" and this generally works great for me - the title and page name are always kept in sync except when I have deliberately changed the name to something that I don't want automatically changed. But one case that has been catching me out is when a page is cloned using the core ProcessPageClone module. When this is done the clone gets a title in the format "Original page name (copy)" but the page name gets the format "original-page-name-1". So from that point on the page gets treated as a case of "initial differences protected" and therefore the name doesn't get updated when the title is changed. Do you think it would be a worthwhile addition to Page Rename Options to try and detect this scenario somehow so that it doesn't count as a case of "initial differences protected"? I'm not sure what the best way to do this would be, but one approach would be to hook after ProcessPageClone has executed and set the page name from the title (e.g. "original-page-name-copy") so that it doesn't count as an initial difference. Update: one more thing... I reckon it would be cool if the module added a button to the name inputfield in the Settings tab which when clicked would sync the name to the current title (via JS I guess).

A new addon action module for Admin Actions created to meet this need:

Replace Home An action for the Admin Actions module for ProcessWire CMS/CMF. The action replaces the template and content of the home page with that of a selected page. Sometimes there is a need to develop a new home page while keeping the existing home page in place until the new version is ready and approved. Then you want to apply the new home page, but this is not so easy to do in ProcessWire since home is a special page that cannot simply be replaced by another page. What the action does Removes all the fields from the home template, which simultaneously deletes all the content from the home page. Adds all the fields from the selected source page template and applies any template-specific overrides. Sets the home page field values to match the source page. Updates all file and image URLs in any textareas so they point to the home page files rather than the original source page. What the action doesn't do The action does not modify the home template file. You will probably want to update the home template file immediately after running the action (e.g. copy/paste the code of the source page template file). The action does not automatically delete the source page – that can be done manually after you have confirmed that the action was successfull. Warning This action is destructive! It deletes content/files/images from the existing home page. In addition to the automatic Admin Actions database backup you should create a backup of /site/assets/files/ before running this action, and consider also making a manual database backup for extra safety. Usage Install the Replace Home module. Visit the Admin Actions config screen and enable the "Replace Home" action for the roles who are allowed to use it. Create file system and database backups – see the warning section above. Navigate to Admin Actions > Replace Home, select the source page whose template and content will replace the home page, then execute the action. Update the home template file if needed. Screenshot https://github.com/Toutouwai/AdminActionsReplaceHome https://processwire.com/modules/admin-actions-replace-home/

PW doesn't support that kind of sorting in $pages->find(), but you could use the FindMerge module and do something like this: $base_selector = "title=foo"; $selectors = [ "$base_selector, template=template1", "$base_selector, template=template2|template3", "$base_selector, template!=template1|template2|template3", ]; $pagination_limit = 20; $results = $pages->findMerge($selectors, $pagination_limit);

Probably it applies to the strikethrough to any non-core fieldtypes because it can't guarantee 100% compatibility. Did you try ticking the checkbox anyway? It seems to work when I did some quick testing.

The forum search supports specific syntaxes depending on how you want multiple words searched, and there are expandable search options too. It explains some of the options after you do a search. That's an unrelated search feature. The forum is powered by IP.Board and the blog posts are powered by ProcessWire.

Cool tip, thanks! As an aside, are you using findRaw() to get your data for the options? My experience lately is that when I make use of findRaw() I rarely need to cache this sort of thing because it's so much faster than loading whole Page objects.

There is a $config setting that lets you specify roles that are not allowed to log in. /** * Names (string) or IDs (int) of roles that are not allowed to login * * Note that you must create these roles yourself in the admin. When a user has * one of these named roles, $session->login() will not accept a login from them. * This affects the admin login form and any other login forms that use ProcessWire’s * session system. * * The default value specifies a role name of "login-disabled", meaning if you create * a role with that name, and assign it to a user, that user will no longer be able * to login. * * @var array * */ $config->loginDisabledRoles = array( 'login-disabled' ); So in /site/config.php you could temporarily have something like: $config->loginDisabledRoles = ['your-role-name'];

You'll want to sanitize search input before using it in a selector string. ? And here's an alternative way you could search across the FAQ items: $search = $sanitizer->selectorValue($input->get('search')); $faqs = new PageArray(); foreach($page->faqs_groups as $group) { $faqs->add($group->faqs); } $results = $faqs->find("title|body*=$search");

@BrendonKoz, you can use the hook below to target the children() selector used in PageListSelect/PageListSelectMultiple and remove the "status" clause that allows unpublished and hidden pages. Because those inputfields use ProcessPageList the tricky part is only affecting the inputfields and not the main page tree. After some digging I found that you can distinguish these cases by a "labelName" GET variable. $wire->addHookBefore('ProcessPageList::find', function(HookEvent $event) { $selector = $event->arguments(0); $name = $event->wire()->input->get('labelName'); if($name === 'your_page_reference_field_name') { $selector = str_replace(', status<9999999', '', $selector); $event->arguments(0, $selector); } }); Before: After:

Hi @adrian, The "Delete Unused Templates" action is throwing an error for me in recent PW versions: Maybe related to this change mentioned in the 3.0.210 release blog post? Update: adding an if($fieldgroup) test to the action seems to resolve it... if($fieldgroup) $this->wire('fieldgroups')->delete($fieldgroup);

I created a GitHub issue: https://github.com/processwire/processwire-issues/issues/1669

Your selector string will be "id=page.name_of_your_repeater_field, check_access=0". The "check_access=0" is so that it works for non-superusers. In the example below I'm using a repeater field named "test_repeater". If you repeater doesn't include the title field you'll want to choose something different in the "Label field" setting.

@MarkE, besides the autojoin setting in admin that's mentioned in Ryan's post, you can also set autojoin programmatically when you get one or multiple pages. For multiple pages ("find") see the blog post: https://processwire.com/blog/posts/find-faster-and-more-efficiently/ And if you only want a single page ("get") then you can use "joinFields" in the $options argument, e.g. Edit: it seems you can use the "field=" syntax described in the blog post with $pages->get() and $pages->findOne() too...

Field values for a page are loaded from the database on demand (i.e. as you request them) unless you have set them to be "autojoined":

I agree that it's not a major issue, but it would still be nice to slim down the total TracyDebugger size because it's a module that receives frequent updates (thanks! ❤️) and so I'm downloading it regularly. Ace makes up approximately 80% of the total TracyDebugger size. Could it maybe be loaded via a CDN? https://cdnjs.com/libraries/ace Also, I've heard good things about Monaco (possible replacement for Ace): https://cdnjs.com/libraries/monaco-editor

@gebeer, the findReady method is working for me: $wire->addHookAfter('ProcessPageSearch::findReady', function(HookEvent $event) { $selector = $event->return; if($event->wire()->user->isSuperuser()) return; // If the selector looks like it comes from a particular autocomplete Page Reference field // (I wish this method provided a better way of working out where the selector is coming from) if(strpos($selector, 'parent_id=1329, templates_id=62,') === 0) { $selector .= ", include=all"; $event->return = $selector; } });

@eelkenet, cool that you were able to find a solution! Here's another way you could add disabled section items into the Page Reference AsmSelect using the PW API. It avoids getting each page individually in a loop so probably a bit more efficient. // Add dummy items to the selectable pages to act as section headings $wire->addHookAfter('InputfieldPage::getSelectablePages', function(HookEvent $event) { /** @var InputfieldPage $inputfield */ $inputfield = $event->object; $field = $inputfield->hasField; $selectable = $event->return; $t = null; $i = 1; if($field && $field->name === 'my_page_reference') { foreach($selectable as $p) { if($p->template->name !== $t) { $section = new NullPage(); $section->id = "section{$i}"; $section->title = mb_strtoupper($p->template->label) . ' ––––––––––––––––––––'; $selectable->insertBefore($section, $p); $t = $p->template->name; $i++; } } $event->return = $selectable; } }); // Set the dummy options to disabled $wire->addHookAfter('InputfieldAsmSelect::renderReadyHook', function(HookEvent $event) { /** @var InputfieldAsmSelect $inputfield */ $inputfield = $event->object; $field = $inputfield->hasField; if($field && $field->name === 'my_page_reference') { foreach($inputfield->options as $value => $label) { if(substr($value, 0, 7) === 'section') { $inputfield->addOptionAttributes($value, ['disabled' => 'disabled']); } } } });

You could apply the purify sanitizer when the field value is saved by hooking InputfieldTextarea::processInput(). But looking at it another way, it isn't really possible to guard against a malicious superuser - they could destroy the site in any number of ways. Therefore you have to accept that superuser is a role for trusted users only.

Hi @tomasanjosbarao, I don't think I understand your post. If you can provide steps to reproduce some problem with the module I'm happy to investigate.

@eelkenet, unfortunately I think you have a difficult road ahead if the optgroups are really important to your use case. Probably you would need to create your own custom inputfield using something like Selectize or Select2. It's a shame, but AsmSelect doesn't support optgroups. It's not adding the optgroups to the underlying select markup that's the big problem, it's that AsmSelect doesn't account for optgroups when it builds the "fake" select from the underlying hidden select element. There was a pull request to add optgroup support the standalone jquery-asmSelect back in 2015 but it was never merged into either the standalone version or the InputfieldAsmSelect included in the PW core. You might think that Selectize would be a simple solution because it supports optgroups out of the box and PW already provides an API for Selectize inputfields via InputfieldTextTags. But unfortunately no optgroup support was included in InputfieldTextTags because the addTag() and addOption() methods only support individual options without the ability to add options in a group as per InputfieldSelect::addOption(). And as far as I know you can't do something like supply the entire select markup to InputfieldTextTags. P.S. the title of the topic is bit confusing because InputfieldSelectMultiple is a different thing to InputfieldAsmSelect. InputfieldSelectMultiple does support optgroups - you can add them via InputfieldSelectMultiple::addOption().

Does the template in question explicitly allow the role to edit, or is the access inherited from parent pages? If you haven't explicitly set the template access I think the likely solution is to set that access. You have to remember that Lister is not creating its list by individually checking the access of every page and every page's parents. Rather it's creating a selector string that produces the list. I can see some code in Lister that looks like it does take inheritance from the immediate parent into account if there is a "parent=" item in the Lister filters. But I think it would be more practical for you to explicitly set the edit access on templates that you want a role to be able to edit. Personally I always set the access for every template in my site because I want to be sure I've made a conscious decision to control that access rather than let it potentially drift down unnoticed from some parent. I've never understood what reason there could be to not explicitly set the access controls on a template (maybe someone can explain the scenario where that is useful?) Getting off topic now, but I have a module that makes it quick to check and set the access controls on templates across the site - I'll write up the readme and release it soon.

By default Lister should automatically show unpublished pages that the user is allowed to edit as long as the Lister filters are limiting by template. So if your user is allowed to edit template "basic-page", and the Lister filters include "template=basic-page" then the user will be able to see unpublished pages (without needing to have a specific "include" item in the Lister filters). But if you don't have a "template=" item in the filters, or you are filtering by multiple templates and the user doesn't have edit permission for all the included templates, then the user will not be allowed to see unpublished pages. See here for the relevant code.

This isn't the first star rating module for ProcessWire, but I wanted some particular config options and to have the inputfield be usable within FormBuilder. FieldtypeStars The inputfield of FieldtypeStars uses a star rating interface to set a float value. The fieldtype extends FieldtypeFloat. The inputfield has no external dependencies such as jQuery or Font Awesome and can be used in FormBuilder. Config Using InputfieldStars in FormBuilder In order to add a Stars field to a FormBuilder form you must first enable "Stars" in the "Allowed Input Types" field in the FormBuilder module config. https://github.com/Toutouwai/FieldtypeStars https://processwire.com/modules/fieldtype-stars/