|
BCPTA
|
May 3, 2016 at 11:51 pm
Hi there, for some reason we can’t log in to our staging site.
It has a white screen that says this Fatal error: Call to a member function get_page_permastruct() on a non-object in /nas/content/staging/bcpta/wp-includes/link-template.php on line 350
WP Engine wrote me this:
It appears that this issue is being caused by the event-espresso-core-reg plugin. I went ahead and deactivated that for you, and I am now able to log in without issue. You may want to reach out to this plugin’s developer for direct assistance since they will be familiar with the code of the plugin.
So then, I tried to replace the plugin with the latest version. But as soon as I activated it, I got this message again, on the white screen:
“Fatal error: Call to a member function get_page_permastruct() on a non-object in /nas/content/staging/bcpta/wp-includes/link-template.php on line 350”
Temporarily I renamed the folder in the plugins folder by adding a ‘1’ before it. Just to deactivate it for now so I could access the site.
Can you please help?
Access to our staging site is the same as it was when we wrote you a few weeks ago I think it was.
I don’t mind sending it again if you need it.
|
|
Josh
|
May 4, 2016 at 6:40 am
Hi Johanna,
It turns out we don’t keep credentials after we’re done, can you send the credentials for the staging site by filling out the form on this page?
https://eventespresso.com/send-login-details/
Along with that, can you let us know if the same issue happens on the live site? If it doesn’t, can you let us know what’s on the staging site that’s different from the live site? (eg. plugins, theme customizations, etc)
|
|
BCPTA
|
May 4, 2016 at 4:26 pm
Hi Josh, i resent the access
I only copied site from live to staging using the WP Engine system to do that
I don’t know there are any discrepancies except that now I’ve upgraded the EE4 plugin folder on the staging site, as explained earlier.
AFTER I wrote to you I also installed a new plugin for store locator plus to manage user access. It’s called “Store Locator Plus : User Managed Locations”. You can remove it if you want, we are just testing it out.
I wrote to WP Engine to say ‘hey, why does this work on live but not on staging?’ and they basically said it’s your problem because EE4 made the plugin and the plugin might be looking for a url or something-something-something. I don’t like that answer but for now can you let me know if it is something with your plugin? It is mysterious that deactivating the EE4 plugin on the staging site is what makes the problem go away.
There is no caching on staging.
Thanks
|
|
Josh
|
May 4, 2016 at 5:30 pm
I don’t think the error is exclusive to EE4 or we would see it on other sites. Also, I found that if I deactivate the Theme My Login plugin on the staging site, it allows me to log in to the staging site as admin while Event Espresso 4 is activated. That’s also mysterious because I have Theme My Login running on other sites with Event Espresso and I’m not seeing any issues there.
|
|
BCPTA
|
May 9, 2016 at 3:44 pm
I’m running this by WP Engine, thank you
|
|
Josh
|
May 9, 2016 at 9:16 pm
You’re welcome.
|
|
BCPTA
|
May 16, 2016 at 9:13 pm
Hi Josh. Ok, so I had A LOT of back and forth with WP Engine, and they escalated this to Tier 3, and that took days.
In the end, when they basically gave up, I had to deactivate one of the culprit plugins, then update everything, then re-activate that one culprit plugin (though there were 3), and then after that it worked.
But…I’m really hoping this won’t happen again. So I have some questions I hope you can help me answer, just to equip my knowledge for future cases.
I’ll also try to give context as to why I’m asking these.
This is what we found out. I realize it’s still inconclusive, but nonetheless, it’s worth mentioning because I still can’t get this resolved on my end, and would like to get clear on how EE4 works to see if this can be narrowed down more.
The staging site worked when any of these plugins are deactivated:
Event Espresso 4
Theme My Login
Yoast SEO
It only took one of any of these three to be deactivated in order for the problem to go away.
The guys at WP Engine said that the plugin could be looking for a URL, and that would cause it not to work on a staging environment. Here is how they explain that:
Our system will create a copy of the files over to the staging area, then will export the database from the live site. The database is imported onto the staging site and we run a search and replace to change the domain name from the live domain to the staging domain. This search and replace is run on the majority of tables that are common to wordpress, but it doesn’t always get all references that some plugins require to function properly. This difference can cause odd behaviors with some plugins.
My questions here are:
Does EE4 look for a specific URL in any of its tables?
I noticed our license doesn’t work on the staging site, which means we have to manually update plugins to test them. This is kind of annoying and I wrote to you guys asking if we could get a license for our staging site as well. Nonetheless, curious if this has something to do with it.
They also said this:
The staging site is not cached and doesn’t use memcached for object caching
Do you know if this would affect EE4? I realize we needed to uncache parts of EE4 to make it work on the live site, so I’m guessing no, but just checking.
They are sure it was just a php thing and only to do with plugins. The other weird thing is that from their end, they could log in to the back end of the staging site fine, as well as copies of the site on other staging installs they made. But we never could, no matter what account we used.
Also, when they copied the site to a ‘live’ version of a temporary domain on their system, the problem also did not occur. At least it didn’t one time. So there seems to be something going on with the way the staging sites work on their system specifically that interacted with one of the three plugins mentioned above.
Any thoughts?
I realize this is a needle in a haystack. I was just hoping you could help me identify the answers to questions given above for future knowledge.
|
|
BCPTA
|
May 16, 2016 at 11:22 pm
Well, it looks like I spoke too soon. I tried going back to the site with Yoast SEO activated and I don’t know why but it doesn’t work anymore. I deactivated it, and still no go. So I deactivated EE4 and then I could access the Staging dashboard. Sigh.
|
|
Josh
|
May 17, 2016 at 10:46 am
The one component that was overlooked is the Password authentication that’s active on your staging site. I think you’ll find that if that’s disabled, you won’t see the fatal error when the 3 plugins are activated at the same time.
Or, you can disabled the JSON API basic Auth plugin that’s bundled with Event Espresso by going into /core/EE_System.core.php then go to line 199 and look for this code:
include_once EE_THIRD_PARTY . 'wp-api-basic-auth' . DS . 'basic-auth.php';
then comment it out like this and save the file:
// include_once EE_THIRD_PARTY . 'wp-api-basic-auth' . DS . 'basic-auth.php';
|
|
BCPTA
|
May 19, 2016 at 8:01 pm
Hi Josh, I disabled the password protect on staging but it didn’t take the error away.
If I make this update to the EE core file, will it be over written on each update? Is there a way to prevent that or make it more permanent? Or even just specific to our staging site when we copy from live to staging in future instances? I realize that may be asking a lot. Just curious what the implication will be in the long run.
|
|
Tony
|
May 20, 2016 at 5:27 am
If I make this update to the EE core file, will it be over written on each update?
Yes it will.
Is there a way to prevent that or make it more permanent? Or even just specific to our staging site when we copy from live to staging in future instances?
Not currently but we are looking into various options for this within EE core itself, if you make the above change we at least know if that is what is causing the problem on your site.
If there’s a problem that means something needs to be disabled within core we wouldn’t expect users to need to modify core after multiple updates, however we need to narrow the cause down whilst we work on a fix 🙂
|
|
BCPTA
|
May 22, 2016 at 12:03 am
That code did the trick for us. Hope this information helps. Thanks a bunch. We really appreciate all the attention you guys give us.
|
|
Tony
|
May 23, 2016 at 4:24 am
Thank you for letting us know.
We have a ticket for adding a setting to allow users to change this within core and this thread has been added to that so when we release this in an update to EE we will also post here.
|
|
Josh
|
June 16, 2016 at 1:30 pm
They actually found a way to avoid the fatal error caused by the bundled Basic Auth plugin and included the fix in Event Espresso 4.9.1.
|
