Jump to content

JFn

Members
  • Posts

    62
  • Joined

  • Last visited

Posts posted by JFn

  1. 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.

    • Like 1
  2. On 9/29/2020 at 12:41 PM, Sevarf2 said:

    Anyone tried MariaDB 10.3 or 10.4 ? The new amazon aws database service starts with 10.3.

     

    On 10/7/2020 at 10:17 PM, StanLindsey said:

    Also looking to check out latest MariaDB versions. 

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

    • Like 1
    • Thanks 1
  3. 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 ?

    • Like 4
  4. 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)

    • Like 1
  5. 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?

    • Like 1
  6. @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.

    image.thumb.png.46c33a2b020256f9ce6c2a50e2665de5.png

    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™ ?

    • Thanks 1
  7. 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:

    Quote

    One drawback (or benefit?) to consider: If the user downloads the image for some purpose other than viewing it on the website, they probably won’t be able to because it’ll result in a WEBP image with a JPG or PNG extension.

    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.

  8. 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.

  9. 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.

  10. 3 hours ago, wbmnfktr said:

    Are there 404 or other warnings in the console > network tab?

    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?

  11. 8 minutes ago, dragan said:

    is this in the frontend or backend? Or both?

    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.

  12. 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:

    Quote

    When, true, prevents http access to file assets of access protected pages.
    Set to true if you want files on non-public or unpublished pages to be protected from direct URL access.
    When used, such files will be delivered at a URL that is protected from public access.

    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?

  13. 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.

  14. 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 ?)

  15. 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... ?

    • Like 3
  16. 1 hour ago, Autofahrn said:

    The interesting point is, that my limitation differs, as I get 6 significant digits.

    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.

    18 hours ago, Robin S said:

    Best to use the Decimal fieldtype in cases where the limitations of the Float fieldtype are a problem.

    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 ?

    • Like 1
  17. 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.

×
×
  • Create New...