adrian

Thanks, the fix you provided looks to be working well. I have just committed it.

I can't see why that $p would ever be an integer - would you mind checking to see if it's returning a $page id or something else for me? It should be a page object. Thanks!

There are lots of shortcuts ? I think @matjazp was looking to have one in the Console panel. Yes I could make it a module config setting but if you make it the default then the "Clear Results" link it irrelevant (I guess it could be removed in this case), but then you'd have to use shortcuts to not automatically clear the results. Some time ago IIRC there were two buttons, "Run" and "Clear & Run" and no separate "Clear Results". I actually think that you had something to do with this change but I don't really remember why we went this way? Yeah, I agree the Tracy settings can be slow to load. Turns out the biggest issue is actually populating the DOM. If I simply collapse all the fieldsets it loads reasonably quickly. I used to have all (except the first couple of key ones) fieldsets collapsed, but I was convinced to change this, but that was some time ago and there were a lot less settings then. I wonder if I should revisit this? Perhaps I should collapse by default, but when following the cog/settings links at the bottom of a panel, then this would open up the requested fieldset. Maybe it also needs a toggle all at the top of the settings page for those who actually want to browse? Any thoughts?

Hey @matjazp - I don't really want to add another checkbox to the interface if we can avoid it, but I value your opinion, so I am curious why you would like this. I never use the "Run" button, or the "Clear Results" either. I just use the keyboard shortcuts - almost always the ALT/OPT + Enter combination (which automatically clears old results before running), and occasionally the CTRL/CMD + Enter combination if I do actually want to keep the previous results for comparison. Is there a reason you don't like the keyboard shortcuts, or is there some other reason I am missing that makes this new checkbox a useful addition?

Nice catch! It's interesting because many of the $sanitizer methods make use of the internal nameFilter() method which uses mb_strtolower. If you actually follow the cleanBasename method it goes through $sanitizer filename(), which uses name(), which uses nameFilter() which leads me to believe that it might actually be possible to just remove that that: $basename = strtolower($basename); line from the cleanBasename() method completely. I just tested this and it's actually pretty close - there are a couple of problems - one is the regex on #578 needs A-Z added to it. The other is that beautify doesn't get passed through to nameFilter() which is a condition for mb_strtolower() being called. Anyway, that was just an interesting excursion into what is actually going on and where ?

Just one additional comment to @LostKobrakai's great reply. HTML5 sessionStorage is basically the same as HTML5's localStorage except that it is only stored for the current session whereas localStorage is kept forever unless intentionally cleared.

Thanks @PWaddict - it should be fixed in 1.2.5

I've committed a new version of the Page Files panel. It is now about twice as fast as v1, so I think it will now be a panel I leave open all the time as a reference. It has a new "Delete missing pagefiles button" which deletes the pagefile references to the files which are missing from the filesystem.

I am curious whether it makes a difference if you make the saveReady a "before" hook? My PageRenameOptions module does some renaming on saveReady using "before" and I don't think I have ever seen this error in this situation. I might be totally off-base here but I thought it might be worth trying.

Thanks @Robin S it's fixed in the latest version. I have also added a message to note that there are no files associated with the page. Also fixed a few other bugs so please update.

Thanks @bernhard for pointing out the Donate button and a big thanks to everyone who has donated already ? I have just committed a new panel that hopefully you will all find useful. The Page Files panel shows (and links) to all the files that belong to the current page (including those in repeater items and even nested repeaters). It highlights (orange) files that are orphans - these are files that are in the /site/assets/files/xxxx folder for the page, but which don't belong to any of the file/image fields on the page. It also highlights (red) files which are missing from the /site/assets/files/xxxx folder but are referenced by one of the file/image fields on the page. Obviously missing files are more important and critical than orphans, so they are red as an alert, rather than a warning. The icon on the debug bar tells you how many files there are and how many are orphans and how many are missing. There is a "Delete Orphans" button to make it easy to cleanup these unneeded files. Note that the results are divided up into page IDs, starting with the ID of the page you are currently viewing/editing and followed by pages for any repeater field items. In parentheses it shows the name of the field that each file belongs to (except the orange orphans because obviously these don't belong to a field). You might wonder how you can end up with orphans or missing files? I find this mostly happens if I am building an API import script to bring in data from a site I am migrating and I mess something up. I also have this issue quite often when developing image related modules (especially my Custom Upload Names module). It may also potentially happen if there is a network glitch during an upload or delete call. Even if you don't have any orphans or missing files, you might still find it useful just as a way to quickly see the contents of the page's assets/files folder without needing to navigate via your file manager / FTP program etc. Let me know if you find it useful or if you have ideas for improving it. PS - this is obviously page based so it's not useful for doing a cleanup of your entire site - if you need that, then take a look at https://processwire.com/talk/topic/4437-delete-orphaned-filesimages-from-siteassetsfiles/?tab=comments#comment-43687 or other similar scripts in the forum.

Wow @matjazp - thanks for a brilliantly detailed answer - much appreciated. i must admit I am not very au fait with this locale stuff. I guess I am a little curious why PW's cleanBasename() has issues with this and yet $sanitizer->filename() and $sanitizer->pagName() with Sanitizer::translate do not. I guess I feel like they should all handle these translations the same way and so should all be subject to the same "issue".

I totally agree!

Ah I see your point now ? I guess I thought you'd be able to paste: https://www.google.ca/maps/place/-46.44080555555555,168.32130555555554 directly into the RTE and the formatter could work with that, but Google redirects that link to: https://www.google.ca/maps/place/46°26'26.9"S+168°19'16.7"E/@-46.4408056,168.3191169,17z/data=!3m1!4b1!4m5!3m4!1s0x0:0x0!8m2!3d-46.4408056!4d168.3213056 which is where things start going wrong. It is strange to me that they use DMS as the actual identifier.

Hey @Robin S - this is quite strange ? 46°26'26.9"S 168°19'16.7"E actually converts to: -46.44080555555555, 168.32130555555554 which you can see is perfectly accurate: https://www.google.com/search?q=-46.44080555555555+168.32130555555554 What is weird is that when you click on the map it shows rounded decimal values which are close to the values you are referencing above (but not quite). I have no idea why ? I have also never seen plus codes until now but they certainly look interesting, although I have always though of decimal degrees as the gold standard for lat/lng coordinates. None of this helps you - just continuing the discussion ?

@matjazp - can you confirm this on your setup? If this is reproducible it sounds like we need to file an issue as it's not related to this module.

Did you change it to en_US.UTF-8 to fix it, or something else?

All those "?" suggest to me that maybe there is a UTF-8 problem going on but I am not sure how to debug further at this point. Anyone out there with any other ideas?

OK, so it's pretty clear that the: if(mb_strpos($value, $from) !== false) { is failing.When I do: $filename = '"Test ä".png'; $pageFiles = new Pagefiles($page); d($pageFiles->cleanBasename($filename, false, true, true)); I get a dump returned showing: This is because it is finding the ä in the filename and doing a mb_eregi_replace on it to convert from "ä" to "a". Does it make any difference if you change "mb_strpos" to "strpos" ? What about removing that conditional altogether so that all replacements are executed regardless of whether the $from is found. So it would be like this - note that I have commented out the conditional. foreach($replacements as $from => $to) { //if(mb_strpos($value, $from) !== false) { bd($from .' => ' . $to, $value); $value = mb_eregi_replace($from, $to, $value); //} }

If that is the only thing that is being dumped, then it sounds like there is an issue with the: foreach($replacements as $from => $to) { loop because there are a couple of bd() calls in there also. It would be helpful to figure out what is failing there. This should help: if($beautify && $needsWork) { bd(1); if($beautify === self::translate && $this->multibyteSupport) { bd(2); $value = mb_strtolower($value); if(empty($replacements)) { bd(3); $configData = $this->wire('modules')->getModuleConfigData('InputfieldPageName'); $replacements = empty($configData['replacements']) ? InputfieldPageName::$defaultReplacements : $configData['replacements']; } foreach($replacements as $from => $to) { bd(4); if(mb_strpos($value, $from) !== false) { bd(5); bd($from .' => ' . $to, $value); $value = mb_eregi_replace($from, $to, $value); bd($value); } } } if(function_exists("\\iconv")) { $v = iconv("UTF-8", "ASCII//TRANSLIT//IGNORE", $value); if($v) { bd($value, 'ICONV'); $value = $v; } } $needsWork = strlen(str_replace($allowed, '', $value)); } Can you try that and let me know which of the 1, 2, 3, 4, 5 bd() calls are output? We are looking to see if commenting that out changes the returned filename, so you could test an actual file upload or you could run that cleanBasename test in the Console again. Either will be fine.

@PWaddict - did you have any success with that modified code in Sanitizer.php - did the bd() calls work? Another thing to try would be to comment out that iconv code completely: /* if(function_exists("\\iconv")) { $v = iconv("UTF-8", "ASCII//TRANSLIT//IGNORE", $value); if($v) { $value = $v; } }*/ so we can see what is returned without it getting involved.

Yeah, it depends on when the bd() call is made. Tracy is now always the first site module loaded by PW (thanks to a recent update by Ryan), but when it comes to the PW core and core modules I don't have any control over that - sometimes you'll have success and other times you'll get that error. For me though they have been working in those spots in Sanitizer.php. I guess the name() method is being called by the core at some point before Tracy is loaded which is why it's not working for you?

@Zeka - could you please add to this ongoing issue: https://github.com/processwire/processwire-issues/issues/408

The code block I posted doesn't change any behavior - it just adds bd() calls so that will can see what is going on in that function. Once you restart does it continue to work until you do something specific or does it seem to randomly stop working?

Here's a working function for doing this. I know without being in the core it's not much use to you, but thought it was worth referencing: https://github.com/adrianbj/ProcessModuleToolkit/blob/09b437d888c270ffe01f3a80fc5dccab3136e42e/ProcessModuleToolkit.module#L1278