adrian

Yes, you can set all of Tracy's settings as $config options. For exporting settings, use: https://processwire.com/modules/module-settings-import-export/ This post explains it all: https://processwire.com/talk/topic/5693-new-module-type-wiremail/?do=findComment&comment=172428

Thanks for your work on this @Pete One thing I noticed is pink on dark grey doesn't really work, eg: Otherwise, looks great!

I did my test with a multiple images field (max: 0) just like in your screenshot. It might be helpful if you could test on another template / repeater field setup with support for multiple images and see if you can narrow it down. If you've got a setup that doesn't work, I am sure others will come across this at some point as well.

Sorry @Rostik RODE - I am at a bit of a loss - still can't reproduce. Any chance you could share a login to the site so I can test? Are there any other modules / hooks that might be interfering with image naming? or anything else you can think of?

Thanks @Rostik RODE - I just tested those settings and can't reproduce the issue you are seeing. Any chance the title field for the page somehow isn't set when the image is uploaded? Usually this is unlikely because title is required and the first thing that is set when creating a new page, but that it really the only reason I can think of for the upload-tmp suffix being added - it's there so that the module knows that file needs to be renamed later, once that field value is available.

Did it work fully with older versions of the module? The problem is not actually repeater specific - the upload-tmp suffix is because the naming rule you defined relies on a field that isn't populated at the point when the image is uploaded. Obviously this happens in most situations with repeaters, but it will also happen with regular pages in that situation. Can you share your settings like PWAddict did?

Sorry if this is a silly / obvious thing, but please note that setting the page name for the admin to xyzzy doesn't also set the admin/superuser's name to xyzzy as well. Did you explicitly set it to xyzzy as well?

The reason is because ListerPro uses the saveField() when only field in the row is changed. If you edit two fields, then the rename will work because ListerPro then uses save() - you can see this starting on line 631 of the main ListerPro module file. It should be possible to make CUN work with this by adding a new hook to Pages::saveField. I have this working but I think I need to test more for other possible side effects. If you'd like to help test, you can place: $this->addHookBefore('Pages::saveField', $this, 'customRenameUploads'); after this line: https://github.com/adrianbj/CustomUploadNames/blob/67b1d42aef4c23be92684420f0d282c0c4a9a8d4/ProcessCustomUploadNames.module.php#L101 Let me know how it goes for you.

Thanks @PWaddict - that helped a lot. Should hopefully be fixed in the latest version.

@PWaddict - I have been trying to reproduce the issue with repeaters but can't so far. I have a feeling the duplicate image issue might not exist in 1.3.1 so I want to work on the repeater issue first and see if that fixes everything for you. Can you please provide all the repeater field settings, the image field settings, and the CUN settings. There must be some combination I am not trying.

Hi @videokid - sorry about that - it was some PHP 7 specific syntax in the newish ConvertFieldsToMultiLanguage action. Should be fixed in the latest version.

@digitex - I think this idea is really needed - can you add to PW requests GH repo please?

Hi @Falk - would you mind adding a note to that github issue (https://github.com/processwire/processwire-issues/issues/1335) so that Ryan knows it's not just me?

Was this just in a repeater scenario? I have been using the latest version extensively without any problems (and it solves lots of other issues), so I am assuming this is repeater specific? I'll try to take a look shortly. Sorry, I haven't had much time for module maintenance lately.

Sorry, because I don't actually use a translation service to translate content in the admin I took the easy way out and just implemented a direct curl request to the Lingvanex API.

@fruid - the selector field is part of the PW core. You can limit the available fields with this setting "limitFields" => ["field_one","field_two"] Hope that helps.

Did you recently update the main Hanna module? @teppo's helper hasn't been updated to support that new version yet.

Try calling the function like: \ProcessWire\myFunction()

@teppo - sorry for the barrage. Again, don't worry about this if it's not important to you, but I noticed an issue with highlighting in the auto description if there is punctuation in the search, eg: https://ian.umces.edu/search/?q=bird's+head Note the last result: "Science communication training for West Papua, Indonesia" doesn't highlight "Bird’s Head" because it's not a regular single quote character used for the apostrophe. I wonder if highlight matching can / should ignore punctuation characters?

@ryan - also wondering what you think about supporting multiple operator options in the ProcessPageSearch settings? I am quite liking the *=~*= combination.

Hi @teppo - I've been playing around with multiple operators (https://processwire.com/docs/selectors/operators/#using-more-than-one-operator-at-a-time). I think you mentioned that these aren't supported, so please feel free to ignore this request, but what I discovered when using this operator combination: *=~= is that the grouping feature no longer works if PW fails to find any results via *= and moves on to ~= All results end up being listed under the All tab with no other tabs shown. For now I've gone back to my old approach to adding the tabs which works with this operator. I have also played around with the #= operator which I think will need some special handling to support because of the need to additional additional quotes and escaping. Just rambling out loud here - I also played around with adding basic support for swapping between *= and ~= depending on whether the user's search term includes double quotes. I almost stuck with that approach but I am honestly not sure how many non-tech users know about quoting search terms, so I thought the *=~= was probably better for most people.

@ryan - just playing around with some of the new options here and they are really awesome, thank you! I was initially confused about how to use this example: +(foo bar) or +"foo bar" indicates the phrase "foo bar" MUST appear My experiments showed this. Unless I am missing something, to use the double quote option, you need to have two sets, with the inner set escaped. This is OK, but I feel like perhaps it could be better documented. The other thing I have noted is a feature request to add support for excluding stopwords when doing partial matches. For example, "University of Queensland" is great when you're searching for the phrase, but if you are using multiple operators at a time, eg: *=~=~|= you really don't want that last operator (~|=) to match the "of" if the other words don't exist. Is there a way to do this already, or is it something that you could support fairly easily? Or, would you recommend that we do this at the server level using MySQL's "ft_stopword_file" setting?

How big is the DB for the site? The backup mechanism built into the upgrade process (and also via ProcessDatabaseBackups) doesn't handle large DB's very well at all. I actually recently requested that Ryan consider changing the latter to use native backup tools (ie mysqldump) to avoid this. Does the upgrade work OK if you just tell it not to backup? I don't honestly see the point in the backup while upgrading - PW upgrades almost never make changes to the DB anyway.

Thanks @Zeka - I wonder why I am not seeing the issue here? I understand your changes, but not really sure why they are necessary. Oh well ? Anyway, thanks very much for the fix - I have made that change (and also changed it in the Tracy logs panel) and committed a new version. Thanks again for all your efforts and have a great weekend!

@teppo - I looked into the issue with truncation of entities a little more and it seems like there are a couple of different approaches to fix this. The simplest seems to be to simply remove any trailing bits of entity that is left over, eg: $value = rtrim(preg_replace('/(?:<(?!.+>)|&(?!.+;)).*$/us', '', $value)); as mentioned here: https://www.drupal.org/project/drupal/issues/2279655#comment-8843201 - there is some other useful discussion there about this issue. Another approach I've come across is to calculate the length by treating the entities as a single character like they detail here: https://gist.github.com/andykirk/b304a3c84594515677e6 and https://alanwhipple.com/2011/05/25/php-truncate-string-preserving-html-tags-words/ I tried the first approach and it seems to work fine. Hopefully this might save you a bit of time. This is where I've put it for now: protected function formatResultAutoDesc(string $match, string $index, string $desc): string { if ($match !== '') { $match_length = mb_strlen($match); $add_prefix = (empty($desc) || mb_substr($desc, -3) !== '...') && (mb_strpos($match, '...') === 0 || mb_substr($index, 0, $match_length) !== $match); $add_suffix = mb_substr($index, -$match_length) !== $match || mb_strrpos($match, '.') !== $match_length; // Remove scraps of HTML entities from the end of a strings $match = rtrim(preg_replace('/(?:<(?!.+>)|&(?!.+;)).*$/us', '', $match)); $match = ($add_prefix ? '...' . $match : $match) . ($add_suffix ? '...' : ''); } return $match; }