Where can I report a bug or suggest improvements?
Please post your problem in the WordPress support forum for this plugin: Support forum
Alternatively you can sent a request to [email protected]. If you do, please copy and paste the debug info from our plugin and attach it to the email.
image (Click to expand)
The most common issues in case the pixels don't work
- Caching: If you run some caching layer, the server might still serve cached versions of the pages. You will need to delete the cache.
Is wpm_get_cart_items slowing down my website?
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.
My theme shows a script code on the front-end that shouldn't be there
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> tags which 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
Elementor Related Products and Upsell Products Widgets
In its current version the Elementor Related Product and Upsell Product Widgets don't properly process the
<script> output created by the Pixel Manager for WooCommerce. 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 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 on 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 frequent 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.
The Purchase Confirmation Page Doesn't Load and Shows a Blank Page
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 on how to increase the memory limit.
The purchase confirmation page loads very slowly when the Pixel Manager is enabled
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. In one of our tests it improved the query speed by a factor of 133 !
Use the Index WP MySQL For Speed plugin to add those high-performance indexes on 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.
Server Sending Invalid Match Key Parameters
The way our plugin generates and sends the match key parameters prevents a mismatch to happen. Either they are sent correctly and matching 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 you think all of them don’t come in question feel free to contact our 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 our support.
Purchase Event delay from server (Conversion API)
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.
Potentially violating Personal data sent to Meta (Facebook)
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. When you are sure it is no personal information you can safely ignore the warning.
I am getting "Failed to load resource: net::ERR_BLOCKED_BY_CLIENT"
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
WC Custom Thank You
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.
Misconfigured Bidding Strategy
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 to conversion tracking 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.
Issue: ID never received
Sometimes Google Ads shows a warning saying the 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 > Paramters > 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.
image (Click to expand)
If you see incoming ID hits in the graph and still want to investigate the warning further, please ask the 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 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:
Open the Google Tag Assistant: tagassistant.google.com
In Google Tag Assistant instruct to open one of your product pages.
If the product page is a variable product, select the drop down(s) to choose one variation.
Then switch back to Google Tag Assistant tab.
In the middle pane click on dataLayer.
image (Click to expand)
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.
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.
image (Click to expand)
If you like you can also take those results and ask the 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.)