tufty

@tillkruess This is a great plugin, and you have also interested me in what the real world benefits are to Pro. I have money to spend on better performance but I think it is reasonable to expect a bit more information up front. This just seems defensive and unhelpful. I can think of plenty of free/pro comparisons that would not be misleading at all. For example, you could take 3-4 typical site/server configurations at one or two mainstram hosts, ranging from basic brochure site, through quiet WooCommerce to busy WC/BB. I’d be interested in metrics that told me whether there is any user perceptible benefit as you might get from increasing the frequency, or whether the benefit is all in the scalability, so you can do more with fewer CPUs.

That way I could judge the installation size where there is any payback at all, as adding CPUs or getting faster ones might be cheaper than the Pro license.

But that reference to GoDaddy seems to be very misleading. It appears that the quoted improvement is based on testing with/without Object Cache Pro, not Free vs. Pro. which is what the question was about.

I fully believe GoDaddy has seen big improvements (a) compared with no object cache, and (b) to server utilization while still delivering competitive front-end performance, but that is not at all relevant to smaller users trying to judge bang for buck here.

Hi @sandipmondal Yes I understand that and this is the fundamental reason why there are no frills in the integration, and won’t be unless the approach is switched to the API integration model.

It is simply not possible to have integration features that are comparable with eg. Shopify unless that is done. I’m guessing from your replies there are no plans to do so.

Hi @sandipmondal thanks for your reply. Unfortunately that code for the custom fields is no help. Customs data is 3 fields per product (description, HS code and country of origin), plus one for the barcode, so two custom fields for the whole order is not enough. And even if it was, there is no mechanism within Shipstation to map the order custom fields to products.

Here are the API documentation for Shipstation products and Order items. What is needed in the integration is to specify the corresponding meta tags in WooCommerce for customsDescription, customsTariffNo, customsCountryCode and upc.

Our Shopify integration manages to achieve this, so I am pretty sure it should be possible with WooCommerce.

Yes we already have unique SKUs for all products and variations. But they are not really very helpful for picking. Our workaround is to manually fix all variable product names in Shipstation, but that is a time consuming bodge.

Now I look at the images, they are fixed. Might be something Shipstation did!

Best wishes

Thank you @adamv3d

Having seen all our orders password protected I was thinking the worst. One would hope Sucuri would have some kind of quality control for their updates to stop the gremlins getting in.

I have solved this now after a lot of conflict testing.

It seem that our shortcode for the Accept button was [cookie_accept] which is not one of the shortcodes currently specified, eg. [cookie_button] or [cookie_accept_all]. By changing the shortcode to [cookie_button], 2.1.2 now works fine.

I do not know how [cookie_accept] came to be in the cookie bar message text in the first place, or how the wrong shortcode has been working for us since 2018, but I suspect that it was the default when we installed it and as the plugin was developed with additional features, the shortcode options were changed, while leaving the legacy shortcode working. And 2.1.2 removed that legacy support.

Hi there,

Sorry, I may have been unclear. These are payments that appear in the PayPal dashboard as fully authorised, not as pending. And the corresponding order in WC shows as on-hold. This happens on a small but significant propotion of Paypal orders through WooCommerce PayPal Payments. And it does not occur at all when I am using WooCommerce PayPal Checkout Gateway.

I was also encountering intermittent Paypal payment failures only with WooCommerce PayPal Payments, so I have now reverted to WooCommerce PayPal Checkout Gateway.

Best regards

I had this issue today. What with that and the problem that orders are intermittently marked on hold instead of processing, I’m going back to the old plugin again.

This is a problem for me. With all caches off, with 2.1.2 the button does not function. But I roll back to 2.1.1 and it works fine again.

So 2.1.2 has introduced this problem for me.

Hi, actually that was the first thing I checked and I could find no issue within Paypal to suggest there was anything pending.

Yes, I agree that it can make sense where the merchant wants flexibility to authorize instead of capture, and leave it On Hold pending review or confirmation. Plus I see this is the WC advised behavior. Although I think it is far more justified when waiting for offline payment, compared with something that is already confirmed by authorization and will capture automatically.

Our situation with Braintree is somewhat different in that the use of authorization instead of immediate capture is solely a workaround to the inability to make a partial refund between capture and settlement in the event a customer or we want to change an order before dispatch. We use other payment gateways which do not have this limitation for everything except Apple Pay.

Apologies. I had misunderstood you. I had assumed that the user would be guided to put the order on hold to effect the refund, not that all orders would be set to On Hold whether a refund was going to happen or not. So I was querying “the messaging to put on hold instead of immediate refund”.

If I had realised at the time, I would probably have mentioned that this approach requires not just an extra click for every order, but also verifying that each order should be set to processing, since there are other reasons an order might have On Hold status.

And the other issue with this approach is that a customer might be concerned if the order is not confirmed straight away.

Sorry for the confusion.

Excellent. The only things I can thinl of are about (a) the messaging to put on hold instead of immediate refund and (b) the way the variation to the authorized amount is dealt with, ie. can’t be increased.

Hi @mrclayton, OK. I had thought that if users are aiming to be precise, they will already have done the allocation between products and shipping, and that this is fallback that can be treated as a simple and separate “reverse fee”.

For a simple change in the order to remove an item that is not required, I would definitely do that in the order, putting the item back into stock, and then the capture would be the same as the order. For a simple refund of the whole shipping fee, I’d probably do the same.

But for partial refunds, such as cheaper shipping, or a customer emails to say they forgot to apply a coupon. It’s a little more complicated, and it would be quite helpful to be able to apply that as a ‘reverse fee’, generated while capturing the final amount.

Hi @mrclayton, TBH, I don’t think all line items are necessary… Just two fields between main amount and tax, and if you felt like it, a checkbox to calculate automatically based on a tax field.

In other words, with a disparity of 12, the initial dialog would offer a prefilled main filed of 12 with tax field zero, which I would manually alter to 10 and 2.

or I’d check the auto box and type in 20% as tax amount, so it would auto populate the fields with 10 and 2.

Hi @mrclayton There is one issue with doing it that way, which is that it should require an assumption about tax. At present, the auto-refund amount ignores tax. But when making a refund, I usually need to refund the tax component appropriately too.

If the partial refund is related to a taxable item, then we will split the refund between the main amount and tax.

One approach to mitigate this scenario would be instead of silently creating a refund with no tax, make a dialog offering to alter the order amount with fields for splitting the total difference between order and captured amount between tax and value.

• This reply was modified 3 years, 3 months ago by tufty.