I wanted to send you my Debug info as I usually do but when I go to toolset debug, it is empty!?
I have read another ticket about it but that ticket was related to the author's name in a child theme's CSS file. This site has the standard Avada theme active.
Hi, as we discussed in chat yesterday the debug info may be empty if there is a conflict with a theme or plugin. You mentioned that you're using the standard Avada theme, but I'd like to go a bit further and confirm the problem isn't a conflict with custom code or another plugin. Can you try testing with only Toolset Types and Avada active? If you'd like to activate a Maintenance Mode plugin during testing, that's fine. Once all other plugins are deactivated, go to Toolset > Settings > Custom Code and deactivate any custom code snippets temporarily. Now test the debug info page once more and see if it's empty.
- If it is not empty, please activate custom code snippets and other plugins one by one, refreshing the debug page each time until the problem returns. Let me know which snippet or plugin caused the debug info to disappear.
- If it is empty, I would like to see if any server-side errors are logged that would indicate a problem in this page. Go in your wp-config.php file and look for
define('WP_DEBUG', false);
Change it to:
define('WP_DEBUG', true);
Then add these lines, just after the WP_DEBUG line:
Refresh the debug info page a couple of times, then check for an error_log.txt file on your server at the root directory (usually the same directory as wp-config.php). Download that file if it exists, copy its contents and paste them in your next reply. Once that is done, you can revert the changes you made to wp-config.php and delete the log file using FTP.
Okay that's odd, I'm not able to replicate the same problem in my own local test site so there must be something specific to your site's setup that is different in mine. May I log in and create a clone of your site using the Duplicator plugin? Then I can try some additional troubleshooting steps without breaking your live site any futher. If that's okay, please provide login credentials in the private reply fields here and I'll get started.
Okay I downloaded a clone of the site that was created earlier today, but the problem doesn't appear in my local copy with WPML active. I do see some Fatal Errors in the debug log recently:
[23-Sep-2020 11:49:01 UTC] PHP Fatal error: Uncaught TypeError: Argument 2 passed to de_DE\de_DE::sanitizeTitle() must be of the type string, null given, called in /path/to/dev/wp-includes/class-wp-hook.php on line 289 and defined in /path/to/dev/wp-content/plugins/de_de/de_DE.php:310
Stack trace:
#0 /path/to/dev/wp-includes/class-wp-hook.php(289): de_DE\de_DE->sanitizeTitle()
#1 /path/to/dev/wp-includes/plugin.php(206): WP_Hook->apply_filters()
#2 /path/to/dev/wp-includes/formatting.php(2186): apply_filters()
#3 /path/to/dev/wp-content/plugins/cred-frontend-editor/vendor/toolset/toolset-common/inc/m2m/element_type.php(63): sanitize_title()
#4 /path/to/dev/wp-content/plugins/cred-frontend-editor/vendor/toolset/toolset-common/inc/m2m/element_type.php(136): Toolset_Relationship_Element_Type->__construct()
#5 /path/to/dev/wp-content/plugins/cred-frontend-editor/vendor/toolset/toolset-common/inc/m2m/relationship/definition in /path/to/dev/wp-content/plugins/de_de/de_DE.php on line 310
[23-Sep-2020 11:55:46 UTC] info for post posts :
[23-Sep-2020 11:55:46 UTC] PHP Notice: Trying to get property 'source_language_code' of non-object in /path/to/dev/wp-content/toolset-customizations/function-ts-is-post-wpml-original.php on line 16
Let me continue to run tests locally and on dev and I will have an update for you later today. Thanks for your patience while I investigate.
It seems to be a bit more complicated than just WPML. It seems to be a combination of WPML and WordFence, because I have deactivated WordFence and activated all other plugins and the debug information appeared as expected.
Similarly, if I deactivate WPML and reactivate WordFence, the information again appears as expected. So it seems to be a 3-way combination of Toolset, WPML and WordFence responsible for the problem. Let me run some tests locally to see if that is replicable in my local environment and I'll update you shortly.
For now, I have reactivated all plugins again on dev.
I'm not sure how much I'll be able to do to debug this, since Wordfence is tricky to run locally. There are many different configurations to consider, and I don't have a premium license available for testing. Let me ask my 2nd tier team for some advice here. In the meantime, the most practical workaround is to temporarily disable Wordfence or WPML when providing debug information from Toolset.
Thanks for the helpful tips. The plugin de_DE you mentioned in the debug.log is designed to convert (sanitise) all ä, ö and ü in German to ae, oe and ue in URLs (same for caps letters). The previous ticket your quoted me at the beginning was also having problems with umlauts (¨).
Our site in EN and DE, so we can't avoid the umlauts unfortunately.
It still amazes me that we still have to workaround umlaut problems in all software these days, but I guess we have to live with it :-)))
I created an online test site with WordFence, Types and WPML installed and active, setup to include German in the site languages, and I wasn't able to reproduce the problem.
I had no difficulty accessing the debug info page for Toolset or for WPML with all of the plugins active.
I haven't done anything special with WordFence such as setting up details of a firewall, it is just using the default settings after installing the plugin.
I expect the problem lies in the details of the settings for that plugin, and to identify what settings that would mean going through them all on your site and reverting each setting to default and then re-applying them one-by-one to try and identify which causes the issue. Given that the only symptom of the problem is with a rarely visited page that can be reached by temporarily disabling WordFence, I'm not sure you would want to do that...
