mattdallan

Awesome! We’ll get those docs updated.

Thanks for the report and have a great week!

Hi @squadcar,

Thanks for the update.

I had a closer look at the code and it looks you need to cancel the existing scheduled action for a new one to be created with the updated interval.

Can you please click the “cancel” under the wc_square_sync scheduled action, as seen in the screenshot: https://d.pr/i/cfLRV7

Once you confirm this, I’ll double-check if this manual step is required by running it by the team and then we’ll update our documentation.

> Just to double check, the following code works for you when included in your theme’s functions.php?

Yes, that’s correct. I’m using the same code in my functions.php ??

Hi @hollymcr,

> The idempotency_key that was failing was 50 chars long. Looking at the Square API info 128 chars should be accepted

Thanks for bring this to our attention! Can you please share a link to the Square API docs that mention 128 characters?

Here’s a link to the Square API library we use in our extension and is says the idempotency_key has to be MAX 45 characters (screenshot: https://d.pr/i/mD8UTF)

In our Square extension we set the idempotency key on payment requests to have the value: {32-char-hash} + : + Order number + - + number of failed attempts.

With a 45 character limit, that leaves 12 characters after the {hash}: for the order ID and number of failed attempts, which I believe will only become a problem after the order ID gets larger than 999,999,999.

In the examples you shared, you had XXXXX-ORDER-1234 in the Failed case: 77c03b5942fa2784e3304b45a4a164d5:XXXXX-ORDER-1234.

What is adding the XXXXX-ORDER- to the idempotency key value??
Do you have some other plugin that customises the value returned by get_order_number to include the xxxx-order- at the front?

Thanks for reporting this.

Hi @squadcar, that filter still works in v2.2.0 so let’s dig into what might be causing the problems you’re having.

First, let’s check your sync event is setup to recur every 15 minutes.

To do this:
1. Visit the action scheduler table by going to WooCommerce > Status > Action Scheduler (tab).
2. Click to filter only pending scheduled actions, then use the search bar to search for wc_square_sync.
3. Check the wc_square_sync scheduled action is set for the 15 minutes recurrence (here’s a screenshot of what it should look like: https://d.pr/i/siLz50)
4. While you’re here, check that the scheduled date is also in the future. If it says something like “2 hours ago” it means cron is not working properly, which means the sync events are not firing off properly

If this is all setup correctly, something that may be causing your syncs to not occur every 15 minutes is if the sync is still in progress (i.e. if sync process takes longer than 15 minutes)

If a sync is already in progress, we don’t run another sync and will try again when the next sync interval comes around (15 minutes in your case).

Do you know roughly how long your sync process is taking? It could be that it’s taking longer than 15 minutes.

Hey @popped,
Sorry for the trouble you’ve been having with syncing and importing.

Firstly, rolling back to 2.1.6 is a good option while we investigate the issue.
If you have access to PHP error logs and Square logs (found in WooCommerce > Status > Logs), that should help us understand what is going wrong.

Hi @gawebwarrior, thanks for sharing those logs with us as they’re very helpful.

The logs point to our function update_image_from_square() which is fetching the product image from Square and updating it on your product in WooCommerce.

The fatal error you linked above shows that our API request to Square returned in invalid response.

Can you please go into your WooCommerce > Status > Logs and use the dropdown to select and view the recent Square logs for square-2020-09-02 please (here’s a screenshot of how to view them: https://d.pr/i/QJqHha)

In these logs you should find an API request and response that is causing this fatal error.

Searching that file for the string: retrieveCatalogObject will point you to the request that failed.

Let me know if this log shows has any information as to what has caused this issue.

Thanks for your patience

Thanks @nf-graphic-design, we’ve had some reports of syncing getting stuck but it only seems to be affecting some customers and we’re unable to reproduce it in our own stores.

To help us diagnose what is causing this, lets gather some more information:
– After upgrading to 2.2.0, are you still seeing any PHP fatal errors in your logs when syncing?
– Have you tried disconnecting/reconnecting recently? I can see you did this in your original message but it might be worth redoing after it has gotten stuck again (disconnecting from Square clears out any sync session data)
– Roughly how many products are being synced in your store?
– Is it manual sync or automatic syncing, that keeps getting stuck? or both?

> Is it normal for 3 square scheduled actions to be sitting in pending?

Thanks for double checking the Action Scheduler. Yes there are 3 scheduled actions we use in Square:
– wc_square_refresh_connection
– wc_square_index_customers
– wc_square_sync

Next to the Sync scheduled action, can you confirm that the next scheduled date is in the future (screenshot)?

Thanks for your patience while we look into this issue.

Hi @kegobeer,

Thanks for the updates on your issue and I’m glad to hear that the import is now working, but I understand it’s still very slow.

Since the import process now also updates existing products from Square (previously these were skipped), it’s possible some update queries to the DB may be slowing this process down now.

One option our team will look into is allowing store managers to run the import without updating products. Either by selecting or deselecting some checkbox after clicking “Import all products from Square” or adding some filter to toggle it off with a code snippet.

How many products do you have in Square and how long is it taking to complete the import process?

Thanks!

Hi @kegobeer, thanks for getting that information to us!

Do you know how long Sitegrounds timeout is? Square defaults to 5 minutes (300 seconds) and from googling around, I see some people mention Siteground has a 30 second timeout. Given that, you could try using the following filter to change the max execution time we use in Square.

function kegobeer_set_square_time_limit( $default_time ) {
    return 30;
}

apply_filters( 'wc_square_time_limit', 'kegobeer_set_square_time_limit', 10, 1 );

It’s worth mentioning that we didn’t change anything in version 2.2.0 that would cause this to start breaking, so if it’s working when you reverted back to 2.1.6 there must be something else causing this problem.

Do you have any fatal errors logged in WooCommerce? Here’s a link for how to check for these: https://docs.woocommerce.com/document/finding-php-error-logs/#section-1

Hi @nf-graphic-design,

Thanks for reporting this issue to us.

> Uncaught Error: Call to a member function getCursor() on string

This error has been fixed in 2.2.0 which was released on 31 August. Could you please try upgrading on a staging/test site and see if you still notice this issue?

Thanks

Hi @parale3000,

Thanks for opening a ticket.

> checkout it redirects on Paypal but the country selected on the menu is US where as we are in a different country

The default country field is based on your stores base country which is then mapped to one of PayPal’s supported locale codes. According to PayPal’s documentation the locale code for Cyprus is en_US, which means the default country will be set to the US.

Thankfully there is a work-around for this.

If you would like Cyprus to be the default location, you can filter the value of woocommerce_paypal_express_checkout_paypal_locale and return 'en_CY'. Here’s a snippet to get you started:

function parale_ppec_cyprus_default_country( $default_locale_code ) {
    return 'en_CY';
}
add_filter( 'woocommerce_paypal_express_checkout_paypal_locale', 'parale_ppec_cyprus_default_country', 10, 1 );

> We need to achieve a guest checkout without having to create an account which works fine when the US selection is there but when you change the country from the dropdown to Cyprus you get an extra form asking you to create an account which is compulsory.

This restriction is coming from PayPal and we cannot change this from our plugin. From my understanding, in order for PayPal to support taking payments in some countries, they need the customer to create an account.

To get more information on this, I would suggest contacting PayPal.

Let me know if you have any further questions ??

Hi @brucerawles,

You can edit the Square title and description that gets displayed to customers by going into the Square gateway settings (WooCommerce > Settings > Payments > Square) and then updating the title and description fields to remove any reference to Square.

Here’s a screenshot detailing which fields to edit: https://d.pr/i/5z4Hpx

Hope this helps!

Hi @hastibe, I’m glad to hear this started working without needing to change anything. That also makes me very curious as to what was causing this issue.

The error you mention is coming from PayPal’s side of things so maybe they went down temporarily and have fixed things on their end.

I will make this as resolved but please open a new ticket if this comes up in the future.

Hi @gavodel,

The default country you’re referring to is set by the local code that we send to PayPal when rendering the PayPal buttons on the page.

When I look up Ireland in the list of PayPal’s supported locale codes, I don’t see a unique locale code and it just says to use United States English (en_US): https://developer.paypal.com/docs/api/reference/locale-codes/#supported-locale-codes

Even though it’s not documented by PayPal I have just tested using ‘en_IE’ as the locale code and that produces the desired outcome you’re looking for: https://d.pr/i/RaTv26

In order to customise the locale_code you will need to add the following code snippet to your functions.php:

function gavodel_ppec_use_ireland_locale_code( $default_code ) {
    return 'en_IE';
}

add_filter( 'woocommerce_paypal_express_checkout_paypal_locale', 'gavodel_ppec_use_ireland_locale_code', 10, 1 );

Let me know how that goes.

Cheers!

Hi @rafikhassan, thanks for leaving a review.

The new Credit Card design in our latest version has come from updating to the newest PayPal Javascript SDK framework and unfortunately, we cannot change the design of these buttons within our plugin.

One way to bring back the old credit card design is to use the following filter to switch back to use the deprecated checkout.js integration:

add_filter( 'woocommerce_paypal_express_checkout_use_legacy_checkout_js', '__return_true' );

Keep in mind this javascript is no longer being updated or maintained by PayPal. More information here: https://developer.paypal.com/docs/archive/checkout/