Is there a hook/filter that I can use to prevent Toolset Types from updating the translation?
Each morning or during long periods of activities, if I go to the WordPress admin and go to a custom post type to make changes or add a new item the website goes down.
https://wordpress.org/support/topic/how-to-disable-automatic-translation-update/
Hi, there's no public API but let me ask my developers if there is any other way we could handle this. Out of curiosity, what exactly is the error you are encountering when the site crashes? Perhaps we could fix the problem so the filter isn't needed. Do you have access to server logs? Can you see anything relevant at the time of the crash? If you're not familiar with server logs I can show you how to activate them temporarily. 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:
define('WP_DEBUG_LOG', dirname(__FILE__) . '/error_log.txt');
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
define('WP_DISABLE_FATAL_ERROR_HANDLER',true);
Then trigger the site crash you mentioned before. If any server-side errors are logged, this will create an error_log.txt file in your site's root directory. Please send me its contents. Once that is done, you can revert the changes you made to wp-config.php and delete the log file.
Ok, settings set. I'll check periodically to see if I can trigger the down website. What I noticed is
- website goes down, seems to be a database connection. ( permission denied error on wp-includes/wp-db.php line 1895 )
- server error thorws a 502
- after 5 mins, everything comes back up fine
Okay thanks, I'll stand by for your update. If there are no error logs created, we may need to enlist some help from your hosting company to see if they can provide any insight into how or why this would be happening. Obviously it's not normal that adding a record would bring down the server or DB connection. Your hosting provider may have access to other logs that include more systemic details.
Still has not been able to trigger a downed site. PHP error logs do have these:
[05-Feb-2020 15:24:21 UTC] WordPress database error [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]An expression of non-boolean type specified in a context where a condition is expected, near 'REGEXP'. Code - 4145 for query SELECT post_id FROM wp_nav_postmeta
WHERE meta_key="_wp_types_group_post_types"
AND (meta_value LIKE "%,special,%" OR meta_value="all" OR meta_value REGEXP "^[,]+$")
ORDER BY post_id ASC made by do_action('toplevel_page_toolset-dashboard'), WP_Hook->do_action, WP_Hook->apply_filters, Types_Page_Dashboard->render_page, Types_Page_Dashboard->build_page_context, Types_Page_Dashboard->get_dashboard, Types_Page_Dashboard->get_dashboard_types_table, Types_Helper_Twig->render, OTGS\Toolset\Twig\Environment->render, OTGS\Toolset\Twig\TemplateWrapper->render, OTGS\Toolset\Twig\Template->render, OTGS\Toolset\Twig\Template->display, OTGS\Toolset\Twig\Template->displayWithErrorHandling, OTGS\Toolset\__TwigTemplate_2c7532df4835a5bea29dc2930cfcc5e35ffe171f36a8a3223a90b5d97549f1c9->doDisplay, OTGS\Toolset\Twig\Template->getAttribute, Types_Post_Type->get_field_groups, Types_Post_Type->fetch_field_groups
[05-Feb-2020 15:24:22 UTC] WordPress database error [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]An expression of non-boolean type specified in a context where a condition is expected, near 'REGEXP'. Code - 4145 for query SELECT post_id FROM wp_nav_postmeta
WHERE meta_key="_wp_types_group_post_types"
There's a bunch of them for each of the custom post types created by types.
Okay I looked into these error messages:
An expression of non-boolean type specified in a context where a condition is expected, near 'REGEXP'.
The explanation here is that SQL Server does not support the REGEXP operator, which is used in the Toolset codebase:
https://stackoverflow.com/questions/51009978/regexp-error-an-expression-of-non-boolean-type-specified-in-a-context-where-a
I'm not sure this is the most accurate information though, and if these errors are appearing in the logs without you experiencing crashes, I'm not sure they are related. I think it's worth investigating, regardless. What I would like to do here is split this into a separate ticket so I can ask my 2nd tier support team to give us some feedback on those specific errors. I will do that momentarily, so you may see some notices about a new ticket being created.
I would like to continue investigating the crashes specifically in this current ticket, so let's keep the log running a bit longer. If the file is getting too large to be manageable before the next crash, feel free to delete the file from the server. A new file of the same name should be created automatically whenever the next log message is triggered.
