Robin S

This CSS seems to be working well for me so far... #tracy-debug-bar { position:fixed !important; left:auto !important; top:auto !important; right:0 !important; bottom:0 !important; }

That screencast is with the latest version (4.10.19).

Hi @adrian, I'm experiencing an issue with Tracy in AdminThemeUikit (I don't remember it happening in AdminThemeDefault) where the debug bar forgets its position between page loads. I normally keep the debug bar at bottom right, but it forgets this and jumps up to the top left (sometimes other random locations too). It seems to be related to opening a modal window, with Tracy enabled for modals. See in the screencast below how after opening and closing the modal then reloading the page Tracy is now at the top left of the screen. Hopefully not too tricky to fix. If in fact it is tricky, I wouldn't mind an option that keeps the debug bar locked in the bottom right because personally I never move it from there. Edit: it does happen in AdminThemeDefault also. Funny, because I always have Tracy enabled for modals and I don't remember this occurring before. Maybe a side-effect of a recent update to the module?

If the hook is removed then it will fix the issue I was seeing, because with the autocomplete attribute being on the password fields those fields aren't autofilled by Chrome. So if the extra condition you added to the JS prevents your generated password from being cleared and you can therefore remove the hook then it will be all good from my end. I guess if/when Firefox autofills the password field it doesn't affect the value attribute? I can't test it here because I can't get Firefox to autofill the password field anyway (or I just don't know what steps are required to reproduce the issue on that browser).

I guess the issue is because of how you are assigning $r. When you assign like this $r gets the value of $p->repeater but is otherwise not connected to it. The PHP manual says: So when you add an item to $r you are not adding it to $p->repeater. Does the problem resolve if you assign $r by reference? $r = &$p->repeater;

Sure, is now pending approval approved for the directory.

Are you positive the   is not actually there in the source? Not sure what tool that screenshot is from but some tools will decode HTML entities in which case   would just display as a space between words. Also, I can see an inline color style in your screenshot - is that coming from Javascript perhaps? If so, disable all your Javascript to make sure it is not responsible for converting the   entity.

A couple of things that might be relevant to the problem: 1. $cache is an API variable (WireCache) - better not overwrite it with something else. 2. WireCache provides everything that the MarkupCache module does plus more. Maybe consider using WireCache instead.

Welcome to the PW forums @Jules Vau Probably silly question, but you are entering   right? It is working for me with the same settings as you show above (although I didn't enter anything in Extra Allowed Content as that shouldn't be needed in this case). I tested in 3.0.99 but I don't think anything has changed in this regard since 3.0.96.

@adrian, looking at the commit that introduced the issue, it looks like removing the autocomplete attribute is an attempt to defeat this piece of InputfieldPassword.js. That piece of JS is a fairly old (and hacky) response to a browser-specific (Firefox) issue that probably no longer applies. The recent autofill fixes in InputfieldPassword and updates/bug-fixes to Firefox should have solved it without the need for that JS workaround (I tested quickly in the latest Firefox and couldn't see any issue with the JS removed). So you could raise a GitHub issue/request to see if Ryan will remove that JS. In the custom module I made for a project recently I took a different approach to auto-generated passwords. Rather than populate the core password field I manipulated the ProcessUser form to... 1. Hide the password field with CSS 2. Add a markup field to show the user the auto-generated password 3. Add a hidden field containing the auto-generated password Then in a before hook to InputfieldPassword::processInput I copy the password value from the hidden field to the password field in $input. That may not be an approach you'd want to take with your module, but just to show there might be other ways to tackle things if Ryan doesn't want to remove that problematic JS.

The issue is exactly as you described it in the GitHub issue I linked to above. It is related to the browser autofilling the password field, so it depends on the form history that is saved in your browser. It's not the kind of thing that will always cause a problem, more one that can (but shouldn't) cause a problem. The fix that Ryan pushed to the core was to avoid that.

The import/export of fields and templates has been around since PW v2.5 (2014), so I think you could consider the feature as stable as anything else in the stable branch. For reference, the blog posts that introduced the features... https://processwire.com/blog/posts/august-2014-core-updates-1/ https://processwire.com/blog/posts/august-2014-core-updates-3/ I think it would be wise to be extra vigilant when exporting/importing non-core fieldtypes, and complex fieldtypes that need to account for templates/fieldgroups such as Repeater, Repeater Matrix, and maybe PageTable. Support was added for import/export of Repeater fields in late 2017 but Ryan said at the time "Seems to be working well here, but definitely needs more testing."

Hi @adrian, just a heads up: I was again experiencing this issue that you raised in the PW issues repo a while ago: https://github.com/processwire/processwire-issues/issues/432 It was a bit puzzling but I traced it back to the Email New User module which I was testing out. Due to this commit the module is undoing the fix that was applied in the PW core.

Not a big problem, but the only other thing I would say is: imagine if every PW module developer did this. Would it be cool if there was an extra branding link in every MarkupSimpleNavigition menu? Maybe nobody would use that module then...

I'm not an expert on software licenses, but I think this restriction is incompatible with the license you are releasing the module under (which seems to be the MIT license based on the code comment here). The MIT license allows for modification, so anyone can modify the code to remove the branding markup. Not sure what sort of license would be compatible with what you intend - I think all the common open source licenses permit modification.

I have used the script below to do that, but must emphasise that this is destructive. The script does copy the original image to a "for_deletion" folder in the site root, but in case of disaster it would be a big PITA to go through and put the original images back to their relevant pages. So use at your own risk! // You could run this script manually, or put it on LazyCron if you have a lot of images // Maximum image dimensions $max_width = 1600; $max_height = 1600; // Images to process per operation $limit = 5; // Create array of large images $large_images = []; $i = 1; foreach($fields->find("type=FieldtypeImage") as $field) { if(!count($field->getFieldgroups())) continue; foreach($pages->find("{$field->name}.count>0") as $p) { foreach($p->getUnformatted($field->name) as $image) { if($i > $limit) break; if($image->width > $max_width || $image->height > $max_height) { $large_images[] = [ 'basename' => $image->basename, 'filename' => $image->filename, 'page' => $p->url, ]; $i++; } } } } // Iterate over images foreach($large_images as $large_image) { // Make backup copy of image (create the "for_deletion" folder first) $destination = $config->paths->root . 'for_deletion/' . $large_image['basename']; if(!file_exists($destination)) { $success = copy($large_image['filename'], $destination); // Don't carry on to the resizing stage if the copy wasn't successful if(!$success) continue; // Log file copy $log->save('resized_images', "Copied original image {$large_image['basename']} from {$large_image['page']} to /for_deletion/"); } /* @var ImageSizer $sizer */ $sizer = new ImageSizer($large_image['filename'], ['cropping' => false]); $sizer->resize($max_width, $max_height); // Log file resize $log->save('resized_images', "Resized image {$large_image['basename']} on page {$large_image['page']} to max width $max_width, max height $max_height"); } If you are using image field types besides the core FieldtypeImage you could modify the identification of image fields to something like this.

You access it like any other property of the field... ...or am I misunderstanding your question?

The next best thing... $imageFields = []; foreach($this->fields as $field) { if($field->type instanceof FieldtypeImage) $imageFields[] = $field; }

Not sure why that should be happening, but you can log/dump $label at different points in the code here to find out where the header label is coming from.

The skipLabel option is about whether or not to render the header of the inputfield. An example with InputfieldText: $f = $modules->get('InputfieldText'); $f->name = 'text1'; $f->label = 'label'; $inputfields->add($f); $f = $modules->get('InputfieldText'); $f->name = 'text2'; $f->label = 'label'; $f->skipLabel = Inputfield::skipLabelHeader; $inputfields->add($f); For InputfieldCheckbox, the header is already not rendered by default unless a description is defined for the inputfield. Instead, the label is rendered next to the checkbox itself. So setting skipLabelHeader or skipLabelBlank won't do anything because the header is already skipped. If you do want a separate header label for InputfieldCheckbox you can use the "checkboxLabel" or "label2" properties (they both do effectively the same thing). When these properties are set the "label" is rendered in the header and the "checkboxLabel" or "label2" is rendered next to the checkbox: $f = $modules->get('InputfieldCheckbox'); $f->name = 'checkbox1'; $f->label = 'label'; $inputfields->add($f); $f = $modules->get('InputfieldCheckbox'); $f->name = 'checkbox2'; $f->label = 'label'; $f->checkboxLabel = 'checkboxLabel'; $inputfields->add($f); If your question is actually "is it possible to have a checkbox without any text next to it" I think the answer is no, not using the API options. You could try a str_replace() in a hook after InputfieldCheckbox::render, or use Javascript to remove the text. Edit: another alternative for a checkbox without text next to it is to use a space character as the label: $f = $modules->get('InputfieldCheckbox'); $f->name = 'checkbox1'; $f->label = ' '; $inputfields->add($f);

See this blog post where it talks about using a selector string as the "expires" argument. But before you go too far into WireCache as a solution for your problem I recommend going through your PageFinder queries ($pages->find(), $page->children(), etc) to see if they can be optimised. You might find you don't need WireCache then - for example, if you change to the query I suggested in my previous post you probably wouldn't need to cache it. It's not so much how many pages you are querying that matters, it's how many pages your query is returning. If each of your 3 queries returns 150 pages then this is not ideal unless you are actually using 450 pages in your markup somehow. Your aim should be to return no more pages that you are actually going to use. Also try to avoid multiple PageFinder queries if the same result can be achieved in one query (as demonstrated in my previous post).

It's this part that probably has the most impact on performance. If that is just to find four random items it could be done a lot more efficiently as: $related = $pages->find("id!=$page, tags=$page->tags, (template=where-to-go-detail|meet-the-locals-detail), (template=events-detail, location_venue!=$page, events_detail_dates_final_date>=today), sort=random, limit=4"); When you are wanting a specific number of results, wherever possible you should do that via a limit in the database query i.e. in the $pages->find() selector.

Thanks @teppo, I'll take a look.

Thanks @adrian, no worries. The needs of my current project are fairly specific/unique so I'm not sure yet whether I'll modify the Email New User module or make a new custom module. I'm sure your module will be a big help in either case, and if I do make some additions to Email New User that could be useful to others I'll certainly share them here.

Hi @adrian, My first time using this lovely module. A question and a couple of requests... When editing/saving a user in admin, under what circumstances is an email sent if the "Automatic Email Send" option is checked? For existing users (who may have already been sent their welcome message) will an email be sent if nothing is changed but the user just saved? Silly me, I was trying to work it out from the code rather than just trying it out. I see now that the interface changes to "Re-send welcome message" after the first user save. Request 1: It would be cool if there was an option in the module config to select key fields in the user template, where if any of those fields have changed the user is automatically sent an email. The obvious fields to trigger this would be "name" and "pass", but it would be nice to include custom fields too because in my case users log in with their email address. If other fields are changed no email would be sent. As I type this another thought occurs to me - maybe there could be different email templates for "new user" (password old value is blank) versus "modified user" (key field has changed)? Request 2: How about a module config option for not showing the "Send welcome message" checkbox and the "Email message" CKEditor field in Edit User? In my scenario there are several different roles with different user-admin privileges. I'd rather take the decisions out of their hands whether or not to send an email and what the message will be.