|
Moz Nugent
|
June 24, 2016 at 7:47 pm
Like others on this forum (threads since closed for comments), I got more than a dozen error messages in admin saying there are errors with various tables, along these lines: “Database table j58_esp_tablename existed when it shouldn’t.”
I’ve followed the instructions to drop bad tables using the config file , but they persisted. So I dismissed the messages one by one – one or two returned afterwards. I dismissed a second time – no further instance so far.
My client is hyper sensitive to these issues, so I need to check if there’s any way to avoid a repeat instance. Here’s the status at the moment:
There are no flags in EE Maintenance > System Status, other than increase upload limit from 8Mb to 64Mb.
I’ve checked the database for errors in cPanel – none found.
We run regular backups of the database, but we have never restored from a backed-up database at all.
I’m using EE 4.9.1 on WP 4.5.3 (php 5.5.36). We implement all WP and EE updates as they become available.
|
|
Lorenzo Orlando Caum
|
June 25, 2016 at 11:19 am
Hello,
I’ve seen that in testing on Godaddy hosting and I have not been able to duplicate it on some other web hosts. Which web host are you currently using?
—
Lorenzo
|
|
Moz Nugent
|
June 26, 2016 at 7:30 pm
It’s Ventra IP. They’re pretty solid with keeping up to date. Has it got anything to do with Lightspeed? Wordfence is always complaining about that in relation to auto updates.
|
|
Tony
|
June 27, 2016 at 5:20 am
Have you previously re-stored a backup of the database on this site?
It might help to explain why those errors are thrown.
EE checks the previous versions that have been activated on the site and compares the tables within the database with the tables that ‘should’ exist based on the last version installed. If there is a difference in what is available and what should be there it throws a notice stating that (the notices you previously saw).
However if this was just an update without previously restoring a database backup etc then something has caused the check EE does to throw a notice on every table.
If you view Event Espresso -> Maintenance -> System information.
Look at your ee_activation_history, does it show the previous version you had activated or just the latest?
There are no flags in EE Maintenance > System Status, other than increase upload limit from 8Mb to 64Mb.
EE does not recommend raising the upload limit from 8MB, do you mean WP_memory? This notice – http://take.ms/wYBS2
Has it got anything to do with Lightspeed?
Possibly, although I run lite-speed on one of my test sites without a problem.
|
|
Moz Nugent
|
June 27, 2016 at 7:20 pm
No, as mentioned in my initial message, there’s been no re-stored database activity, just updates to EE and WP.
The activation history just shows the current version – 4.9.1.p – 2016-06-21 02:39:40.
Correct, that should have read wp-memory (I’m too used to seeing this for upload limits).
|
|
Tony
|
June 28, 2016 at 5:31 am
The activation history just shows the current version – 4.9.1.p – 2016-06-21 02:39:40.
I’m assuming you’ve had previous versions of EE installed?
If so then the problem is that as far as EE can see the site has not had any previous versions of EE installed but it then found multiple EE tables within the database so it throws the notices. It won’t cause any problems in that situation (other than the notices) but means that something has removed the option from the database that tells EE which previous versions have been installed (espresso_db_update within wp_options), do you run any plugins that ‘maintain’ or ‘optimize’ the DB?
There are no flags in EE Maintenance > System Status, other than increase upload limit from 8Mb to 64Mb
8MB is very low and I doubt that is the value that is actually being used (if WP_MEMORY_LIMIT is set lower than your server memory_limit value, the WP_MEMORY_LIMIT value is ignored), on the same page you can view memory_limit and will find a local and global value there, what are they?
Or you can simply increase the limit set for WP_MEMORY_LIMIT set within wp-config.php by adding something like this:
define( 'WP_MEMORY_LIMIT', '96M' );
Or editing the current value if its already there.
More info here:
https://codex.wordpress.org/Editing_wp-config.php#Increasing_memory_allocated_to_PHP
|
|
Moz Nugent
|
June 28, 2016 at 9:33 pm
Correct, we’ve had previous versions. We’ve always been on 4, but I don’t recall which version specifically (circa late 2015). The only reference to other versions I can find on the system info tab is mention of migration from 4.9.0.
We optimise the db regularly using remote app via a plugin (ManageWP). This site seems to generate a lot of overhead – more than than average at least.
The global and local memory_limit values are 128 and 256 MB respectively.
|
|
Tony
|
June 29, 2016 at 5:28 am
The global and local memory_limit values are 128 and 256 MB respectively.
So you will be using at least 128MB, which is fine.
We optimise the db regularly using remote app via a plugin (ManageWP). This site seems to generate a lot of overhead – more than than average at least.
Hmm, it may not have been that plugin and I can’t say for sure why but espresso_db_update looks like it has been removed. It basically just stores your activation history so won’t cause any problems with the plugin and now you have a value within the option again (the current version of EE) the next update should not cause any notices to be thrown.
I’ll check in with our developers and see if they can provide any feedback for this.
|
|
Moz Nugent
|
June 29, 2016 at 7:53 pm
Thanks Tony. If it helps, I have a vague memory of a message box from EE in the admin area asking us to run a check/update of the database (or words similar) following one of your recent updates (which we did). Can’t say for sure this caused the file you mentioned to be removed.
|
|
Tony
|
June 30, 2016 at 3:08 am
That sounds like an EE migration which is normal and should not cause that option to be removed.
Do you have a backup of the database from before this happened? I’d like to take a look and see if there are any clues to why this may have happened.
|
