Robin S

Yes, certain system pages are forced to the bottom of the list. See ProcessPageListRenderJSON.php

Hi @netcarver, When ModuleReleaseNotes is installed the main admin headline gets removed in the config screen for ProFields InputfieldCombo and this makes the form layout a bit off too (FieldtypeCombo is similarly affected). Without ModuleReleaseNotes: With ModuleReleaseNotes: I had a quick look and traced it back to the module's hook after ProcessModule::executeEdit but nothing in there leaps out at me as the cause of the problem. Do you have ProFields so you can try and replicate? Cheers, Robin.

In the newly released v0.3.0 you can also quickly toggle the "required" state of fields in a template, Repeater, etc, by clicking the asterisk icon next to the field label.

@Tintifax, Ryan has fixed the issue. So to get ProcessDatabaseBackups working as normal: download PW 2.0.220 again to get the latest commits, update the wire folder of your site, uninstall ProcessDatabaseBackups if it is already installed and then reinstall ProcessDatabaseBackups.

I can confirm the issue in PW 2.0.220. The problem seems to be with Modules::getModuleInfoVerbose(). I opened a GitHub issue here: https://github.com/processwire/processwire-issues/issues/1765

You could use a hidden field in the template to store the title of the first repeater item, similar to this: Or you could match the repeater page by sort position and then get the containing page for each matched repeater page. $items = $pages->find("template=repeater_areas, title=$area, page.sort=0, check_access=0"); $results = new PageArray(); foreach($items as $item) { // Get root page that contains the repeater page $result = $item->getForPageRoot(); // Maybe do some checks on $result page here, for example if you only want pages that have a particular template $results->add($result); }

I don't think there is anything about field templates that means they can't include a markup region. But you can't have nested markup regions (where your template output includes one markup region inside another markup region). So if you are using a markup region inside a field template you would not be able to render that field template inside another markup region, which is something you would often want to do. I think a better solution is to use a FilenameArray and add whatever JS files you need to it in your field template. In /site/templates/_init.php $config->siteJs = new FilenameArray(); In /site/templates/_main.php <?php foreach($config->siteJs as $jsFile): ?> <script src="<?= $jsFile ?>"></script> <?php endforeach; ?> In your field template $config->siteJs->add('/site/templates/js/myField.js'); Or you can follow the same general idea using an ordinary WireArray and include the whole "<script src..." string so you can optionally use "defer" or other attributes.

Welcome to the PW forums @Tenzing ? You can achieve this by setting the URL segments you want to $input before you render the page. E.g. $input->urlSegment1 = 'foo'; $input->urlSegment2 = 'bar'; echo $thepage->render();

If the field value is being set from a FormBuilder form field (e.g. send form submission to PW pages) then you will need to set the noTrim setting for the FormBuilder field too. Again, there is no config field for this but I expect you will be able to hook into the form rendering and/or processing and set noTrim=1. Ryan should be able to help with this in the FormBuilder subforum if you're not sure how.

I tested in 3.0.217 and when trying to rename a field to the same name as an existing field PW gave an error notice, did not change the field name, and no data was lost. So maybe it was a strange glitch, or it was an issue that was fixed between 3.0.165 and 3.0.217.

InputfieldText (and other inputfield types that extend InputfieldText such as InputfieldTextarea) has a "noTrim" setting that is false by default, which is what causes leading and trailing whitespace to be trimmed out of the field value. This setting isn't included in the config options for text fields (not sure why, perhaps because it's rarely needed) but you can add a config option for it with a hook: $wire->addHookAfter('InputfieldText::getConfigInputfields', function(HookEvent $event) { /** @var InputfieldText */ $inputfield = $event->object; /** @var InputfieldWrapper $wrapper */ $wrapper = $event->return; $field = $inputfield->hasField; // Only for inputfields that are associated with a Field object if(!$field) return; // Add checkbox field to config to control noTrim setting /** @var InputfieldCheckbox $f */ $f = $event->wire()->modules->get('InputfieldCheckbox'); $f->name = 'noTrim'; $f->label = 'No trim'; $f->label2 = 'Do not trim whitespace from the field value'; $f->checked($field->noTrim); if(!$field->noTrim) $f->collapsed = Inputfield::collapsedYes; $wrapper->add($f); }); This will add a "No trim" checkbox to text fields, and if you tick the checkbox the field value won't be trimmed. Result:

Are we sure Tracy is causing the error as opposed to only reporting the error? As in, maybe the session lock times out regardless of whether Tracy is installed, but without Tracy installed you never learn about it. The timeout is a configurable setting in SessionHandlerDB so maybe the solution is that if you expect to run tasks that can take longer than the 50 second default you increase that setting, or if the long task is triggered by your own code do a $session->close() immediately before the task. Or is the sort of exception thrown by SessionHandlerDB when the lock times out supposed to be more silent? There was a Tracy issue similar to that but it was fixed a while back: https://github.com/adrianbj/TracyDebugger/issues/58

Bummer about the Selectize issue. I think it might be the cause of this too: https://github.com/processwire/processwire-issues/issues/1736 A hook to substitute a textarea for the toolbar config without editing the core: $wire->addHookAfter('InputfieldTinyMCE::getConfigInputfields', function(HookEvent $event) { /** @var InputfieldWrapper $wrapper */ $wrapper = $event->return; $toolbar = $wrapper->getChildByName('toolbar'); $replacement = $event->wire()->modules->get('InputfieldTextarea'); $replacement->rows = 3; $settings = [ 'name', 'label', 'description', 'icon', 'textFormat', 'themeOffset', 'notes', 'value', ]; foreach($settings as $setting) $replacement->$setting = $toolbar->$setting; $wrapper->insertBefore($replacement, $toolbar); $wrapper->remove($toolbar); });

Hi @Laksone, welcome to the PW forums ? I think you're right that this is a bug - good find. Could you please open an issue in the GitHub issues repo so that Ryan becomes aware of it? Thanks!

You don't need a different field for this scenario. You can use template overrides for the field settings. In the field settings (Overrides tab): Then from the template settings, edit the field in template context:

Sounds like it would be a good case for a custom Page method (either added by hook or by custom Page class) that falls back to the core $page->get() when no value exists. $value = $page->getFromJson('some_field');

You can actually adapt that to a selector string that will allow you to use Page Autocomplete: In a Page Reference field selector string, "page" is a special keyword that PW converts into "the page that is open in Page Edit". This isn't documented anywhere as far as I know, but it would be good if it was @ryan.

You'll need to write this line as... } else if($dl->ext() == "doc" or $dl->ext() == "docx") { ...or else it will always evaluate as true regardless of the extension. A good candidate for rewriting as a switch statement too.

The core show-if can only work when the test relates to values that are contained in inputfields in the Page Edit form, (e.g. "some_field=foo"). Technically there is a field in Page Edit that relates to the parent - the "Parent" (parent_id) field on the Settings tab. But that inputfield is set to AJAX-load so the value isn't available to the inputfield dependencies JS. But you can use the Custom Inputfield Dependencies module to create show-if conditions that are evaluated by PHP rather than JS: https://processwire.com/modules/custom-inputfield-dependencies/ You would create a show-if condition like this:

Usually such things are the result of being logged in (probably as superuser) in one browser and logged out in the other browser. It looks like that's the case in your screenshots because I can see the Tracy debug bar in one screenshot and not in the other. So probably the difference is due to some access issue, where superuser has access to something that guests do not.

Yes, I do intend to create a new module similar to HannaCodeDialog that supports TinyMCE. But I don't have an estimated date for when it will be ready. For many of my modules, the situation has been that I work on them when I have a need for them myself. And I have quite a number of modules based on CKEditor that I use frequently and that would need to be redeveloped for TinyMCE before I personally can contemplate changing my RTE fields from CKEditor to TinyMCE. So I have quite a lot of work ahead of me and consequently I don't think HannaCodeDialogMCE is going to completed in the very near future.

There are a number of ways you could conditionally add CSS to the PW admin, but one simple way is to add this to /site/templates/admin.php (before the line that requires controller.php) if($user->hasRole('editor')) $config->styles->add($config->urls->templates . 'styles/admin-custom.css');

Another way you could do it... In my example the parent template is "countries" and the child template is "country", and there are 195 child country pages. Using the PageEditPerUser module the user is only allowed to edit country pages "Zambia" and "Zimbabwe": Page List before: The problem being that lots of uneditable pages are included, with the two editable pages being at the end of the 4th pagination. I'm not using Admin Restrict Branch here so (presumably) that's why all the non-editable pages are listed, but that doesn't matter for the purposes of this example. A solution is to add the following hook to /site/ready.php: // Only for a particular role if($user->hasRole('editor')) { $wire->addHookBefore('ProcessPageList::find', function(HookEvent $event) { $selector = $event->arguments(0); /* @var Page $page */ $page = $event->arguments(1); $user = $event->wire()->user; // If the parent template is "countries", restrict the children list to only the pages that the user may edit if($page->template == 'countries') { $selector .= ", id=$user->editable_pages"; $event->arguments(0, $selector); } }); } That fixes it so that only the editable child pages are shown, but the incorrect child count and unnecessary pagination controls are still visible: So the simplest thing is just to hide those things with some custom admin CSS only for the relevant role (if you're not sure how to do that something like this should work, with a check first for the user role). /* Adjust the parent template name to suit */ .PageListTemplate_countries > .PageListNumChildren { display:none; } .PageListTemplate_countries + .PageList > .uk-pagination { display:none; } .PageListTemplate_countries + .PageList > .PageListActions { display:none; } End result:

I don't think you can do that in a selector, but you could add a hidden "owner" field to the "inventory" template and then populate that on page save with the value from the last repeater item. So if "owners" is the repeater field and "owner" is a Page Reference field within the repeater that stores a user... $pages->addHookAfter('saveReady', function(HookEvent $event) { /* @var Page $page */ $page = $event->arguments(0); if($page->template == 'inventory') { $page->owner = $page->owners->last()->owner; } }); Then you can easily find pages like this: $myInventoryPage = $pages->get("template=inventory, owner=$user");

Not sure I understand the question exactly, but the general way to handle URL segments is in the template file. The template setting is just for if you only have one or two fixed segments or have some reason not to use the template file. So in your template file you just throw a 404 if the segment doesn't match your allowed segments, which could be defined dynamically. E.g. // Throw 404 if segment1 isn't in the array of allowed segments (which you could define dynamically) if($input->urlSegment1 && !in_array($input->urlSegment1, $my_allowed_segments)) throw new Wire404Exception(); // Throw 404 if there is more than one segment when there shouldn't be if($input->urlSegment2) throw new Wire404Exception(); // Now generate output according to segment, no segment, etc... Also see the docs here: https://processwire.com/docs/front-end/how-to-use-url-segments/#best-practices