Herbert van-Vliet

Thanks.

Ok, thanks, that clarifies things.

So I understand that the pixels are loaded from remote domains and they are reporting back to those sites directly. Let’s for example use Facebook.
That means that if Facebook is blocked (through e.g. AdBlock, Brave Shields, or when the site applies the visitor’s cookie consent properly), the pixel would not be loaded and no information can be sent to Facebook.

I’m not sure what the word “primarily” in your response means, but your plugin must send its own code to the website in order for data to be sent directly back to the website. The Facebook pixel is not going to do that for you.
Right?

Assuming your plugin does send its own code on the thank-you page, the WooCommerce view “PMW pixels not fired” will contain those orders where the user never went back to the “thank-you” page: this can be decided because the plugin code reports directly to the website (and cannot be blocked by AdBlock, Brave Shields and so). No cookies required for that either: all is good.
Unless of course the end user doesn’t bother going back to the thank you page because of the off-site payment settings or UX.
That’s why you can say to fix it “if it gets below 90%” (ref. https://sweetcode.com/blog/are-all-payment-gateways-created-equal#what-can-you-do-to-fix-the-tracking-accuracy).

Does this describe what’s going on?

There seems to be an option after all?
https://www.ads-software.com/support/topic/add-filter-to-ignore-certain-emails-2/

I did some additional testing, and this seems to not select what I would like:

parent slug equals “ovk”
OR
slug equals “ovk”

If I use only: parent slug equals “ovk”, it selects the 16 posts.
If I add: slug equals “ovk”, it selects just 1 post.
The expected number is 17.

This is without status “Published” – there are some revisions that I would like to exclude, but that is now separate from the above mentioned issue.
I assume it means adding: status equals “publish”, but with an AND somehow? The query would be (slug = “ovk” OR parent_slug = “ovk”) AND status = “publish”.

• This reply was modified 1 year, 3 months ago by Herbert van-Vliet.

Did not work (plugin version 2.0.0):

01-13-2023 @ 12:22:24 - Push callback. Created order. 45636
01-13-2023 @ 12:30:44 - Syncing admin edited order item to Svea.
01-13-2023 @ 12:30:44 - Trying to get with admin checkout client.
01-13-2023 @ 12:30:45 - Syncing admin edited order item to Svea.
01-13-2023 @ 12:30:45 - Order 39674682 (ID: 45526, Order number: 45526) could not be updated (missing CanUpdateOrderRow in actions). Aborting
01-13-2023 @ 12:30:45 - Order 39674682 (ID: 45526, Order number: 45526) could not be updated (missing CanUpdateOrderRow in actions). Aborting
01-13-2023 @ 12:30:51 - Getting order 39674682 for updating with admin client
01-13-2023 @ 12:30:51 - Order 39674682 (ID: 45526, Order number: 45526) could not be updated (missing CanUpdateOrderRow in actions). Aborting
01-13-2023 @ 12:30:51 - Order 39674682 (ID: 45526, Order number: 45526) could not be updated (missing CanUpdateOrderRow in actions). Aborting
01-13-2023 @ 12:30:51 - Order 39674682 (ID: 45526, Order number: 45526) could not be updated (missing CanUpdateOrderRow in actions). Aborting

Worked (plugin version 2.0.1):

01-13-2023 @ 14:22:26 - Push callback. Created order. 45648
01-13-2023 @ 14:25:47 - Validation callback for Svea order ID (41126497) received
01-13-2023 @ 14:25:47 - Processing checkout for Svea Order ID: 41126497
01-13-2023 @ 14:25:48 - Validation callback successfully made for order #45648 (ID: 45648)
01-13-2023 @ 14:25:48 - Sending validation response: array (
  'Valid' => true,
  'Message' => '',
  'ClientOrderNumber' => '45648_2',
)
01-13-2023 @ 14:25:48 - Output buffer at checkout catched the following: 'nono'
01-13-2023 @ 14:26:14 - Syncing order rows. Order ID: 45648
01-13-2023 @ 14:26:14 - Push callback. Finalizing order. 45648

I also made some other adjustments (turning off other – possibly conflicting – plugins) so I’ll turn those on one by one and give more feedback.

Let me know if you need any additional information, but your version 2.0.1 seems to have fixed the issue.

We have the exact same thing.
WordPress: 6.1.1
PHP: 7.4.33
Woocommerce: 7.3.0
Svea Checkout for WooCommerce: 2.0.0?

I turned on the logging function in the setup for svea. Next thing is to find out where that logfile is located. ??

OK, But I think I need help with the free plugin.

The fact that I purchased an addon was to clarify and help direct the efforts.
If it turns out I need help with the commercial addon, I will use the link.

So my rephrased question is:
Does anyone know the likely cause of the eternal redirection, and where in the code this cookie gets checked?

Ah, I hadn’t dare trying the delete button without advice.
The root issue remains but this cleaned the list up at least.

Yes, brilliant. I hadn’t read that far in the code – in the details it’s mentioned, but in relation to RML which I don’t use.
It does what I need it to do in robust way.

Thanks Sergio and Alex.

For one site, I turned off all plugins except WP Remote Users Sync, then turned them back on and that got rid of 404’s. I suppose one of those plugins called flush_rewrite_rules().

Then came across this sticky and this solved the issue for me for the other site.
Chapeau!

• This reply was modified 4 years, 9 months ago by Herbert van-Vliet.

It’s not resolved.
But I found out it has to do with the Simple Lightbox plugin, so I’ll do without the latter.

Symptoms: for certain pages the user was redirected to the login.
After logging in, the user was redirected to the login again etc.

Seemed to be around line 901 of includes/core/class-access.php

Well apologies, I did have my needs met with a similar plugin, so I would have to reinstall the plugin. So the situation has changed already.

If you are not getting anymore similar feedback, I suppose you could close this and conclude it was a specific user setup issue or so.

Thanks for your support Kevin. Appreciated!

But let me know if you would like me to try.

• This reply was modified 4 years, 10 months ago by Herbert van-Vliet.

I went back (browser back), reloaded the page, made the changes again, submitted again. Same issue. Tried both buttons (but those are just submits).
Also checked if it mattered going into the setup page from the link in the plugin list, or from the menu – it didn’t seem to matter.

I was thinking it could be a nonce-thingy, but haven’t spent anymore time on it.

I changed the download method under products under settings from force to redirect.

There is more information on the plugin author’s website.