isarisar

Hi again @seinomedia,

you are both right. I got confused over the exclusions selectable on our provider’s backend: They’re for CDN only, not the provider’s own cache. So I contacted them and they (had to) manually added the custom URL to the latter’s list.

Solved, thanks!

Hi @seinomedia,

I did, attempts were with fresh incognito instances.

I’ve also tried disabling WP-Rocket entirely, no change.

Both /wp-admin & the new URL are excluded from my provider’s server cache, no change.

The provider does supply CDN (Cloudflare), but it’s supposed (I have no influence) to only be set to cache static files.

*edit:* Correction: Actually I can influence the CDN exclusions, it’s the provider cache I can’t seem to influence. Will try & contact them now, oops.

• This reply was modified 2 years, 7 months ago by isarisar.

Note that a 2021 comment in the source you link for search_join mentions exactly this error – along with a fix:

Had to change these two lines to get it working on WP 5.8.1 as I had an error ( Not unique table/alias: ‘wp_postmeta’ [continues with fixes]

… and it’s back, this time as

WordPress database error: Not unique table/alias: 'wp_postmeta' for query
                        SELECT 	 DISTINCT wp_posts.ID
                        FROM wp_posts  LEFT JOIN wp_postmeta ON ( wp_posts.ID = wp_postmeta.post_id AND wp_postmeta.meta_key = '_et_library_theme_builder' ) LEFT OUTER JOIN wp_postmeta ON wp_posts.ID = wp_postmeta.post_id AND wp_postmeta.meta_key = "yikes_woo_products_tabs"
                        WHERE 1=1  AND (
  wp_postmeta.post_id IS NULL
) AND wp_posts.post_type = 'et_theme_builder' AND ((wp_posts.post_status = 'publish'))
                        GROUP BY wp_posts.ID
                        ORDER BY wp_posts.post_date DESC
                        LIMIT 0, 1
                 von require('wp-blog-header.php'), wp, WP->main, do_action_ref_array('wp'), WP_Hook->do_action, WP_Hook->apply_filters, et_pb_ab_init, et_builder_ab_get_current_tests, et_theme_builder_get_template_layouts, et_theme_builder_get_theme_builder_templates, et_theme_builder_get_theme_builder_template_ids, et_theme_builder_get_theme_builder_post_id, WP_Query->__construct, WP_Query->query, WP_Query->get_posts

Hi @dotch, thanks for the advice – I’ve tried that with our WP Rocket and provider cache, unfortunately it does not work for us.

Some also suggest setting define('COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] ); in wp-config.php, unfortunately that didn’t work for us either.

Ah, I see now that the plugin doesn’t support Grouped Products anyway.

So to at least get rid of the errors, I just changed the…

if ($nr_get > 0)

… in woosea_product_fix_structured_data to:

if ($nr_get > 0 && $product->get_type() !== "grouped")

Note that the minimum price reported by…

$product_price = wc_get_price_including_tax($product)

… at the end of woosea_product_delete_meta_price doesn’t match for Grouped Products. Woocommerce’s own solution is in the first dozen+ lines of get_price_html, but it seems fixing this just adds pointless overhead.

Hi @sixaxis,

what do you think about the part with parse_url(…, PHP_URL_PATH)?

It is by definition not meant do generate full paths.

See its PHP documentation, example 1 — PHP_URL_PATH is 3rd from bottom.

So my hoster couldn’t possibly do anything about this.

I understand. Though I don’t think more input is needed from us to require further discussion as we’ve probably found the cause. From the past two occurrences:

The issue reproducibly happens when a

• grouped product page
• is called with any parameter, so far ?epik=… (pinterest?) or ?pp=… (Youtube?)

Our grouped products consist/reference only variable products. We added a try&catch block with some logging — prior to it, the function failed after trying to process the first VP reference, now it tries & fails with each VP the GP references.

[The reason this hasn’t been a pressing issue for us yet is our GPs are not exported into feeds, and so no recipient tries to check their bugged SD.]

Hi @devnihil,

thank your for your reply. I actually already did just what you suggested (except for the three resets, I just ran that for “indexables tables & migrations”.

Since then the issue has indeed gone away.

Seems you already had a check like that in mind? Considering line 1611…

$prod_type = $product->get_type();

… but that variable is never used.

Thanks, this is now fixed. Sorry for the delayed reply.

IOW, just prepend the string with get_home_path().

Dunno how well that works with installs that hide/redirect wp-content, though.

This one still occurs. I believe it’s an extremely trivial fix?

--- a/includes/pr-dhl-api/abstract-pr-dhl-api-rest.php
+++ b/includes/pr-dhl-api/abstract-pr-dhl-api-rest.php
@@ -259,7 +259,7 @@
 			case '201':
 				break;
 			case '400':
-				$error_message = str_replace('/', ' / ', $response_body->message);
+				$error_message = isset($response_body->message) ? str_replace('/', ' / ', $response_body->message) : "";
 				throw new Exception( __('400 - ', 'dhl-for-woocommerce') . $error_message );
 				break;
 			case '401':

The fatal error with round() occurred twice yesterday.

Hi Shadi, sorry, I don’t know how either came about.

Though the first report’s stack trace does reveal that somehow PR_DHL_WC_Order->save_meta_box_ajax got invoked with the empty string.