Not what I meant. I was hoping to find some guidance on how to find specific static blocks such as the one referenced by you to alter the spatial behavior of the footer (#etheme-static-block-7) to get a bit more control over the layout of the template.
Since there is no documentation, the question becomes mute.
Never mind.

Hi Rose,

we’ve rebuilt the multiple headers per your suggestion, and the problem seems to have gone for now. We’ll keep monitoring closely as we develop the other languages.
Thank you

Hello Rose,

We have only one production site in use, hence the one license.

Besides this, to troubleshoot current issues, we have two development sites running, clearly indicated by the .dev in the slugs.

There seems to be a lot of incompatibility in xtore’s code, working with TranslatePress. We rely on our developer as well as Xstore to troubleshoot and resolve these issues. In order to compare code we need both development sites.

If we need to decommission 1 of the development sites, we will do so, but then we would have to rely even more on your supper team to help us resolve the open tickets.
Indicating that we are expanding into the global market and the dire need for the translation /xstore incompatibility to be resolved ASAP, the reply that we get a license warning, really isn’t the response we were hoping for.
We hope you can appreciate our current position and help us out.

Thank you

migrations where done by wp migrate db pro (plugin by delicious brains – https://deliciousbrains.com/wp-migrate-db-pro/)

Spend another couple of hours today just testing different theme settings to figuring out what could be the cause and I found the following things.

when importing the settings from the live production site in to the settings of the xstore parent theme, the error also shows itself in the Xstore parent theme.

On removal of all elements from the header builder the issue seems resolved (manually removing each individual element, not using the header reset option).
when rebuilding the header it keeps working with the main menu and logo element present, when also adding the secondary menu (as third item) the issue seems to reoccur but less often.

When leaving the secondary menu element out of the header all the other header elements (desktop view, removed additional headers) can be used without issues.
with the exception of the secondary menu, checked all single products in the /en/leren-lingerie/ categorie, all without issue.

the moment I put the secondary menu element back in the header, the issue presents itself again.
(main menu, logo and secondary menu elements are placed in the bottom header)

When trying to work around the secondary menu usage and adding a couple of items to the main (mega) menu, while the secondary menu was still in the header the issue also seems to disappear suggesting it could also be caused by something inside the (mega)menu that is conflicting with translatepress.

those screenshots are not from the supplied examples.
Also as previously mentioned. when testing the three provided examples at least 1 isn’t working correctly.
When just looking at 1 single page it occasionally can display correctly.

currently 2 of the 3 provided example url’s are partly in Dutch.

Hi Rose,

I’ll let our lead developer take care of the login request.
As for the problem, please review the video capture in Private area

We use TranslatePress as translate plugin, after tested Weglot (external, expensive after 2nd language), WPML, ridiculously slow, MultilingualPress (SEO issues, among other issues), Polylang, Loco (still using, combined with TP). TranslatePress support basically told us, the problem isn’t on their end; there’s probably an issue with either other plugins or the chosen template (xstore). Funny enough, the problem didn’t exist a month or so ago (many, many updates ago, as we’ve skipped a few xstore updates)

Staging copy with all of the plugins deactivated, except for Woocommerce, TranslatePress and Xstore, displayed same issues. Again, our lead developer can share more insights. He will contact you tomorrow.
Not sure if staging was tested with storefront…

Obviously, I know how to work those arrows 😉
Clearing the browser cache (complete history & contents btw) didn’t work.
Very frustrating…

I’ll keep digging. Thanks anyway.

Cheers,
Bas

Hi Rose,

our development team had a look and created a fix.
For future reference, we use WP Business Reviews (https://wpbusinessreviews.com/). It seemed to be an error from Xstore’s static block cache. Deactivating this feature solves it.

–This seems to be a bug in the static blocks / theme conflict with the ‘nested’ shortcodes
When the code of customer reviews is added ([wpbr_collection id=”8141″]) directly to the page, the review slider appears twice.
Could also be in the testimonial plugin that doesn’t support this.
As a fix, we have now put the code of the static block directly in the shopping cart.

The firewall was still configured to allow only a specific IP address. It’s open to connect now

As for the comparison: our production site displays the reviews on the cart page just fine (version 4.1.5)

I will ask our developer to provide FTP access within 30 mins.
But please note, that our development team will work on the staging site tomorrow and they will probably lock out any externals to prevent code breaking.

Hi Rose,

that was one of the first things I’ve tried. The ‘break’ seems to be unrelated to the advanced layout as the reviews still didn’t show. Something else from the update is causing the issue…

Ok, thanks

We seem unable to update the user profile (database timeout). Let us investigate and get back to you

The code voor the noindex filter is old (2017) and doesn’t really work. The noindex is only added when the top filter (popularity/newest/price) is set, but not when the left side taxonomy filter is used.

Looking at trying canonical URLs, Woocommerce nor Yoast offer any solution to declare those sufficiently. Google, however, indexes all generated URLs with filters all the same.

On different forums it is suggested that the theme developer may be able to suggest some code to replace or implement canonical URLs such as the parent category page. When that happens, those filter URLs should drop off in Google in favour of of the main category page, thus preventing indexing duplicate content…

Is that something worth trying?

I’ve noticed that the code has already been added to the custom js (url in private). By you?
However, socials still don’t open in new window