Robin S

Page List Auto Expand Automatically expands the next adjacent page when moving a page in Page List. Usage As you are moving a page in Page List, if you position the yellow move placeholder above a Page List item for a configurable period of time (default is 1000 milliseconds) then that item will expand, allowing the moving page to be dropped as child page. Configuration In the module config you can set the delay before the Page List item adjacent to the move placeholder will be automatically expanded. Restricting the module to certain roles If you want to restrict the module functionality to only certain roles then create a new permission named page-list-auto-expand. If that permission exists then a user's role must have that permission or the module will not have an effect in Page List. https://github.com/Toutouwai/PageListAutoExpand https://processwire.com/modules/page-list-auto-expand/

Tracy Debugger's Console panel can execute any PHP that you would otherwise run from a .php file. You can type code directly into the Console window, or if you prefer to code in your IDE you can save .php files to /site/templates/TracyDebugger/snippets/ and then run them from the Console panel. I also like to use custom actions for Admin Actions for more complicated or lengthy code, or for when I want to set various parameters using PW inputfields.

Sometimes you need to execute a slow task after some event occurs in the PW admin, and normally you have to wait for this task to finish before you can continue using the admin. This is because PHP is "blocking", meaning that while one thing is executing nothing else can execute. There are potentially lots of different kinds of tasks that could be slow, but just as an example suppose you want to generate resized variations of images on a page, and there are a lot of images. You might have a hook like this so that any non-existing variations are created when the page is saved: $pages->addHookAfter('saveReady', function(HookEvent $event) { /** @var Page $page */ $page = $event->arguments(0); // When a gallery page is saved if($page->template == 'gallery') { // Create an image variation for each image foreach($page->images as $image) { $image->size(1200, 1200); } } }); When you save a gallery page in the PW admin, the admin will be unresponsive and will only load again after all the variations have been created. I wanted to find a way for slow tasks to be triggered by events in the PW admin and for the website editor not to have to wait for the task to finish before continuing with other work in the admin. Inspired by this StackOverflow answer I came up with the following solution that seems to work well. Using the image variations task above as an example... First we make use of the URL hooks feature to set up a URL that can trigger tasks to run when it is loaded: // A URL that will trigger tasks when loaded $wire->addHook('/run-task/', function($event) { $input = $event->wire()->input; // A simple check to avoid unauthorised access // You could implement more advanced checks if needed if($input->post('key') !== 'cTdPMBQ7x8b7') return false; // Allow the script to keep running even though we have set a short WireHttp timeout ignore_user_abort(true); // The "create variations" task if($input->post('task') === 'create-variations') { $page_id = (int) $input->post('page'); $p = $event->wire()->pages->get($page_id); // Create an image variation for each image foreach($p->images as $image) { $image->size(1200, 1200); } return true; } return false; }); Then in the Pages::saveReady hook we use WireHttp to load that URL and post parameters that define what task to run and anything else needed for the task (in this case the ID of the page that has been saved). $pages->addHookAfter('saveReady', function(HookEvent $event) { /** @var Page $page */ $page = $event->arguments(0); // When a gallery page is saved if($page->template == 'gallery') { // Load the /run-task/ URL using WireHttp $http = new WireHttp(); // Set a short timeout so we don't have to wait until the script finishes // Timeout values shorter than 1 second can be tried once a core issue is fixed // https://github.com/processwire/processwire-issues/issues/1773 $http->setTimeout(1); $url = $event->wire()->config->urls->httpRoot . 'run-task/'; $data = [ 'key' => 'cTdPMBQ7x8b7', 'task' => 'create-variations', 'page' => $page->id, ]; $http->post($url, $data, ['use' => 'curl']); } }); By doing it this way the task runs in a separate request and the website editor doesn't have to wait for it to finish before they can continue working in the PW admin.

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');