iank

@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!

Ha, thanks! I'm not a 'proper' programmer but I don't like it when I can't establish a logical explanation. It's been raised as a fault to the hosting team and they're looking into it..

Update: It seems that function_exists() is broken in some way on PHP 5 versions in this particular hosting environment. It returns false when passed a namespaced function name (as per the FileCompiler compiled module files). It should return true, as the function is certainly present and callable. I've done some tests and it's not Processwire related; the same issue is present in vanilla PHP scripts. If I switch to PHP 7 function_exists() once again behaves as expected.

Still haven't resolved this. Some further information which may be of help: PW Version 3.0.62 Formbuilder Version: 0.3.0 WireMailSMTP Version 0.2.5 (was 0.2.2 but upgrading made no difference). PHP Version was 5.4.28 on dev, 5.6.31 on live. Tried switching to 5.4.45 on live, no improvement. Still not sending via SMTP, and still not able to hook WireMail::send on live. Have attached Tracy Debugger but no obvious errors detected. Update: I'm getting a bit closer to the root of the issue. When FormBuilder comes to send, it does a check to see if the wireMail function exists: if(function_exists('wireMail')) { ... $result = wireMail(...) } else { ... $result = @mail(....) } So I put some breakpoints in and it transpires that function_exists('wireMail') is returning false on my newly upgraded cPanel hosted sites. The reason that I can't hook is that it then goes on to use the mail() method directly, bypassing WireMail completely. ... so why would the function_exists() return false all of a sudden? What could change in PHP that would create this issue? I may cross-post this last updated info in the FormBuilder forum; hopefully Ryan can pick it up and provide some insight.

Hi, Didn't know where to post this, so have gone for this subforum. I have a few PW sites with a UK host, on a Reseller account. They are all using a combination of Formbuilder and WireMailSMTP to send the results of enquiry forms. I have WireMailSMTP set up with my Mandrill account settings, and everything worked fine. Nothing too unusual here. I have similar setups on another host, everythings OK. A couple of days ago the first hosting company (and my preferred one) upgraded the cPanel to include EasyApache and the ability to easily switch PHP versions. I think they're going to provide LetsEncrypt shortly too, but that's unrelated. Suddenly, the system has stopped using SMTP and appears to be sending via the default WireMail settings/PHP mail. The mails are getting sent (as far as I can see), but not going through the Mandrill authenticated route, so some are getting into junk mail folders. I try the same site/codebase on my internal development system and it still sends via WireMailSMTP's Mandrill settings, but not on the live host. PHP versions are slightly different, but both 5.4 variants. What's even weirder is that during troubleshooting I set up a hook to WireMail::send to see if I could log which class it's using (and other params). This works fine on the local dev system and shows all the expected settings. On the live system, the hook doesn't even fire, so I can't confirm it's using WireMail's send() even. The hosting company have been quite helpful and we've spent all day trying to resolve this, but they've run out of ideas and I'm getting to the same point. Can anyone throw any possible light/offer any suggestions? Much appreciated, Ian.

@Robin S Thanks - I came to the same conclusions as your first two points during further testing too. I'll open a GitHub Issue. Cheers! Ian.

Hi, I have a text field called refcode that I wanted to add to the fields searched by the Ajax Admin Page Search, so was able to add it in the Module Settings. The default search operator I've left unchanged at "%= Contains phrase/word using LIKE". The refcode field contains something like "ABCD000126". If I type a three or less character search term, e.g. "126" or "012" in the admin search box, the ajax search finds a match. However if I type a longer term, e.g. "0126" it doesn't. It seems that if the search term is more than three characters the ajax search switches from "%=" to using "*=" and I guess this may be looking for word boundaries? The only way I can get a match for more than three character search term is if I enter the full value "ABCD000126". Strangely, if you press enter to display the actual results list, all of the above search terms will display matching results, so this must honour the default search operator "%=". It's not a huge problem, but if I wanted to find just the record with refcode "ABCD000012" I would need to enter "012" but this would also return "ABCD000126" and "ABCD001200" as well. I wonder if this is the intended behaviour? I'm on master version 3.0.42 with default theme. Thanks, Ian.