Robin S

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.

Thanks for reporting this issue. It should be fixed in v0.1.5 of CKEditor Link Files. If you check the changes in this commit you can apply something similar in your module. @tpr, this issue will affect the version included in AdminOnSteroids too. I thought a hook before module edit would trigger before the access control kicks in but it seems not. Sort of obvious in hindsight. I really didn't want to have to add a page just for the AJAX response so went looking for some other process to hook into. I settled on ProcessLogin::executeLogout as this is one process module/method that should be accessible for any user. You might want to update AOS with a similar fix.

I had the same thought initially when Markup Regions were introduced, but after thinking about it some more I don't know that this amounts a good reason not to use something. Because you could actually say the same thing about most aspects of the PW API and therefore never start with PW in the first place. Take $files->render() for example. If you're coming in cold knowing nothing about PW you're not going to instantly understand how this works, what variables will be in scope, etc. You have to take a bit of time to become familiar with the method, read the documentation, test things out. So really no different to Markup Regions. Once you read the introduction and try out Markup Regions it starts to make sense very quickly. Personally, I think Markup Regions are a fantastic feature and I have used them on every new site since they were introduced.

The widths you have defined wouldn't work on any of the core admin themes. When you want a set of fields to all display on a single row, their widths must sum to 100% disregarding show-if conditions. The widths you have defined sum to 134% so they will not display on the same row. When you have show-if conditions where only one of the show-if fields will display at once, divide the remaining width in the row between the show-if fields. So in your row you have two fields that always show, totaling 66% width. That leaves 34% of width to divide between two show-if fields. So give each of those fields a width of 17%. When either of the fields shows its width will be actually be expanded beyond 17% to fill up the row.

This means that the response is not the JSON that is expected - there is probably an error message or something else revealing at the start of the response. See the post below for how you can use your browser dev tools to inspect the response and find out what the error is:

That was an error in the info at the modules directory, caused by mismatched browser autofill. Catches me out on a semi-regular basis. Would be nice if the modules directory used autocomplete attributes on the fields to give browsers some guidance for autofill.

@gmclelland, thanks for taking a look at the CSS. I've made some tweaks in v0.1.4 which will hopefully solve the cutoff text you were seeing. Let me know if not.

@gmclelland, thanks for the feedback. I don't want to reinvent the wheel for functionality that's already in the core. I'd actually prefer this module to be more like the Images field behaviour rather than the other way around. I would have done the file renaming the same way as the Images field but the filename is used as a link in the Files field. I will probably work on refining this module to be closer to the renaming/replacing behaviour of the Images field when I have time. I also think Ryan does intend to bring renaming and replacing to the Files field, as the underlying code is in InputfieldFile and labelled with "currently only used by InputfieldImage". We've talked previously about how to limit image renaming by a permission: I don't think there's an easy way to prevent image replacement, but it doesn't really make sense to anyway because if a user has access to an Images inputfield then they can already upload and delete images which is no less destructive than replacing them. I can't see that here so hard for me to fix - it might be OS dependent. When you have a chance, could you have a play around with the CSS and see if you can find a solution? Hopefully without changing the position of the elements. Maybe take a look at line-height, overflow or z-index? Thanks. Yes, it is awaiting approval for the directory.

Module updated to v0.1.3. The workflow for replacing files is now reversed, because it's more intuitive that way. Readme and screencast updated.

I think I misunderstood you before. You're suggesting the dropdown would be "Replace with" and you would use the dropdown in the target file rather than the source file, and select a source file to be a replacement. I agree that is more intuitive, but the replace code in InputfieldFile doesn't work that way - each file can specify another file that it will replace, but not a file that will be it's own replacement. But I could go away from letting InputfieldFile handle the replacement and do it all within the module (I'm already having to handle the metadata and sort position). Will have a think about it and may well change to that. So to any early adopters... be advised that the workflow may change.

I hear what you're saying, but the idea for this module is to bring the behaviour of the core Images field to the Files field (albeit in a less ambitious way). Ideally the Files field would have a dropzone similar to the edit panel thumbnail of the Images field, and a file uploaded via that dropzone would immediately replace the edited file. But tackling the Javascript that would be involved feels like too much work, hence the less elegant approach taken in this module. Pull requests from JS wizards would be welcome. The way I'm imagining this module being used is you have a file with some metadata, and perhaps that file is linked to in a CKEditor field. You want to replace that file with another file (not yet uploaded) without having to manually copy the metadata or recreate the link in CKEditor. The new file is uploaded to the field and then immediately afterwards the target file is replaced. So it's like a poor man's version of the image replace feature, using the same underlying core code in InputfieldFile, in two steps instead of one. I hadn't imagined the replacement file being one that has already existed in the field for a while and has metadata associated with it (my screencast demo wasn't that well thought out - I'll redo it). But I think it should be quite easy to support what you've suggested, via a checkbox next to the select for "Replace metadata also". Or some other wording you think would be clearer?

An Images field allows you to: Rename images by clicking the filename in the edit panel or in list view. Replace images, keeping metadata and filename (when possible) by dropping a new image on the thumbnail in the edit panel. Introduced here. But neither of these things is possible in File fields, which prompted this module. The way that files are renamed or replaced in this module is not as slick as in the Images field but it gets the job done. The most time-consuming part was dealing with the UI differences of the core admin themes. @tpr, gives me even more respect for the work that must go into AdminOnSteroids. Most of the code to support the rename/replace features is already present in InputfieldFile - there is just no UI for it currently. So hopefully that means these features will be offered in the core soon and this module can become obsolete. Files Rename Replace Allows files to be renamed or replaced in Page Edit. Usage Install the Files Rename Replace module. If you want to limit the module to certain roles only, select the roles in the module config. If no roles are selected then any role may rename/replace files. In Page Edit, click "Rename/Replace" for a file... Rename Use the text input to edit the existing name (excluding file extension). Replace Use the "Replace with" select to choose a replacement file from the same field. On page save the file will be replaced with the file you selected. Metadata (description, tags) will be retained, and the filename also if the file extensions are the same. Tip: newly uploaded files will appear in the "Replace with" select after the page has been saved. https://github.com/Toutouwai/FilesRenameReplace http://modules.processwire.com/modules/files-rename-replace/

I had an issue on local sites recently where communication with the Google Maps geocoder was failing due to an SSL error. The error message was a little different than what you are seeing, but it might be worth a shot. Have a read of this article: http://www.bigsoft.co.uk/blog/index.php/2017/04/29/file-get-contents-ssl-operation-failed-with-code-1-ssl3-get-server-certificate-certificate-verify-failed And follow the steps: Download the cacert.pem file to some suitable permanent location Edit php.ini to set the path to the downloaded file, openssl.cafile=/path/to/cacert.pem Restart Apache

The reason in terms of the code is that a password inputfield is forced to display uncollapsed on unpublished pages because of this part of InputfieldPassword. There is no way to override this collapse status with a hook. As for the reason "why?", I can only speculate that Ryan sees the password field as a special case that is unlike other fields, and does not expect it to be used apart from the single built-in usage in the user template. Did you try the hook I suggested in my previous post? I'm not clear on whether you are using the password field a second time in the user template or in some other template besides the user template. If it's the latter and you are not editing the page via ProcessUser (i.e. not under the Access > Users section of admin) then you would modify the early return test to check for template instead. $wire->addHookAfter('ProcessPageEdit::buildFormContent', function(HookEvent $event) { $page = $this->process->getPage(); if($page->template != 'your_template') return; $form = $event->return; $pass = $form->getChildByName('pass'); // Assuming your password field is named "pass" if($pass) $form->remove($pass); $event->return = $form; });

Not sure, but it's working for me with non-superuser roles. Double-check that you have met all the requirements:

1. This part... // 4. // Split search phrase // If nothing above matches, try each word separatly if( !count($matches) ) { $q_separate = preg_replace('/\PL/u', ' ', $q); // "Remove" everything but letters $q_separate = preg_split('/\s+/', $q_separate); foreach ($q_separate as $q_word) { if ( $q_word != '' && strlen($q_word) > 4 ) { $append_products_separate = $pages->find("title|headline|summary~=$q_word, template=product, limit=50"); $matches->append($append_products_separate); } } } ...is needlessly inefficient. You don't need to do separate database queries per word here - you can use the pipe as an OR condition between words. So basically replace spaces with pipes in your search phrase and match against title|headline|summary. 2. Consider using the %= operator so you can match part words. So a search for "toast" will match "toaster". 3. If you don't have a huge number of products then maybe a fuzzy search using Levenshtein distance could be a possibility, for product title at least. I did a quick test against 196 country names (239 words) and it was reasonably fast. $q = 'jermany'; $countries = $pages->find("template=country"); $matches = new PageArray(); foreach($countries as $country) { $words = explode(' ', strtolower($country->title)); foreach($words as $word) { // Adjust max Levenshtein distance depending on how fuzzy you want the search if(levenshtein($q, strtolower($word)) < 2) { $matches->add($country); break; } } }

That is just how images work in ProcessWire. All images that you upload must be stored in an images field.

There is an option in the field access tab "Make field value accessible from API even if not viewable" that would probably resolve that. Alternatively you can prevent the field appearing in ProcessUser with this hook: $wire->addHookAfter('ProcessPageEdit::buildFormContent', function(HookEvent $event) { if($this->process != 'ProcessUser') return; $form = $event->return; $pass = $form->getChildByName('pass'); // Assuming your password field is named "pass" if($pass) $form->remove($pass); $event->return = $form; });