JFn

Oh my, I must be getting old ☺️. That's the thing with processwire, you set it and forget it, it just keeps on running ?

After a second look, apparently the offending HannaCodeHelper module was installed, although I don't recall installing it, was it part of the previous version by default? Anyway, disabling it, no more errors, problem solved.

Although the issue is closed, I commented on it, since it's the same error but not the same resolution or offending module installed.

In the latest version 2.0.1 from April 9, the padding-bottom {pct} variable sometimes results in an invalid CSS value, like 56,25% (with comma) This value should be locale independent, so please use an intval or use forced dot notation in the calculation. Thanks

Latest update 0.3.0 from April 6 is giving an error.

I've been running MariaDB 10.4 with InnoDB engine on multiple sites since more than a year without any issues.

Hello @teppo, when using the module with @ryan's TOTP two-factor authentication, the user is logged as "Successful attempt: NO", and the user id instead of the name. is displayed in the "WHO" column. Probably because the login process has an extra TOTP code screen.

Ah that's where the hickups came from. Maybe drastic, but we block all website traffic from China and email senders from Russia. Seems to handle 90% of rogue request. Beside that a few .htaccess lines to stop bad bots, scrapers, or scanners in our server area. Updated regularly after skimming through error logs. # bad bots RewriteCond %{HTTP_USER_AGENT} ^.*(Ahrefs|MJ12bot|Seznam|Baiduspider|Yandex|SemrushBot|DotBot|spbot|adscanner).*$ [NC] RewriteCond %{HTTP_USER_AGENT} ^.*(python|masscan|Researchscan|twotweak|site\.ru|X11|yacybot|netcraft).*$ [NC] RewriteCond %{HTTP_USER_AGENT} ^.*(BLEXBot|SemanticScholarBot|Nimbostratus|Mb2345Browser|UCBrowser|MQQBrowser).*$ [NC] RewriteCond %{HTTP_USER_AGENT} ^.*(LieBaoFast|yacybot|seocompany|Vagabondo|zoominfobot).*$ [NC] RewriteRule ^.*$ - [F,L] I see the same usual suspects in your blog post ?

I ran into a specific multilanguage problem. When setting the default language C parameter of LanguageSupport to nl_NL.UTF-8 (or nl_BE.UTF-8), then the Color module hsl return value has a comma as decimal separator, which is not a valid CSS value (or a valid hsl value for that matter). Example with dutch locale: hsl(195, 96,2%, 59%); Should always be: hsl(195, 96.2%, 59%); no matter the chosen locale. (note: the comma is the expected/normal decimal separator in dutch, so it's not a LanguageSupport mistake)

Since most Operating systems support unicode file names, I'm wondering why PW still sanitizes (image) filenames to [-_.a-z0-9] characters only. I've used @adrian's Custom Upload Names module before to change file names, but it still depends on @ryan's core Pagefiles->cleanBasename, which strips out all non ascii characters. HDPI images are often named "image@2x.jpg" and from a copyright perspective "image©2019-company.jpg" would be far more practical (obvious) than hidden exim data. Something like "image-ab&cd.jpg" or "image(v2).jpg" isn't a weird thing either. Linux, Windows and MacOS can all handle this kind of file names, and offcourse modern browsers too. Is there any particular reason why this couldn't be implemented as a default in PW?

@flydev Great module. It would be nice to have/force a different language or multi-language support. Right now Google renders the widget in what it thinks is you native language. For me that's Dutch, although the html lang="en", the site's default language and my browser is in English as well. This could be done via a simple extra parameter in your module's getScript() and a "hl=langcode" setting, ie.: <script src='https://www.google.com/recaptcha/api.js?hl=en'></script> There's a list at https://developers.google.com/recaptcha/docs/language Edit 1: Already figured out you can do this via the ->render("","en") method. Edit 2: Somehow that's not working. But I expect it's Google's fault. It renders "en" but still displays it in Dutch. Edit 3: It was Google's fault. When you're logged in with your Google account in Chrome (aka 'sync') it will take the language of that account, no matter what language you asked the widget to be. Google always knows better™ ?

I've just implemented Strategy #1 on an image-heavy website (full-screen backgrounds, image galleries). Works like a charm, savings go up to 80% for some images! You mentioned: I also thought this is a benefit, however for me it doesn't work as you describe. When downloading the image, the original jpg is still fetched, not the webp with jpg extension, although the Chrome network console clearly states that it's a webp that's loaded into the page. I tried with and without commenting out the '-strmatch 'nc=*' line.

Update My bad ? after a checking everything again, I did have an old custom change I forgot about in the htaccess file... (Directive #18. where Ryan put in a warning that it could produce a 404 in combination with $config->pagefileSecure) Thanks Hero's for looking into it.

Doesn't even need to be a copied page. Just $config->pagefileSecure to on, and unpublished pages do not show images anymore in the admin backend. Maybe a server setting? I did not do any custom changes to the pw 3 htaccess file.

yes, there is a 404 for the image in the backend admin. If I go directly to the asset url the same 'not found'. Are you sure you made a copy of an existing page and kept it unpublished? In this instance I'm on 3.0.123, but it's not version related, because I had it before in the past, with older versions, and even with another host. Something else I noticed, the image field states the correct Dimension and Filesize, but initially zero (0) Variations. Maybe the variations don't get copied correctly when keeping the page unpublished and assets page files secured?