Since I’ve setup this plugin, I have weird bugs happening when it comes to setting order meta data and then reading them a few milliseconds later in another function/method. Function A creates an order and sets some meta data, then executes function B. Function B have null value while using get_post_meta() even though database stored the meta values.

So I think it’s safe to say that there is an issue involving caching here.

I’d like to know if there is a way to avoid any caching related to woocommerce orders and their metas. I’m only using DB and object cache through Redis.

Best regards,

After switching to HPOS and turning off compatibility mode, i wanted to clean up the database as per the native function in Status->Tools. This does not seem to function.

I read here https://www.ads-software.com/support/topic/is-postmeta-table-used-even-after-making-table-based-pods/ that even when tables are used, wp-pods stores the data in postmeta.
I’m using a lot of wp-api calls. When a wp-api call is made to fetch relationship field data (like related post IDs) for a table-based pod, does the backend query the podsrel table or does it query postmeta?

In 2020, according to your blog, you released Yoast SEO 14.0 and said, “We’re moving all of our meta data from?wp_postmeta?to custom tables. This allows for far more efficient querying.”

If that’s truly the case, then why are there still thousands of Yoast SEO entries in our post meta table? Why didn’t you delete those old entries in the post meta table after the 14.0 update?

I have seen this question asked on a couple forums, but have not seen any clear answer given: Now that Yoast is up to version 24.1, ten major updates past the 14.0 custom tables update, is it safe to delete all those _yoast_wpseo_ entries from the post meta table?

After researching existing posts, I already tried to deactivate and reactivate the plugin. Nothing changed. I also tried activating the setting Search all custom fields but that yields too many unrelated results. Our custom posts are generated by an import script. We don’t use external Google functionality.

The error occurs consistently on two instances, but it does not occur in a third instance that I have set up on localhost.

These are our ASL settings (without nonces and visual frontend preferences):

wp option get asl_options
array (
  'theme' => 'underline',
  'override_search_form' => '1',
  'override_woo_search_form' => 0,
  'keyword_logic' => 'and',
  'mob_auto_focus_menu_selector' => '#menu-toggle',
  'trigger_on_facet_change' => '1',
  'click_action' => 'results_page',
  'return_action' => 'results_page',
  'click_action_location' => 'same',
  'return_action_location' => 'same',
  'custom_redirect_url' => '?s={phrase}',
  'results_per_page' => '9',
  'triggerontype' => '1',
  'trigger_update_href' => '0',
  'customtypes' => '_decode_WyJjb3Vyc2UiLCJwYWdlIiwicG9zdCJd',
  'searchintitle' => '1',
  'searchincontent' => '1',
  'searchinexcerpt' => '1',
  'search_in_permalinks' => '0',
  'post_password_protected' => '1',
  'search_in_ids' => '0',
  'search_all_cf' => '0',
  'customfields' => 'title|subtitle|description|content|keywords',
  'post_status' => 'publish',
  'override_default_results' => '1',
  'override_method' => 'get',
  'res_live_search' => '0',
  'res_live_selector' => '#main',
  'res_live_trigger_type' => '1',
  'res_live_trigger_facet' => '1',
  'res_live_trigger_click' => '0',
  'res_live_trigger_return' => '0',
  'exactonly' => '0',
  'exact_match_location' => 'anywhere',
  'searchinterms' => '0',
  'charcount' => '0',
  'maxresults' => '10',
  'itemscount' => '4',
...
  'autocomplete' => '0',
  'kw_suggestions' => '0',
  'kw_length' => '60',
  'kw_count' => '10',
  'kw_google_lang' => 'de',
  'shortcode_op' => 'remove',
  'striptagsexclude' => '',
  'runshortcode' => 1,
  'stripshortcode' => 0,
  'pageswithcategories' => 0,
  'primary_titlefield' => '0',
  'primary_titlefield_cf' => '',
  'primary_descriptionfield' => '0',
  'primary_descriptionfield_cf' => '',
  'secondary_titlefield' => -1,
  'secondary_titlefield_cf' => '',
  'secondary_descriptionfield' => -1,
  'secondary_descriptionfield_cf' => '',
  'advtitlefield' => '{titlefield}',
  'advdescriptionfield' => '{descriptionfield}',
  'woo_exclude_outofstock' => '0',
  'exclude_woo_hidden' => '1',
  'exclude_woo_catalog' => '0',
  'excludecategories' => '',
  'excludeposts' => '',
  'wpml_compatibility' => '1',
  'polylang_compatibility' => '1',
  'kw_exceptions' => 'JavaScript, Java, PHP ',
  'kw_exceptions_e' => '',
...
  'classname-excludecategories' => 'wpdreamsCategories',
  'sett_tabid' => '1',
  'selected-customfields' => 
  array (
    0 => 'title',
    1 => 'subtitle',
    2 => 'description',
    3 => 'content',
    4 => 'keywords',
  ),
  'selected-showcustomtypes' => 
  array (
    0 => 
    array (
      0 => 'post',
      1 => 'Search in posts',
    ),
    1 => 
    array (
      0 => 'page',
      1 => 'Search in pages',
    ),
  ),
  'selected-exsearchincategories' => 
  array (
  ),
  'selected-excludecategories' => 
  array (
  ),
  'asl_cf_search_nonce' => 'REMOVED_SECRET_DATA',
  'asl_sett_nonce' => 'REMOVED_SECRET_DATA',
  'wdcfs_15' => '',
  'selected-customtypes' => 
  array (
    0 => 'course',
    1 => 'page',
    2 => 'post',
  ),
)

How to make sure ASL searches in the custom postmeta fields and lists all relevant posts?
Or is there a filter hook to override / replace ASL search logic with our own WP query?

We have a multilingual WordPress website using WPML with over 52,000 posts across 8+ languages. We are encountering performance issues and site slowness, which seem to be related to the size of several database tables.

Here is an overview of the large database tables:

• wp_icl_translate: 1859.59 MB
• wp_icl_translation_status: 1196.06 MB
• wp_postmeta: 1095.48 MB
• wp_posts: 570.16 MB
• wp_icl_string_translations: 260.89 MB

To address these issues, we have optimized the database using the WP Rocket plugin, clearing out unnecessary data like post revisions, transients, and auto drafts. Additionally, we have set WP_POST_REVISIONS to 3.

I came across the suggestion to split large tables into multiple tables as a potential optimization. Could anyone share their experience with this approach?

Moreover, I would appreciate any recommendations on further improving site performance, especially with regard to the database, queries, and overall request handling.

Thank you in advance for your assistance.

Best regards,
Vimal Roy

Is it necessary? How can I clean this table?

I couldn’t find a good solution for my problem, so I decided to make a topic.

My DB is enormous (783MB!) and the bigest tables are wp_postmeta (637MB) and wp_post (123MB). I have tried to clean it up by various plugins but there is no effect.

I found queries to check what I could delete:

1. Select from wp_postmeta by meta_key with counting

SELECT meta_key, COUNT( meta_key ) FROM wp_postmeta GROUP BY meta_key

Result:

meta_key
_additional_settings 4
_auxin_meta_client 8
_auxin_meta_release_date 8
_display_related 8
_dp_original 27
_edit_last 52
_edit_lock 193
_elementor_controls_usage 387
_elementor_css 25
_elementor_data 1767
_elementor_edit_mode 1788
_elementor_page_assets 715
_elementor_page_settings 1656
_elementor_source_image_hash 16
_elementor_template_type 1804
_elementor_version 1791
_form 4
_format_audio_embed 35
_format_audio_player_skin 35
_format_quote_source_name 35
_format_quote_source_url 35
_format_video_embed 35
_format_video_player_skin 35
_hash 4
_locale 4

2. Order meta_key by size:

SELECT meta_key, (SUM(LENGTH(meta_id)+LENGTH(post_id)+LENGTH(meta_key)+LENGTH(meta_value)))/1048576 AS Size, COUNT(*) AS Count FROM wp_postmeta GROUP BY meta_key ORDER BY Size DESC; 

Result:

 meta_key		   size		count
_elementor_data		   568.7895 	1767
_elementor_controls_usage  3.3453 	387
_wp_attachment_metadata    0.5746 	660
_elementor_page_settings   0.1319 	1656
_elementor_page_assets 	   0.0943 	715
_wp_page_template 	   0.0840	1786
_elementor_template_type   0.0701 	1804
_elementor_edit_mode 	   0.0628 	1788
_elementor_version 	   0.0566 	1791
_wp_attached_file 	   0.0455 	830

3. Select entries without ID from wp_posts and wp_postmeta:

SELECT *
FROM wp_postmeta pm
LEFT JOIN wp_posts wp ON wp.ID = pm.post_id
WHERE wp.ID IS NULL

And here the result is just few rows of meta key called “auxin-autop” and deleting them obviously doesn’t solve the problem. Probably this query is not valid for this problem?

To sum up.

I understand that I should delete Elementor data but how would I know which I can remove without breaking my site?

Thank you in advance for helping me with my issue!