|
chrisscottuk
|
August 23, 2016 at 2:33 pm
Hi there,
The support license key in general settings, will not stay green, and changes to red. If I re save the page it will go green, but quickly changes back to red.
I’ve had this for a few 4.9.x versions now, so I can’t upgrade until I go to the settings page, and re save the page.
I’ve tried a manual install of latest version, by removing all plugin files, and doing a manual file transfer, but the problem still exists.
Any ideas?
|
|
Tony
|
August 24, 2016 at 2:36 am
Hi Chris,
Is this a single or multi-site install?
|
|
chrisscottuk
|
August 24, 2016 at 3:46 pm
Hi Tony, it’s a single site.
|
|
Tony
|
August 25, 2016 at 4:28 am
Hmm, ok.
So looking over your account everything looks fine (I remember checking this a little while ago too) and looking through the pings we receive from your server that looks fine too.
When you say it quickly changes to red, how quickly?
I’m wondering if maybe the severs firewall is blocking some of the requests which then causes the key check to ping, it would be strange that the manual update checks (when you save the general settings) then work but its possible.
I’ll ask one of our developers for some feedback.
Do you have access to the server errors logs? Could you check there an see if any errors are being thrown relating to EE. You may need to enable WP_DEBUG first, resave the settings and wait for the key to change to red, then check the logs again.
|
|
chrisscottuk
|
August 27, 2016 at 3:13 pm
Hi there,
I’m not certain but I think it only turns red when there is a new update. As since posting the above it remained green, then today I noticed there was a new version of EE available, and it was red again.
I haven’t checked error logs yet, and will enable WP_DEBUG shortly. I may need to wait until the next EE version to pick the problem up.
Thanks for your help,
Chris
|
|
Josh
|
August 29, 2016 at 4:07 pm
There’s an example in the WordPress codex that shows how to set up WP_DEBUG so it logs the errors only and doesn’t display the errors on the screen. Which is the best practice when it’s a live site.
https://codex.wordpress.org/Debugging_in_WordPress#Example_wp-config.php_for_Debugging
|
|
Josh
|
August 30, 2016 at 10:03 am
The developer of the plugin update engine would also like to take a look at the site? If possible, can you send some temporary access (including FTP or c-panel access) via the secure form on this page?
|
|
chrisscottuk
|
September 14, 2016 at 11:21 am
Thanks Josh and Tony, I haven’t got around to creating the access for your developer yet, but didn’t want you to think I’d forgotten.
I’ll get to it as soon as I can.
Kind Regards,
Chris
|
|
AMTA Admin
|
September 20, 2016 at 1:02 pm
I have this exact same issue. It’s annoying, but doesn’t break anything for me. I only notice it’s doing it again whenever WP gives me an “update available” message. It’s true of any time there’s a core or add-on update, so I assume it happens often. I resaved the general settings after turning on debug_log and will see how long it takes mine to turn red again.
|
|
Josh
|
September 20, 2016 at 2:14 pm
@AMTA Admin, since we haven’t heard from Chris, maybe you can send some temporary access (including FTP or c-panel access) via the secure form on this page so someone can investigate further?
|
|
AMTA Admin
|
September 22, 2016 at 12:02 pm
Sent.
For reference, WP debug.log has this:
[20-Sep-2016 20:01:27 UTC] PHP Warning: preg_match() expects parameter 2 to be string, array given in /wp-content/plugins/event-espresso-core-reg/core/third_party_libs/pue/pue-client.php on line 658
|
|
Josh
|
September 22, 2016 at 1:41 pm
Yeah so that line has $this->api_secret_key as the second parameter and that should be the license key which is a string. So apparently something on your site is highjacking that incoming value and changing it into an array.
|
|
AMTA Admin
|
September 22, 2016 at 2:47 pm
Considering plugin integrations with APIs like AWS and dozens of other APIs that use secret keys, I have no idea where I would start to look for what’s asking for api_secret_key. It must be coming from a mistakenly public function in one of them. I don’t use little-known plugins on this site and ones that mention API keys include, but are not limited to:
Smart Slider 3 (social media APIs – various)
Updraft Plus (AWS, Dropbox, etc)
s2member (authorize.net, paypal, stripe and captcha)
Ninja Forms (captcha)
Those plugins are required on this site, so I’d have to have a different API key for my local/test site or a way to test for this without disabling those plugins.
|
|
Josh
|
September 23, 2016 at 12:30 pm
The developer of the Plugin Update Engine for Event Espresso will look into this further once he has a block of time to do so.
|
|
chrisscottuk
|
September 29, 2016 at 4:26 am
Hi everyone,
apologies for the delay. I’ve been waiting for a block of time to setup secure access for event espresso team to access my server to have a look round. Alas, I’m in a really busy period and haven’t been able to get to it yet. (I learn as I go with the server configurations, and no longer use cpanel so it takes me a bit of time)
Anyway – it seems to be working now, as it’s just upgraded perfectly to 4.9.13 using the wordpress updater.
Unless something has changed on the event espresso side, I have recently made 2 changes to my setup – which might help identify what has been going wrong.
1) Wordfence was upgraded to 6.2.0
2) and my hunch is that this is the issue – I amended the patterns the the security plugin BBQPro blocks, removing ‘ REQUEST% ‘ from the advanced patterns.
I did this, as I realised that this pattern being blocked was causing another problem in EE I encountered a few days ago.
The upgrading now works. EE are you able to clarify if you use ‘ REQUEST% ‘ in the query string of the updater. IF you do, then this would clarify what the problem is, and the fix for BBQ Pro users is simple.
AMTA admin – do you use BBQpro? or wordfence?
|
|
Josh
|
September 29, 2016 at 7:28 am
Thanks for the update. The update engine that’s included with Event Espresso does not use REQUEST in the query string. There could be a domino effect of all kinds of crazy if the PHP $_REQUEST global was affected though.
|
