When people contact me with reports that RSVPMaker is misbehaving in some way on their websites, figuring out whether the problem is due to a flaw in my code and/or interaction with some other plugin is tricky business. This can be made more complicated by WordPress features that hide error and warning messages from being publicly displayed — a good practice, but one that can frustrate access to debugging information.
Here’s the debug logging setup I recommend adding to wp-config.php – so you can track down errors when necessary without them being publicly displayed:
@ini_set( 'display_errors', 0 );
// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );
// Disable display of errors and warnings
define( 'WP_DEBUG_DISPLAY', false );
// Enable debug logging to file, ideally outside of public_html
define( 'WP_DEBUG_LOG', '/home/mysite/debug.log' );
@ini_set( 'display_errors', 0 );The debug file location will vary based on your server setup, but for example on my sites /home/mysite/public_html/ is where publicly visible files go, so /home/mysite/ is a more secure location for a debug log that you don’t want someone attacking your site to be able to access (bugs are sometimes opportunities for hacks).
Should come before the line that says:
/* That’s all, stop editing! Happy blogging. */
Note: these debug log files can grow large after a while, so you might have to periodically delete the file and then let it regenerate as new error and warning messages are generated. Then go try to perform whatever action wasn’t working for you.
On systems that include the Cpanel utility (or something similar), I typically use that to view and delete log files.