iank

No, unfortunately not - I've had to disable the AutoSmush (or at least disable the optimize on upload option in the module). I guess it's a case of keeping an eye open to monitor when they'll fix their SSL. It's affecting non-PW users too: https://wordpress.org/support/topic/ssl-certificates-expired-on-resmush-it-servers/ Regards, Ian.

Are you using the AutoSmush module by any chance, configured to use the reSmush.it service? I've encountered similar problems on a site with this installed, and there seems to be a problem with the SSL certificates on one or more of the reSmush.it servers since late December.

Excellent @Robin S, thank you very much!

Also, $sanitizer->pageName("raphaël", true) produces raphael. The second param being $beautify, which according to the docs: "Because page names are often generated from a UTF-8 title, UTF-8 to ASCII conversion will take place when $beautify is enabled."

Scenario: I'm importing a whole number of pages via the API which will have titles such as "A Page Title | October 2018" and "Another Page Title | November 2018" and so on. However, there are some duplicates (the titles come from repeaters in another PW installation; these may well have the same title, but a different photo, for example). So, if I'm importing several pages with the same name, let's say: "A Page Title | October 2018" "A Page Title | October 2018" "A Page Title | October 2018" PW knows how to increment page names when they would be duplicated. I want these to create page names like the following: a-page-title-october-2018 a-page-title-october-2018-1 a-page-title-october-2018-2 but instead, the generated page names are: a-page-title-october-2018 a-page-title-october-2019 <= a-page-title-october-2020 <= not what I wanted!! The same behaviour occurs in the PW admin too. Does anybody have a suggestion how to override this situation? Thanks, Ian.

@alexmercenary - Very strange! (as per the title of this thread!)

Hmm, that is weird! It appears as though the first call to a subsequent page number other than the base (1) is overwriting the cached page for the base, though I don't understand how that can happen. I presume you're using ProCache? If so, maybe check the versions of the cached files themselves: When you clear the cache and call the base (first) page and it's rendered correctly, does it save the correct cached index.html in the appropriate ProCache folder in assets? What happens when you then visit one of the higher page numbers, say /page5? Does this 'root' index.html file immediately get overwritten? Is there an index.html in the page5 folder in ProCache assets? How do these two compare? You can also access the cached files directly in the browser since you'll know your own unique ProCache folder structure. This would eliminate any (unlikely) rewrite rule problems.

Hi @alexmercenary, I don't think it's the same problem as I had - that was down to me not validating my UrlSegments. However I have had problems where the wrong "start" value is supplied to the selector, generally by being set by some other part of the code (some other selector with limit elsewhere in the code). I'm not sure that's your issue either, but it may be related. It seems that on your very first page of results, the "start" is somehow being set at a different value, and then this is being cached, generating the wrong set of results and corresponding pagination. If you bypass the cache (https://www.edmplus.co/uk-ltd/edm-consumables/?test=1) or explicitly specify the first page number (https://www.edmplus.co/uk-ltd/edm-consumables/Page1) then it works as expected. I'd look for something that could be inadvertently setting the start value or the $input->pageNum() when these aren't otherwise defined for the selector in question. Not sure if that helps, but maybe it's a start... Others more experienced may chip in!

Hi @adrian - I've submitted an issue to the PW issues github. As you say, it doesn't quite feel like a bug, but at least it's officially on record now.

Hi @adrian: Yes, I think that would work. At least then there is always something visible to the user for the key fields and button texts. I wonder if the cache thing may be an issue though, even if using template cache or WireCache. I'm not sure if there's an easy way around this. Sorry to keep adding problems Adrian..

@adrian That's true, I guess. In my case though, the site I've just launched and am using this on has news articles that may be populated with alternate language field values, though in the main, they are just in the default (English). Where one or more alternative language variant exists for an article, we render links to those alternate language variations. Visiting such a link switches the user's language setting so they can view any translated content in that language. Not quite the way Processwire's Language functionality was designed to be used I know, but it fits the client's needs. Since the site's now live I can show you the example alluded to in the screenshots in my earlier posts. If you visit https://www.traffic.org/news/kota-kinabalu-hosts-heart-of-borneo-judiciary-workshop/ and before accepting the cookie notice, click the "Francais" link, you'll see the problem. Such an article might have content in French, Spanish, Vietnamese, Japanese or Chinese (or any combination), so I'd need to get the module settings text translated for each of these, and remember to do this if we add new languages further down the line. However, a thought just occurred to me as I was writing this - the above site is heavily cached with ProCache. If a user from France say, visits a yet uncached page (say an 'ordinary' page without any language versions), I presume the page then be cached with blank (or translated) values for the cookie banner text etc.? Subsequent visits, regardless of the user's language, will get ProCache's static html version. Hmmm.... ?

Hi @adrian - no need to apologise! I can report a positive result though - the alternate language values are displayed if entered (see below). It appears to be just the fallback to default that's not being picked up.

@adrian Me again, sorry - I've just noticed something else a bit odd; I've used this in a multi-language environment, and see that the various fields for content and button text etc., are multi-language enabled. I haven't added any alternate language values for the text, but the banner doesn't seem to be picking up the default language values - instead I just see empty content areas and buttons for languages other than the default. See attached for English (default) and French versions of the same page. Default: French: I've only just noticed this, so it may be peculiar to this particular environment; I'll try it on a vanilla PW install and report back. Thanks, Ian.

Thanks @adrian - a bit late to the party today, but tested and all works fine, including iOS.

I'm on jQuery v3.2.1. Tried on several different browsers too, with the same issue. Changing to .prop as suggested by @wbmnfktr does seem to fix it.

Beat me to it @wbmnfktr ! I was just about to ask a similar question. I'm no jQuery expert but didn't recognise [method].

Adrian, I just noticed on the "Manage Preferences" banner, the two options "I accept" and "I do not accept" are checkboxes, meaning it's possible to select both of these, which could be confusing for the user. It only saves the "I accept" value to the local storage if both are checked, but if you popup the banner again without a page refresh, both checkboxes remain checked.

I am happy to implement this if it helps. I am curious though what scenario this is useful for - why do you prefer to manually inject them? @adrian I'd be happy to see this too if possible - so that we have the option to bundle/minify with the likes of ProCache..

@adrian: Perfect, thanks!

@adrian Thanks for this module - it's working great; Just one question - Is there a way to prevent it displaying inside an iFrame-embedded formbuilder form? It displays the banner in both the containing page and in the formbuilder iFrame. Thanks, Ian.

Thanks @adrian. Here's what I see: Does this mean mod_security is not running?

@BitPoet Thanks - that would make sense I guess. I don't know if mod_security is present, but I don't think I would have access to the logs; I'll make some enquiries of the hosting people. Cheers,

Here's a weird one: I'm working on a project at the moment that has several TextareaLanguage fields (setup with CKEditor) The field names are a little inconsistent, but they are as follows: body richtext richtext2 richtext_boxout rtsummary rtfooter notes They're not exactly the same, but some have been cloned from others. However, it seems the naming of the field affects the saving of the page when a relative link is added in the content. (Absolute or fully-qualified links are fine). Relative links are the only thing that causes this problem, and in a reproducible manner. The last three (rtsummary, rtfooter and notes) will not accept a relative link in the content. Depending on which server I run this on, I either get an immediate 403 Forbidden message, or a 404 Not found when I try to save. However, if I rename the fields (for example rtsummary => richtext_summary, rtfooter => richtext_footer and notes to richtext_notes). Saving the content with a relative link is fine. If I rename them back, the problem occurs again. I thought it may have been something in say, mod_security, but if that's the case, why would changing the field name allow the content through? And why are fully-qualified links accepted, but relative links not? I can't get my head around it. Also, I tried this with a single language textarea field too, with the same results. I found that for example, the following names don't work: notes, rtnotes, rt_notes, r_tnotes, and yet richtext_notes is fine. Environment is: PW 3.0.98, PHP 7.030. There are quite a few modules installed, but I haven't tried disabling them or trying this on a vanilla PW install. I can get around the issue by renaming the fields, but it would be good to get any suggestions! No errors are showing in Tracy Debugger. Thanks, Ian.

I believe you can do it like this in your config.php on an individual option basis: $config->imageSizerOptions('quality', 10); $config->imageSizerOptions('cropping', 'north'); ..and so on; this doesn't override any of the other defaults.

@dragan's suggestion may be the answer. I've had a similar problem with my cPanel accounts which have a PHP switcher. In my case using the switcher and changing from the default PHP version adds a PHP version handler snippet to the end of the .htaccess, something like: # php -- BEGIN cPanel-generated handler, do not edit # Set the “ea-php70” package as the default “PHP” programming language. <IfModule mime_module> AddType application/x-httpd-ea-php70 .php .php7 .phtml </IfModule> # php -- END cPanel-generated handler, do not edit ..and of course when you try this locally there is no such handler, so you are prompted with a download. Edit: Actually, re-reading your post, I don't think this could be the answer if other pages are working, sorry!