Troubleshooting

General

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 send a request to support@sweetcode.com. If you do, please copy and paste the debug info from the Pixel Manager and attach it to the email.

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.
• Minification, combination, and concatenation: Some minification and combination plugins mangle up the injected JavaScript code to an extent, that the tracking pixels stop working. You will need to turn minification, combination, and concatenation off and try again.

Is wpm_get_cart_items slowing down my website?

Short answer: No

Long answer:

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_items that 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 fulfill. It is using the standard WordPress Ajax function to fetch the product data.

But is this not slowing down the website?

The wpm_get_cart_items call happens after the browser has signaled the load event, which happens after all content has already been successfully loaded.

info

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

info

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

So the 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 Pixel Manager 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 <script></script> tags.

Elementor Related Products and Upsell Products Widgets

info

This has been fixed in version 3.9.0 of Elementor Pro. Please update to that version (or higher).

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 [related_products limit="X"]

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 Elementor 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.

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 wp-config.php

/wp-config.php

define('WP_MEMORY_LIMIT', '256M');

/wp-config.php

define('WP_MEMORY_LIMIT', '512M');

/wp-config.php

define('WP_MEMORY_LIMIT', '1024M');

Here's a support article on WooCommerce that also shows other ways 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. 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.

Why I can’t verify my site on Hotjar?

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 cache after each configuration so the Hotjar verifier will not load a cached version.

Duplicate jQuery library causes random issues

Problem

The theme, or a plugin, or custom code loads an additional jQuery library that 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.

Verification

1. Open the development console
2. Search the entire source code using OPT+CMD+F (on a Mac) for the following string: "jQuery requires a window with a document"
3. If you get two results then the jQuery library is duplicated and is causing issues.

Solution

Remove the additional jQuery library. Keep the jQuery library that WordPress is injecting.

Render issues that show Pixel Manager JavaScript code on the front-end

In rare cases you might run into rendering issues on the front end which visibly show JavaScript code that is injected by the Pixel Manager into the page source.

This typically starts with the following line:

window.wpmDataLayer.products = window.wpmDataLayer.products || {};

There are two known cases where this problem appears.

1. Users of the Elementor Pro widget for related and upsell products. For them, we have an own support article with a workaround: Elementor Render Issue

2. The theme is using a front end JavaScript library which makes a mistake when rendering the code that the Pixel Manager injects into the product templates. The Pixel Manager injects the following three HTML elements into the page source: <meta>, <input type="hidden"> and <script></script>. All those HTML elements are invisible elements by definition and should not be visibly rendered. However, some JavaScript helper libraries don't account for those invisible elements and render some or all of them visibly nonetheless.

This needs to be fixed by the developers of those render libraries. The Pixel Manager cannot work around this issue.

Updates not visible

Sometimes it can happen that updates don't show up anymore, despite the subscription still being active.

Sync the license manually

Go to the Account tab of the plugin and click the Sync button. This will sync the license and might fix the issue already. If it doesn't continue with the next approach.

Full Reset

Sometimes manually syncing the license or deactivating and reactivating the plugin will not help. In that case a full reset should help.

1. Download the Freemius Fixer plugin from here: https://github.com/Freemius/freemius-fixer

2. Install the plugin on your website.

3. Run the Freemius Fixer.

4. Now you will have to add your license back to the Pixel Manager by going to the Account page of the Pixel Manager. If you don't have it on file you can always log into your account and get it from there: https://sweetcode.com/freemius-account/

The REST endpoints for the Pixel Manager are not working

In some edge cases it can happen that the wp-json REST endpoints for the Pixel Manager stop working and return a 404.

Typically, this happens when switching from pretty links to non-pretty links in the WordPress permalink settings and if the website uses caching.

Clearing all server-side cache (caching plugin, server cache, CDN cache, etc.) should fix that issue.

4 seconds delay or slow down of loading the website visually

Here's one possible explanation.

Condition: Lazy Loading the Pixel Manager and Google Optimize are active at the same time.

When Lazy Loading the Pixel Manager, which will also lazy load Google Optimize, the Google Optimize experiments would not load correctly, and the AB-tests would not yield valid results.

Therefore, only when both functions are active, the Pixel Manager automatically activates the Google Optimize anti-flicker script, which prevents the website from loading visually until either 1) Google Optimize is fully loaded or 2) the anti-flicker timeout is reached.

That timeout is set to 4 seconds by default.

Remember, the Lazy Load function loads the scripts immediately when the visitor interacts with the website. So that delay usually is much lower, especially when a visitor uses a mouse to navigate (as mouse movements trigger the loading immediately).

But when using performance measuring services, no interactions are triggered, which makes the Lazy Load always wait and the visual loading delayed until the anti-flicker timeout is reached.

You have the following options to deal with the situation:

1. Ignore the visual delay measured by performance-measuring services. The real-life delay is usually much lower.

2. Decrease the anti-flicker timeout by using the following PMW filter: https://sweetcode.com/docs/wpm/plugin-configuration/google-optimize/#adjusting-the-anti-flicker-snippet-timeout

3. Either disable Google Optimize or Lazy Loading the Pixel Manager.

Action Scheduler

The Pixel Manager ships with the Action Scheduler library. It helps to compile reports at night, because they can take a long time to process.

In rare cases the Action Scheduler tables are bloated, locked and can cause the entire website to go down. It seems to be an ongoing issue that's not limited to users of the Pixel Manager: https://clicknathan.com/web-design/woocommerce-actionscheduler-table-error/

There are various ways to deal with this. All of them have essentially the goal to clean up and fix the Action Scheduler tables.

Remove unnecessary records such as failed, cancelled and completed jobs

warning

Only do this if you know how to restore a database backup.

1. Take a backup of your database

2. Open your database and run the following SQL statements.

If your tables use a custom prefix other than wp_, adjust the prefix in the statement.

DELETE FROM `wp_actionscheduler_actions` WHERE `status` = 'canceled';
DELETE FROM `wp_actionscheduler_actions` WHERE `status` = 'failed';
DELETE FROM `wp_actionscheduler_actions` WHERE `status` = 'complete';

Locked database

warning

Only do this if you know how to restore a database backup.

It can happen that the Action Scheduler is messed up so much, that the database is constantly locked by Action Scheduler reads/writes. As a result you can't access the database and fix the issue. Here's how deal with this problem.

1. Take a backup of your database.

2. Open the wp-config.php file, take a note of the database password, delete the password in the file and save the file. The website will not be able to access the database anymore. The database should now be accessible again.

3. Get your fixes done.

4. Add the database password back to wp-config.php.

Drop current tables and replace them with fresh ones

warning

Only do this if you know how to restore a database backup.

1. Take a backup of your database.

2. Download the following file by right-clicking on it and selecting "Save link as": replace-as-tables.sql and save it under the name replace-as-tables.sql on your local computer.

3. Import the file into your database. If you use the default WordPress prefix wp_ in your database it will replace the existing tables.

4. Now you have fresh Action Scheduler tables. If you're using the default WordPress prefix wp_ you're done. The tables are fixed. If you use a custom prefix, please continue with the next step.

5. Drop the old tables manually.

6. Take the following SQL statement and replace custom_prefix_ with the prefix you're using in your database. Then run the SQL statement.

RENAME TABLE
    wp_actionscheduler_logs TO custom_prefix_actionscheduler_logs,
    wp_actionscheduler_groups TO custom_prefix_actionscheduler_groups,
    wp_actionscheduler_claims TO custom_prefix_actionscheduler_claims,
    wp_actionscheduler_actions TO custom_prefix_actionscheduler_actions

6. Now you have fresh Action Scheduler tables with the correct prefix and everything should be working again.

Further Action Scheduler Support

The Action Scheduler is maintained by the Automattic team. If you need further support, please contact them directly: https://woocommerce.com/contact-us/

Call to undefined function as_has_scheduled_action()

If you get the following error message:

Call to undefined function ... as_has_scheduled_action() in...

It means that you're using a third-party plugin with an outdated version of the Action Scheduler library.

The Pixel Manager ships with the latest version of the Action Scheduler library that contains the as_has_scheduled_action() function.

The Action Scheduler is packaged within many plugins. When loaded the Action Scheduler automatically loads the latest version of the Action Scheduler library. However, this only works reliably from version 3.2.1 onwards.

Here's the WooCommerce troubleshooting article on this issue: Deconflicting Different Versions of Action Scheduler

There is a safeguard in the Pixel Manager that prevents using the function as_has_scheduled_action() if it is not available. But, it may happen that in a later version of the Pixel Manager we forget to add that safeguard (as this already happened in the past). If you're reading this article, we probably have forgotten again and need a slap on the wrist. Please contact us and we will fix it immediately.

Meta (Facebook)

Server Sending Invalid Match Key Parameters

The way the Pixel Manager generates and sends the match key parameters prevents a mismatch to happen. Either they are sent correctly and matched by the Pixel Manager, 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 resolved 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 into 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.

• You've enabled Facebook to track events automatically without code. You need to disable that feature in the Facebook events manager.

Purchase Event delay from the 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 sent through the Conversion API. Only when the payment on that order is recovered at a later point in time, then the purchase event will be 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.

Example: http://example.com/account/reset-password?username=johndoe

In this case, Meta (Facebook) detects that username probably contains personal information, issues a warning, and redacts the information like this: http://example.com/account/reset-password?username=_removed_

Our plugin does not add any information to the URL path. The only information that the Pixel Manager is sending through the browser pixel is product and order data. The source of this warning is 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.

Example: http://example.com?_ip=123456

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

Duplicate events tracked in Meta (Facebook)

In rare cases, the Meta (Facebook) pixel duplicates events. This is a known issue on Meta (Facebook)'s side.

If you can rule out, that no duplicate tracking code is implemented on your website, and automatic event tracking is disabled in the Meta (Facebook) events manager, then the only thing that can explain this issue is a known bug on Meta (Facebook)'s side.

It has proven to be difficult to convince Meta (Facebook) support to fix this issue.

Luckily the Pixel Manager has a built-in workaround for this issue.

You can confirm if this is a tracking library issue by loading an older version of the Meta (Facebook) tracking library fbevents.js. We have a repository in which we track some of the versions of the Meta (Facebook) tracking library: https://github.com/alewolf/fbqevent.js

To test if this is a tracking library issue, please follow these steps:

1. Chose an old version with which you want to test. Version 2.9.84 has proven to work in our tests.
2. Add the following parameter to the URL of the page where you suspect duplicate events are tracked: fbevents-version=2.9.84

A full example with just this parameter looks like this: https://example.com/?fbevents-version=2.9.84

3. If the duplicate events stop, then it is a tracking library issue. If the duplicate events continue, then it is probably not a tracking library issue.

If you can confirm that it is a tracking library issue, then you can use the following filter to force the Pixel Manager to always load the older version of the tracking library:

/wp-content/themes/your-theme/functions.php

add_filter('pmw_facebook_fbevents_script_version', function () {
	return '2.9.84';
});

info

Make sure to delete all server-side cache after adding the filter.

Incompatible Plugins

WC Custom Thank You

Plugin homepage: link

info

The plugin creates a custom order thank-you 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.

Google Ads

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".

info

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 has more requirements in order to run well. If those are not met, the same warning is thrown.

1. First make sure that conversion tracking has been set up correctly. Double-check the conversion ID and conversion label.
2. Make sure that the product ID type is the same as the one you use in Google Merchant Center. The product IDs must match.
3. 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.
4. Make sure that the bidding strategy uses the the correct budget type. Depending on your settings you might have to use a different budget type. A single budget per campaign generally works fine. But if you're using shared budgets, you must make sure that all campaigns in the same shared budget use the same bidding strategy.
5. 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 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 retail and the custom audience. 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 custom vertical can not be turned off once enabled.
• There is some reason that is blocking the remarketing script from sending events correctly, usually some kind of JavaScript optimization plugin.

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 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.)

The measured conversion value is too high in Google Ads

Situation: The measured conversion value is too high in Google Ads. When comparing the conversion value of each transaction in the Google Ads website report with the actual transaction value in WooCommerce, the Google Ads conversion value is higher than the actual transaction value.

Here's how that might look in the Google Ads website report. When comparing the conversion value with the actual transaction value in WooCommerce, the Google Ads conversion value is higher than the actual transaction value:

This can be explained by one or several of the following reasons:

• You've enabled one or several campaigns to bid higher for new customers: In that case, Google Ads will increase the conversion value for new customers by the set value. This is a feature of Google Ads and not a bug.

  

  You might experience this only while using using the Pixel Manager. The reason is that the Pixel Manager is one of the few tracking code managers that is able to distinguish between new and existing customers and sends the new_customer parameter to Google Ads as described in the Google Ads documentation.

• You are using the Pixel Manager conversion value filter to increase the conversion value: In that case, the conversion value will be increased by the conversion value determined by the filter. This is a feature of the Pixel Manager and not a bug. Read more about the conversion value filter here.

The Pixel Manager doesn't recognize custom order paid statuses.

The Pixel Manager uses the WooCommerce order paid status to determine if an order has been paid. If you use a custom order paid status, the Pixel Manager will not recognize it.

You can use the following filter to add a custom order paid status to the Pixel Manager:

/wp-content/themes/your-theme/functions.php

add_filter('woocommerce_order_is_paid_statuses', function ($statuses) {
  $statuses[] = 'custom-paid-status';
  return $statuses;
});