Plugin Author
Franky
(@liedekef)
I’m guessing something is blocking the correct output. What is the error you’re seeing? And is there something in your browser console and/or php errorlog files?
And what is the version of php and wordpress?
PHP version 7.4.30
WP version 6.0.1
When attempting to add a new Event: “Database insert failed!”
When attempting to add a new Location:
WordPress database error: [Table ‘<DBNAME REDACTED>.wp_eme_locations’ doesn’t exist]
SHOW FULL COLUMNS FROM wp_eme_locations
WordPress database error: [Table ‘<DBNAME REDACTED>.wp_eme_locations’ doesn’t exist]
SHOW FULL COLUMNS FROM wp_eme_locations
as well as:
“There has been a problem adding the location.”
and…. this just pointed me somewhat in the right direction! The tables that got created in my database by the plugin do not include the table prefix (they exist as <DBNAME>.eme_XXXXX and not <DBNAME>.wp_eme_XXXXX
Plugin Author
Franky
(@liedekef)
EME takes the prefix as configured by WP (the global variable $wpdb->prefix in fact), so if the tables are created with a “wrong” prefix it means something is wrong when you created/activated the plugin. Is it possible you have some plugin that changes the prefix but did not update your wp config accordingly?
Oddly, the plug-in appears to be calling the correct table name everywhere else as these are the errors I’m seeing when I turn on error logging:
[Table '<DBNAME REDACTED>.wp_eme_bookings' doesn't exist]
SELECT count(bookings.booking_id) FROM wp_eme_bookings AS bookings LEFT JOIN wp_eme_events AS events ON bookings.event_id=events.event_id WHERE bookings.status IN (2,3) AND events.event_end >= '2022-08-16 11:45:03'
WordPress database error: [Table '<DBNAME REDACTED>.wp_eme_members' doesn't exist]
SELECT COUNT(*) from wp_eme_members WHERE status=0
Somehow the initialization script did not properly pull the prefix and created them without one at all.
I just deleted the plugin after setting it to delete all settings, etc. and the tables were properly deleted from the database. After re-installing, the tables were once again created without any prefix and the above errors looking for the tables with the prefix are immediately thrown.
EDIT: To confirm – the db prefix is set properly in wp-config and there are no plugins being used to modify the prefix at all.
-
This reply was modified 3 years, 9 months ago by
dustinkk. Reason: Additional info
Plugin Author
Franky
(@liedekef)
The plugin never assumes any prefix. Even “wp_” is coming as info from wordpress. Is the plugin installed in multisite or so? How did you change your db prefix?
And is your wp-config.php correctly changed to use that prefix? See e.g. https://www.bettertechtips.com/wordpress/change-wordpress-table-prefix/
This is a single site, no multisite configuration.
The db prefix is default and properly set in wp-config. The scripts all properly reference the expected prefix post installation, it is only the initial table generation (and apparently removal, since those were also handled properly) that seem to not be utilizing any db prefix at all for some reason (these were all created as eme_<tableName> with NO prefix at all).
I went in and manually renamed the tables that were created to include the prefix and everything is working properly for me but figured I would update you in case there’s an underlying bug that may cause this for someone in the future.
Plugin Author
Franky
(@liedekef)
Arghh … you just pointed me to a new weird thing in wp. The $wpdb variable is not correctly initialized during plugin install/deinstall unless you include a specific php file. While I used to do this directly, I now used a function (in the latest version) to get the prefix (during install, uninstall and regular plugin function) and I did not take that into account correctly. I’ll correct and release a new version asap (after some testing).
Plugin Author
Franky
(@liedekef)
I just released a version that should work as expected for new installations.
