Log into your WooCommerce.com account and place your ticket there.
Additionally please copy and paste the debug information from the support page of the plugin into your support ticket.
- Caching: If you run some caching layer, the server might still serve cached versions of the pages. You will need to delete the cache.
Short answer: No
First some information on what
wpm_get_cart_items is doing.
While a visitor is browsing a shop he might add some products to the cart. Each time he uses the minicart to modify his selection, by adding or removing products, we need to make sure to have all product information handy in order to send pixel events with all relevant data to Google, Meta (Facebook), etc. Unfortunately it is not possible to include this information on page load within the HTML code, because caching mechanisms could serve outdated data to the browser. That’s why we need a mechanism like
wpm_get_cart_itemsthat will fetch all the current product data for the minicart from the server.
And now to the question if
wpm_get_cart_items is slowing down the website.
Some users have noticed in the network tab of their browsers that the
wpm_get_cart_items call adds one more request, which on slow servers can take even more than a second to fullfil. It is using the standard WordPress Ajax function to fetch the product data.
But is this not slowing down the website?
wpm_get_cart_items call happens after the browser has signalled the
load event, which happens after all content has already been successfully loaded.
The load event is fired when the whole page has loaded, including all dependent resources such as stylesheets and images.
Reference: Mozilla MDN Web Docs
PageSpeed measures the loading time of your page starting from the initial request to when the last embedded resource (JS, CSS, images, etc.) has finished loading. So that’s essentially when $(window).load() is triggered.
Reference: Lèse Majesté’s answer on Stackoverflow
wpm_get_cart_items doesn’t slow down the download or rendering of a WooCommerce shop in any way.
The plugin uses a script output to track products in a way that works with every caching system.
It outputs that code wrapped in a
<script></script> tag that is fully compliant HTML code.
Because the code is wrapped in
<script></script> tags the theme should ignore the code and not output it visibly to the front-end.
There is nothing we can do from our side. You have to ask the theme developer to update the theme to ignore all code that’s wrapped in
In its current version, the Elementor Related Product and Upsell Product Widgets don’t properly process the
<script> output created by the WooCommerce Pixel Manager. It should be hidden and not visible. This is an issue that only can be fixed by the creators of the Elementor Related Products and Upsell Product Widgets as described in the following troubleshooting article.
Luckily, there is a workaround for users of the Elementor Related Products Widget. Instead of using the built-in Elementor Related Products Widget, you can use the following shortcode,
Similarly, for replacing the Elementor Upsell Products Widget, you can use this code published by bekarice: https://gist.github.com/bekarice/a3305c18d32b4de9d8b7
We already have placed a bug report on Elementor’s GitHub issue tracker: https://github.com/elementor/elementor/issues/16934
The bug report shows another way for the users to fix the problem, enabling them to keep using the Elementor widgets. But it can’t persist over Elemetor updates, so you need to keep updating this with every Elementor update. Use it at your own risk.
We’d recommend that you give the issue a thumbs up or add your own comment so that the Elementor developers see how frequently that problem happens and increase the priority of that issue.
We’re in direct contact with Elementor, but at the moment we can’t say for sure if and when they are going to fix this on their end.
If a blank page shows up when trying to load the purchase confirmation page the reason is typically too low allocated memory. The Pixel Manager runs a few queries on the purchase confirmation page which use more memory than on other pages. If in the shop configuration the memory limit is too low, this problem can occur. The solution is simple. Increase the memory limit in your configuration.
Make sure that the memory limit is well above your maximum memory allocation.
Add one of the following lines to the configuration file
Here’s a support article on WooCommerce that also shows other ways how to increase the memory limit.
The Pixel Manager runs a few queries on the purchase confirmation page to evaluate if the customer is a new customer or an existing customer. It also determines different types of customer lifetime values for that customer. Those queries, on some shops, can take a long time to execute.
The simplest way to fix this is to add high-performance indexes to the tables. One of our tests improved the query speed by a factor of 133!
Use the Index WP MySQL For Speed plugin to add those high-performance indexes to your shop too. It will not just help on the purchase confirmation page but on every page of your shop.
Read more about this optimization in our blog article about adding high-performance indexes.
The plugin configuration for HotJar is really simple. You just have to paste the Site ID from HotJar’s tracking code to Pixel Manager and you’re good to go.
However, sometimes, there will be instances where your site can’t be verified. Usually, it’s because of these things:
- Cookie Banner – make sure that you have disabled the cookie banner when verifying your site on HotJar. This sometimes blocks the cookies coming from HotJar as well causing it not to verify successfully
- Explicit Consent Mode – having this option enabled in the plugin will also not allow cookie tracking on your site. Just like the Cookie Banner, this will also cause your site’s verification to be unsuccessful
- You’re logged in while verifying – You also have to do the verification while you’re logged out on your WordPress Dashboard so your site will be tracked.
- Server-side caching – Make sure to clear all server-side caches after each configuration so the HotJar verifier will not load a cached version.
The theme, a plugin, or a custom code that loads an additional jQuery library overwrites the events the Pixel Manager hooks into.
WordPress for a long time was shipped with an old version of jQuery. Therefore, some theme developers or shop managers loaded an additional, newer jQuery library in the HTML source. But, if done incorrectly, this would overwrite all events a plugin like the Pixel Manager has hooked into, rendering all event listeners useless.
Luckily WordPress, since version 5.5, is shipped with the most modern jQuery library. This means the additional jQuery library can be safely removed.
- Open the development console
- Search the entire source code using OPT+CMD+F (on a Mac) for the following string: “jQuery requires a window with a document”
- If you get two results then the jQuery library is duplicated and is causing issues.
Remove the additional jQuery library. Keep the jQuery library that WordPress is injecting.
The way our plugin generates and sends the match key parameters prevents a mismatch to happen. Either they are sent correctly and matched by our plugin, or they are not sent at all.
The usual explanation for this warning is one or several of the following:
- You recently enabled Meta (Facebook) CAPI. In that case, Meta (Facebook) sometimes, unfortunately, mixes up old with new values and generates this warning. Fortunately, this transitory situation is only temporary and resolves just by waiting a few days. In this case the recommendation is to simply dismiss the warning. If the warning shows up again, have a look at the other possible reasons. If the issue you are encountering is not listed, feel free to contact support.
- You are running a second instance of the Meta (Facebook) pixel through another plugin or custom code. If that is the case then that code is missing the correct match keys and causes the warning. Please disable additional Meta (Facebook) plugins and/or remove additional custom Meta (Facebook) code. Then dismiss the warning in Meta (Facebook). If the warning reappears, go ahead and contact support.
Under normal conditions, the plugin sends the purchase event immediately to Meta (Facebook). But, when a payment for the order fails, no purchase event is being sent through the Conversion API. Only when the payment on that order is recovered at a later point in time, then the purchase event is sent to Meta (Facebook). This can lead to a
Purchase Event delay from server warning. It can be safely ignored.
This happens when Meta (Facebook) detects URL parameters that potentially contain personal data (PII) in the path of the URL.
In this case Meta (Facebook) detects that
username probably contains personal information, issues a warning and redacts the information like this:
Our plugin does not add any information to the URL path. The only information that our plugin is sending through the browser pixel is product and order data. The source of this warning are URL paths generated by the server and must be fixed there.
Meta (Facebook) in some cases is “trigger happy” and issues a warning although there is no personal data in the URL path.
In this case
_ip=123456 resembles an IP address, but in your case, it might be something completely different. If you are sure it is not personal information, you can safely ignore the warning.
This is usually caused by an ad-blocker in the browser.
In order to fix this, temporarily disable the ad-blocker or switch to another browser that doesn’t have an ad-blocker enabled.
Read more about this here.
Plugin homepage: link
The plugin creates a custom order thankyou page for WooCommerce, but doesn’t follow the WooCommerce standard for the order confirmation page. In order for conversion pixels to fire on the WooCommerce order confirmation page, every WooCommerce theme must implement the correct output for the
is_order_received_page() conditional. This is valid for plugins that modify the purchase confirmation page too. On top of that, the WC Custom Thank You plugin has not been updated in a long time and the developer has stopped to answer support requests.
It can happen that Google Ads throws the warning “Misconfigured bidding strategy“. The hover text shows “Your campaign is running with limited performance. Set up conversion tracking for your account to improve your performance, spending and see reporting“.
Unfortunately, this warning sometimes is thrown even if conversion tracking is set up just fine.
Typically, the warning is thrown on Smart Shopping campaigns. Additionally, conversion tracking for Smart Shopping campaigns have more requirements in order to run well. If those are not met, the same warning is thrown.
- First, make sure that conversion tracking has been set up correctly. Double check the conversion ID and conversion label.
- Make sure that the product ID type is the same as the one you use in Google Merchant Center. The product IDs must match.
- Smart Shopping campaigns require at least 30 conversions within a time frame of the past 30 days. And, in order for them to be able to use the remarketing lists, there must be at least 100 visitors per list in the past 30 days. Once the requirements are matched, the warning will go away.
- If you don’t think you can match the requirements in the near future, it is better to run a standard shopping campaign.
Sometimes Google Ads shows a warning saying the ID was never received. Unfortunately, that warning is shown even in cases where everything works perfectly fine.
You can check yourself if IDs are being received in the audience report. Switch the graph to Parameters > ID hits. If you see a graph like the following, everything is ok and you can dismiss the warning and don’t need to continue reading further.
If you see incoming ID hits in the graph and still want to investigate the warning further, please ask Google support.
On the other hand, if you don’t see ID hits in the graph, please continue reading.
It doesn’t mean that Google Ads is always wrong when it comes to that warning. There are cases where the Google Ads warning can be right. Here is a list of possible causes:
- You’ve set the wrong conversion ID. Double-check and correct it if necessary.
- When setting up the remarketing audiences you’ve enabled
customaudience. The plugin can only send the signal for one or the other, not for both (which would not make sense anyway). So one of those verticals never receives an ID (usually
custom), in which case you will see that warning show up regularly, but usually can dismiss it. Unfortunately the
customvertical can not be turned off once enabled.
Make sure that none of the above reasons are causing this problem.
The best way to check if the ID is being sent is to use the Google Tag Assistant
Here’s how to check:
1. Open the Google Tag Assistant: tagassistant.google.com.
2. In Google Tag Assistant, instruct to open one of your product pages.
3. If the product page is a variable product, select the drop-down(s) to choose one variation.
4. Then switch back to the Google Tag Assistant tab.
5. In the middle pane, click on dataLayer.
6. In the left sidebar, click on the view_item event. If you’ve also set up Google Analytics, you will see several view_item events. Click through each of those until you see in the dataLayer the event that is sending events to your Google Ads conversion ID.
7. Once you find the correct event, check if the ID is being sent. If so, all is good. You have proof that the ID is being sent and the warning is wrong. You can dismiss it.
8. If you would like, you can also take those results and ask Google Ads support to fix that warning. (It would be a great help for us, because we investigate way too many of those false positive warnings).