Robin S

I recommend using a virtual host for each local project - it avoids little issues like this and will be more consistent with how the site will operate when migrated to a remote host. It's not difficult to set up virtual hosts manually, although if you use a tool like Laragon it's an absolute breeze because it automatically creates virtual hosts for every project in the document root: https://laragon.org/docs/pretty-urls.html

When a page is rendered by another page PW populates a "stack" of pages that called render in an $options variable. See Ryan's comment: So if a page is accessed directly and not rendered by another page then the page stack will be empty (in fact the $options variable will not be set). So you can put the following at the top of template files that should not be directly viewable but only rendered as part of another page: if(empty($options['pageStack'])) throw new Wire404Exception();

It's the infinitely useful Console panel in Tracy Debugger: https://adrianbj.github.io/TracyDebugger/#/debug-bar?id=console

This seems like it could be reasonable solution: disable session fingerprint when a site is on localhost. That way when developing locally the user agent is allowed to change without causing a logout. In /site/config.php: if(in_array($_SERVER['SERVER_ADDR'], ['127.0.0.1', '::1'])) { $config->sessionFingerprint = false; }

Thanks, makes sense. So a couple of solutions would be: Use an incognito window when working with dev tools device mode. Or set $config->sessionFingerprint = false in /site/config.php These are okay but still kind of annoying. The incognito solution is a bit less convenient than working within the current browser window and easy to accidentally forget when opening view links from Page Edit / Page List. And I wouldn't want to forget the sessionFingerprint setting and leave it disabled as it reduces security a bit. I wonder if there is some way the PW session fingerprint feature could detect and allow for user agent changes that specifically come from the Chrome dev tools?

For some reason enabling the device mode in the Chrome developer tools logs me out of the ProcessWire admin. I'm using Windows 10, Chrome 70.0.3538.102. Steps to reproduce: 1. Login to PW admin. 2. View the site frontend in a new tab (e.g. Home page). 3. Open the Chome dev tools, enable device mode, and reload the Home page: 4. Switch to the admin tab (where dev tools is not open) and reload - you are now logged out. Can anyone else confirm this? Is there a setting in the dev tools that would avoid this? Or is this logout behaviour something that could/should be fixed in the PW core?

The item you want to give special treatment to is the last item in the WireArray, so you could use pop() to get that item and remove it from the WireArray: Alternatively here is a more flexible approach that you can use for any item in the WireArray:

Yeah, it's not clear exactly which languages are supported but the example in the docs... ...makes me think there is some non-English language support. Good solution. Thanks for adding this feature.

Working fine here: $wire->addHookBefore('InputfieldImage::render', function(HookEvent $event) { /* @var InputfieldImage $inputfield */ $inputfield = $event->object; if($inputfield->hasField == 'image') { $inputfield->setMaxFilesize('2m'); // Set the max file size in bytes or use string like "30m", "2g" "500k" } }); But if you have client-side resizing enabled for the field that will likely interfere with the checking of the filesize before upload.

Nice one. I have another enhancement in mind but perhaps you wouldn't agree with the premise. The default Child Template Suffix is "Items" so I guess you like to name the child templates with the plural, but to me the parent template should be plural and the child template should be singular. And ideally the singular wouldn't be created by appending the word "item" but would be a bit smarter. So if the noun is "car" then the parent template is "Cars" and the child template is "Car". And as a trickier example, if the noun is "bacterium" then the parent template is "Bacteria" and the child template is "Bacterium". An an experiment I added pluralize.js to the module and it's working great, with ProcessPageFieldSelectCreator.js consisting of: $(window).load(function() { $('#Inputfield_fieldLabel').bind('keyup change', function() { var field_label = $('#Inputfield_fieldLabel').val(); var plural = pluralize(field_label); var singular = pluralize(field_label, 1); $('#Inputfield_parentTemplate').val(plural); $('#Inputfield_childTemplate').val(singular); $('#Inputfield_parentPageTitle').val(plural); }); }); Of course the user would want to double-check that the plural/singular forms are what they want, but this addition could save time if you are creating a lot of select fields (which is something I needed to do recently). The pluralize library looks like it handles non-English languages too but I couldn't find documentation on that and I'm not competent to test that myself. What do you think?

Exactly the same as the hook I posted above, but substitute InputfieldImage for InputfieldFile.

I haven't needed to do anything like this before, but I think it might be better to use a separate template for all these extra profile fields. When a user is added you use a hook to automatically create a profile page for the user. Or potentially vice-versa. The user page and the profile page would be connected via a Page Reference field. When it comes to editing the profile pages you may want to let users change their password or email address. This could be done by providing a (modal?) link to ProcessProfile within the Page Edit interface (using Runtime Markup or similar) or you could add password and email address fields to the profile template and then update the equivalent fields in the user page in a saveReady hook.

Thanks for these updates - working perfectly now.

I haven't heard of such an issue before. My only other idea is to make sure $config->debug = true in /site/config.php so that you will see any PHP errors that might be occurring. Or better yet, install Tracy Debugger and enable the debug bar for the backend as this will catch errors even more reliably.

This worked for me: Alternatively this also worked, in /site/modules/InputfieldCKEditor/config.js: CKEDITOR.editorConfig = function( config ) { config.colorButton_colors = 'CF5D4E,454545,FFF,CCC,DDD,CCEAEE,66AB16'; };

These are already excluded from the autocomplete as far as I can tell. // ProcessPageEditLink > Link to URL: exclude pages using templates without template file and unpublished pages $wire->addHookBefore('InputfieldPageAutocomplete(name=link_page_url)::render', function(HookEvent $event) { $inputfield = $event->object; $fileless_templates = []; foreach($this->wire()->templates as $template) { if(!$template->filenameExists()) $fileless_templates[] = $template->id; } $inputfield->findPagesSelector .= ', status!=unpublished, template!=' . implode('|', $fileless_templates); }); // ProcessPageEditLink > Select Page / Select Child Page: prevent selection of pages using templates without template file and unpublished pages $wire->addHookAfter('ProcessPageEditLink::execute', function(HookEvent $event) { $css = '.PageListStatusUnpublished .PageListActionSelect, '; foreach($this->wire()->templates as $template) { if(!$template->filenameExists()) $css .= ".PageListTemplate_{$template->name} .PageListActionSelect, "; } $css = rtrim($css, ', '); $css .= ' { display:none !important; }'; $event->return .= "<style>$css</style>"; });

The current version of the module isn't creating any option pages when using the standard "title only" option for Select Options. The parent page is created but no child pages. Settings: Result:

Hi Adrian, I think it would be good to provide a dedicated field for setting the parent page title rather than setting it the same as the field title. An example: I'm creating a select field to choose a geographical region. Only one region may be selected, so the field title should be "Region". Each individual page represents a region and together they make up the set of regions, so it makes sense to me that the parent of those pages should be titled "Regions" and not "Region".

I can't reproduce that on my secure sites - for me the panel and modal load pages over HTTPS. Normally for an HTTPS-only site you would enable the HTTPS redirection in .htaccess: https://github.com/processwire/processwire/blob/341342dc5b1c58012ae7cb26cffe2c57cd915552/htaccess.txt#L91-L95 So that would be something to check.

My guess is that some non-printable character got pasted inside your code. See the comments in this thread from here down: If that's not it then you can also use Tracy Debugger to debug why $template is undefined for you. All that the relevant code inside the hook is doing is looping over the $templates API variable with $template representing each Template object, so I can't see where else that could be going wrong.

Do you have a large number of inputs on this page? Inputs being images, repeater items, other fields. If so you might be exceeding PHP's max_input_vars setting. https://www.virendrachandak.com/techtalk/big-forms-and-php-max_input_vars/ If you do have a lot of inputs and cannot change max_input_vars then it may help if your repeater items are ajax-loaded as needed and not opened by default.

Minimal Fieldset Adds a config option to Fieldset/FieldsetGroup/FieldsetPage to render the fieldset without label or padding in Page Edit. When a neighbouring field in the same row is taller than the fieldset the extra height is distributed evenly among rows within the fieldset. Requires ProcessWire v3 and AdminThemeUikit. Why? This module allows you to create layouts in Page Edit that would not be possible without it. It's useful when you want a layout that has two or more fields as rows that are themselves within a row in Page Edit. It's also useful when you have some fields that you want to add to a template as a group (i.e. via FieldsetGroup or FieldsetPage) but having a heading and visible wrapper for the fieldset in Page Edit would be redundant. Example: Installation Install the Minimal Fieldset module. Usage In the field settings for any Fieldset/FieldsetGroup/FieldsetPage, tick the "Remove label and padding for this fieldset" checkbox. https://github.com/Toutouwai/MinimalFieldset https://modules.processwire.com/modules/minimal-fieldset/

There are different inputfields in ProcessPageEditLink and they need to be treated differently: Link to URL, Select Page, Select Child Page. For Link to URL I agree that there is probably no common use case that needs pages without template files to be visible/selectable here. For Select Page and Select Child Page, I think that pages without template files should appear there because those pages may have viewable child pages, and also I think it is easier for users to understand these inputfields if they show the same pages that they are familiar with from ProcessPageList where non-viewable pages are listed. But the pages without template files should not be selectable as links. I suggest you raise a GitHub request or issue to ask for a change to this. In the meantime here are a couple of workaround hooks for /site/ready.php: // ProcessPageEditLink > Link to URL: exclude pages using templates without template file $wire->addHookBefore('InputfieldPageAutocomplete(name=link_page_url)::render', function(HookEvent $event) { $inputfield = $event->object; $fileless_templates = []; foreach($this->wire()->templates as $template) { if(!$template->filenameExists()) $fileless_templates[] = $template->id; } $inputfield->findPagesSelector .= ', template!=' . implode('|', $fileless_templates); }); // ProcessPageEditLink > Select Page / Select Child Page: prevent selection of pages using templates without template file $wire->addHookAfter('ProcessPageEditLink::execute', function(HookEvent $event) { $css = ''; foreach($this->wire()->templates as $template) { if(!$template->filenameExists()) $css .= ".PageListTemplate_{$template->name} .PageListActionSelect, "; } if($css) { $css = rtrim($css, ', '); $css .= ' { display:none !important; }'; $event->return .= "<style>$css</style>"; } });

Yep, works well here. New PR made.

user_copy should be a new template without any fields already added to it. The only field it should contain is the automatic Title field which is not a permanent field unless you manually changed it to be permanent.