|
saddleupmt
|
June 24, 2021 at 12:31 pm
If I try to activate the Elastic Email Sender plugin, it crashes the backend of WordPress (white screen and won’t load). I went through and started deactivating plugins via FTP and realized that when I deactivated “event-espresso-core-reg”, the site started working again. Likewise, when I went into the WordPress dashboard and reactivated the Event Espresso main plugin, the site crashed again (when Elastic Email is also activated). Seeing as how Elastic Email is pretty popular for easy SMTP sending, is this something that you can help fix? Our registrations are on hold until you guys or Elastic Email updates their plugin or provides a fix.
|
|
Tony
|
June 24, 2021 at 2:09 pm
Hi there,
So the issue is that both Event Espresso and Elastic Email are defining a constant names EE_ADMIN, if Elastic Search defines it earlier than Event Espresso, EE will throw a fatal as it then can’t files based on the location normally set in the constant.
All EE constants are prefixed EE_, see here:
https://github.com/eventespresso/event-espresso-core/blob/master/core/espresso_definitions.php#L35
The Elastic Email plugin is using EE_ADMIN as a ‘flag’ to say if Elastic Email has loaded within the admin.
5 matches across 5 files: https://monosnap.com/file/kSWdCj6PKZj6lOqoUSgiJy8OrB4EOa
So to be honest, it makes the most sense for the Elastic Search Plugin to update that constant to something like EES_ADMIN which will require minimal change and the least amount of testing.
|
|
saddleupmt
|
June 25, 2021 at 10:03 am
Ok–so is that something I can fix, or do I have to take it up with Elastic Search to have them change it in their code?
|
|
Tony
|
June 25, 2021 at 10:07 am
You ‘can’ change the code locally, but if Elastic Search doesn’t make that change to the plugin then you’ll lose those changes when the plugin updates next time and be in the same situation.
|
|
Tony
|
June 29, 2021 at 8:55 am
Hi there,
Generally (as above) I don’t recommend changing core files of a plugin but I realised that although what I said above still applies, I think it’s worth letting you know the changes that need to be made for this to work to give you the option to use both at the time.
\elastic-email-sender\class\ees_admin.php Line 3:
Change: define('EE_ADMIN', true);
To be: define('EES_ADMIN', true);
Thats where the constant is defined, the next 4 files all use it in the exact same way:
\elastic-email-sender\template\t-ees_admin.php
\elastic-email-sender\template\t-ees_errorlog.php
\elastic-email-sender\template\t-ees_reports.php
\elastic-email-sender\template\t-ees_sendtest.php
Line 2 on each of those files has:
defined('EE_ADMIN') or die('No direct access allowed.');
Change that to be:
defined('EES_ADMIN') or die('No direct access allowed.');
That should be it, as it’s used as a flag there’s not much to test. It’s either defined or not and it’ll either work or you’ll see ‘No direct access allowed.’ on the page.
I looked to open up a pull request to have these changes considered by Elastic Email but looks like their repo isn’t public (or I’m completely missing it) but at least for now you know what needs to be changed.
|
