iank

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.