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?

Logged in as superuser, the unpublished copied page, in the frontend with selector "include=all" does return the url of the image, but surfing to it in site/assets/files gives a 'not found'. Which is fine since this is what the $config->pagefileSecure should do, restrict access to the unpublished page its images, if you try to get it publicly. But I was under the impression that regardless, you should be able to access the images in the admin backend, since this is where you manage the images, whether the page is published or not. This is not the case at the moment, when $config->pagefileSecure is on, you can't see the images of an unpublished copied page.

When $config->pagefileSecure is on (so you secure your unpublished page files) and you clone a page that has an image field, the newly created page (which is unpublished by default), does not show any of the images or thumbnails. You only get to see transparent thumbnails. Is this expected behavior? The "Secure page files" option mentions: Surely as a superuser or editor you should be able to see the images and thumbnails of an unpublished page, even if it's protected from public access? Or am I missing something?

There's a Github project that lists all 2FA sites and services. https://twofactorauth.org/ Maybe a good idea to add ProcessWire?

Anyone have an idea what could be the cause of a Page Reference-Page Auto Complete field to fail with a javascript error JqueryCore.js?v=1550490665:2 Uncaught TypeError: Cannot read property 'length' of undefined at Function.map (JqueryCore.js?v=1550490665:2) at Object.success (InputfieldPageAutocomplete.min.js?v=112-1550487061:1) at l (JqueryCore.js?v=1550490665:2) at Object.fireWith [as resolveWith] (JqueryCore.js?v=1550490665:2) at T (JqueryCore.js?v=1550490665:2) at XMLHttpRequest.r (JqueryCore.js?v=1550490665:2) Even when making a new auto complete field, default settings with a simple template selector, and new page with just that field in it. Running PW 3.0.125 (and 126, same result). Tested it on another 3.0.126, and there everything works fine, so it's probably not related to the core jQuery. Edit, never mind, the admin > pages > search was disabled. Making the autocomplete search, well, not functioning.

There are serious issues with this module running PW 3.0.123+. Didn't have time to debug properly, but on different sites the pim2load didn't work anymore. Two different examples that didn't work anymore: $img->pim2Load('img_name')->width(640)->grayscale()->setQuality(80)->pimSave()->url; $img->pim2Load('img_name')->setQuality(90)->setOutputFormat('png')->canvas(240,160)->pimSave()->httpUrl; I ended up disabling the module and using core image manipulations (except for the grayscale... it looks much better in color anyway ?)

thanks for the advice, I submitted it as an issue.

Not sure where to post this, I'm hesitant to file it as a GitHub issue. I noticed that in the database's image fields, the fractional part of focus values are a bit overkill: e.g. {"focus":{"top":93.400000000000005684341886080801486968994140625,"left":49.39999999999999857891452847979962825775146484375,"zoom":0}} Don't know that it matters much, but hey, the super-extra-hyper-10x-Retina displays aren't on sale yet, so... ?

You are correct,, it was 6 significant digits I had 15248.01 that changed and rounded to 15248. But I wrongly used 15248.25 in my example. I'm using the decimal field from now on. But I'm very frustrated that for some reason this is not stated very clearly anywhere in ProcessWire. I've used lot's of float fields in the past 5 years, also for webshop transaction data saved in PW. Luckily the total amounts were never greater than 10000, but it could have been worse... Just stumbled upon it when revamping an invoicing system and porting it's data to PW. I've literally been shortchanged ?

I know it's an old problem, but is the float rounding broken in 3.0.124 ? Or did it never get solved? Precision set to 2 digits, but numbers greater than 10000 are rounded to the closest integer, without precision. ie. 15248.25 is changed to 15248. Everything below 10000 works fine.

An amazing Master update, full of goodies to start the new year with, thanks Ryan,