matjazp

I was suspecting locale problems from the very beginning, that's why I asked to dump basename() and pathinfo() calls since they are both locale aware. Just to test again, could you @PWaddict try this: d(basename("ä")); with and without translated "C" in LanguageSupportModule? Though I'm getting the correct results regardless of "C" value. That's why we have a check that is performed on every login (and some changes are introduced recently to better clarify the issue here)! Do you get a warning message when you log in, something like "Note: your current server locale setting isn’t working as expected with the UTF-8 charset and may cause minor issues. Your current locale setting is “en_US.UTF-8”. Please translate the “C” locale setting for each language to the compatible locale in ... " ? if not, then why you translated the "C" in the first place and also translated to the nonexisting locale? There is no need to translate "C" string on windows (from my experience). Windows don't have "en_US.UTF-8" locale, that's why PW suggest "en-US". The list of supported locales on windows: https://msdn.microsoft.com/library/cc233982.aspx , see the language tag column. As for getting mixed results: the locale information is maintained per process, not per thread. If you are running PHP on a multithreaded server API like IIS, HHVM or Apache on Windows, you may experience sudden changes in locale settings while a script is running, though the script itself never called setlocale(). This happens due to other scripts running in different threads of the same process at the same time, changing the process-wide locale using setlocale(). Glad you solved the problem ?

Hm, I'm running out of ideas... And this? d($sanitizer->filename($filename)); d($sanitizer->filename($filename, Sanitizer::translate));

Now that's odd. Please do: d(pathinfo($filename)); on both affected instalations. @adrian off topic: when I do bd() call in Sanitizer.php in the name() method (line 245) I get: Fatal error: Uncaught Error: Call to undefined function ProcessWire\bd() in C:\inetpub\wwwroot\wire\core\Sanitizer.php:246

I get the same results as Adrian. Are there any hooks in the game? Tried on fresh install? Could you also d(basename($filename)); @PWaddict

I'm on windows:

I used PW upgrades module... Edit: Adminer 4.7.0 (released 2018-11-24)

Just wanted to upgrade her, but I got compile error: "Cannot declare class TracyDebugger, because the name is already in use", File: ...\modules\TracyDebugger\TracyDebugger.module.php:24

@bernhard would you mind editing WireFileTools.php and in rmdir() method insert $path = rtrim($path, "/"); just before $files = scandir($path);

I know, I opened it ? Ryan tried to fix this issue, but introduced another one. Try: $files->mkdir($config->paths->cache . "test/test/", true); $files->rmdir($config->paths->cache . "test/", true, array('throw' => true)); By default throw is false, I set it to true just for you/others to see the results. The point is: rmdir() fails to remove a directory that contains subdirectories due to a bug. Edit: ?

The problem is in WireFileTools.php in rmdir() method in foreach loop. The $path coming into rmdir() contains ending slash, and $pathame (actual directory name) eventually contains two slashes , that makes allowPath() method to throw an WireException. The possible solution is simple: $path = rtrim($path, "/");

Yep, that's true. How about making this as an option? Most of the time work on templates is done on wide screen. Also, some might prefer to have fieldsets on the main screen, not on separate tabs, so I would make this configurable too. Just an idea, not a feature request.

Cool! Add an arrows-h icon to the InputfieldMarkup? Make the widths with the slider instead of text input? Dynamically show the width of fields as they change?

Thanks for the module. Maybe this could be in the core... Any chance of supporting AdminThemeDefault? If not, then you could possibly check if the user has Uikit theme active before injecting css file and applying classes?

https://github.com/processwire/processwire-issues/issues/704

I upgraded PW to the latest dev using the upgrade module from Ryan (I normally upgrade by hand) and got the message that Upgrade files are already present. Please remove them before continuing. Clicking on Remove button didn't help, had to manually delete /site/assets/cache/ProcessWireUpgrade folder. I'm on windows, I think this is important. Anyone else?

Yep, it's me ? I had an error (premature end) in my 404 template file.

I tried new redirect option and manually created redirect, but instead of a redirect, I get 404 page. I'm probably doing something wrong ...

@adrian when you get back, please take into account $config->dbPort setting. I'm using non-standard port and this should be honored in ProcessTracyAdminer.module something like that: $port = wire('config')->dbPort ? ':'.wire('config')->dbPort : ''; ... new AdminerProcessWireLogin(wire('config')->dbHost.$port, wire('config')->dbUser, wire('config')->dbPass, wire('config')->dbName),

I don't know if Ryan need to know that. It seems there are no (known?) side effects with this paths, maybe there could be an issue with adminTemplates if PW is running in subdirectory? Ryan is busy, don't won't to bother him. And there are other issues that need his attention...

Thanks for this, very cool! When you toggle all and then try to collapse one object/class by clicking on the down arrow, the first click doesn't collapse, had to click it again. Nothing to do with Tracy, but I noticed that some paths in $config are different, like $config->paths: ProcessWire\Paths #3457 _root protected => "C:/inetpub/wwwroot/" (19) data protected => array (206) wire => "wire/" (5) site => "site/" (5) modules => "wire/modules/" (13) ... fieldTemplates => "site/templates/fields/" (22) adminTemplates => "C:/inetpub/wwwroot/wire/modules/AdminTheme/AdminThemeDefault/" (61) sessions => "C:/inetpub/wwwroot/site/assets/sessions/" (40) and $config->urls ProcessWire\Paths #cc50 _root protected => "/" data protected => array (206) wire => "wire/" (5) site => "site/" (5) modules => "wire/modules/" (13) ... adminTemplates => "/wire/modules/AdminTheme/AdminThemeDefault/" (43) AdminThemeDefault => "wire/modules/AdminTheme/AdminThemeDefault/" (42) (adminTemplates has the slash at the beginning). Is this how it should be?

@BitPoet thanks. I'm sure we will not add an exception for processwire.com (or any other domain). I'm not sure Ryan is aware of this, as it looks like (looking at the SPF record) he was using mandril before. I hope this post will reach him somehow ...

Hi! Today I changed my email address associated with my PW forum account. PW sent an email to my new email but unfortunately, I didn't get it. Luckily I could change my email again to g*ail address and this time I received an email instantly. The from address is: "ProcessWire Support Forums ryan@processwire.com via sendgrid.net". G00gle explains: You'll see "via" and a website name next to the sender's name if: The domain it was sent from doesn't match the domain in the "From:" address. For example, you got an email from john.smith@gmail.com, but it could've been sent through a social networking site and not Gmail. The email was sent to a Google Group from a domain that has a "p=reject or p=quarantine" DMARC policy. You can't remove the "via" next to someone's name. Gmail shows this information so you're aware of where your messages are coming from. It looks like our (my company's) SMTP server doesn't accept "those" emails. Is there something that could or should be done in that regard? G00gle says this: If you send messages using a bulk mailing vendor or a third party affiliates, check out Gmail's Bulk Senders Guidelines, including: Publish an SPF record that includes the IPs of the vendor or affiliates which send your messages. Sign your messages with a DKIM signature that is associated with your domain. Make sure the domain in the "From:" address matches the domain you're using to authenticate your emails.

Looks ok, icons are there too. Thanks.

It's not applied because AdminThemeDefault class is set on body, not on html. This is what I have now and it's working here: .Inputfields .InputfieldMarkup .InputfieldContent { margin-top: 0; } div#links { margin-left: calc(100% - 250px); text-align: right; position: relative; top: 35px; z-index: 103; } .AdminThemeDefault div#links { top: .5em; } #AdminActionsList { background: none; } .AdminThemeDefault #AdminActionsList { margin-top: 1em; } Mind z-index on div#links. Because there is no $info['icon'], see the php notice in my second screenshot: array (6) title => "Copy Content to Other Field" (27) description => "This action copies the content from one field to another field on all pages that use the selected template." (107) notes => "This can be useful if you decide you need to split one field into two to allow different settings on different templates. It also makes it easy to move content from one field type to another one that is incompatible." (216) author => "Adrian Jones" (12) authorLinks => array (3) roles => array (1) in ...\ProcessAdminActions\ProcessAdminActions.module:388

Tab is ok, link is not: