30knees

I'd like to revisit this. I have {categories:/}{id:/}{rewrite} as the product rewrite. Shouldn't domain.com/en/cat/123/typo automatically rewrite to domain.com/en/cat/123/correct? Because currently it doesn't. If I'm not mistaken, it used to work. Maybe I also just forgot to test last time.

I have the meta description field filled in but I see that search engines don't show this as the snippet in the search results. What is being shown is random. Some of it makes sense, other text not (eg a "thank you" from a reply to a review).

If people still choose the wrong country we know it's on purpose.

Good solution. How did you do that?

Perhaps the only way to minimise this would be to use some address verification / autocomplete system, at the very least for the postal code and city. Shouldn't be too difficult to implement, I'm assuming. Any thoughts on the solution?

I've noticed a couple of times now that customers from Spain mistakenly select Germany as the country (Germany is where the shop is based). This impacts the shipping price, the rate, and requires a manual correction of the address. I'm hoping this isn't some shipping fee scam but just a mistake by the customer. Is there any way to prevent this mismatch?

Is anybody using Zapier and thirtybees? I see there's a module to connect the two: https://addons.prestashop.com/en/third-party-data-integrations-crm-erp/24308-zapier-integration.html I am particularly curious about how good it is in fetching order invoices and integrating with Amazon Sellercentral.

I've not had any spam since using Turnstile. It's great!

D.h. ob es einen Update vom Modul geben wird? Vielleicht eher auf English datakick fragen?

@DRMasterChiefI wouldn't worry too much about maintenance mode. The risk that someone is going to get you for Google Fonts during maintenance mode is so small. Even if: an authority would just tell you off. 99.99% sure no fine.

I have a delay of 0, which means that the delay will depend on the cron job. Is this correct? Because at the moment the default queue isn't delaying anything, as far as I can tell.

Perhaps you need to test by disabling modules one by one?

We also load locally and nothing changed after the update. I just checked.

Yes, it works!

I see ... I think for my purposes (payment reconcillation) cart id isn't helpful at the moment, but maybe for someone else?

Found it, thank you. I was only able to upgrade to the latest. I couldn't select the version in the dashboard. I'm on the latest and did a test purchase, it worked. The only breaking changes listed for the latest compared to 2023-10-16 are: PaymentIntents now has automatic_async as the default capture method when capture method is not specified during PaymentIntents creation. For more information about async capture, view the asynchronous capture guide. Fields under rendering_options for invoices are now migrated under rendering. Product ‘features’ has been renamed to marketing_features. I guess they don't affect the module?

Oh, and would it be possible to add the order number as https://docs.stripe.com/metadata?

I noticed that under https://dashboard.stripe.com/developers API overview it says: You may be using multiple API versions due to your client libraries or plugins. And I see I'm using both API versions: 2023-10-16 2018-02-28 and not 2024-04-10 Latest Here https://docs.stripe.com/building-plugins#set-api-version it says: Your plugin should use the setApiVersion function, which will set the Stripe-Version HTTP header on all requests. Your users will use their own API keys to access Stripe, but this header will be included with every request. We recommend that you use the most recently published version of the API. The current API version and details on our versioning policy can be found in the API reference. New Stripe users automatically default to the latest version of the API. This header ensures that your connector is pinned to a specific API version, which keeps the occasional backwards-incompatible change from breaking your connector’s functionality. Users can upgrade their own API version through the Stripe Dashboard. If your connector relies on webhook events, their data format and structure depend on the user’s account API version. You should instruct your users to set the version in their Dashboard to match your plugin. Caution API versions can’t be downgraded. You should regularly release new versions of your connector to correctly handle any changes to JSON responses.

Ich muss noch nicht bilanzieren, will mich aber darauf vorbereiten. Würde alles rund um die Bestellungen schön erfassen für: UmSt-VA, ZM, OSS.

Danke, vielleicht muss ich mir JTL genauer anschauen. Eigentlich suche ich nur etwas für die Buchhaltung. Zudem: Der Connector wird ja nicht weiterentwickelt. Prestashop allgemein (nicht nur 1.6) wird ja zunehmend weniger von Dienstleistern unterstützt. Wenn ihr voll im JTL-System seid, wieso dann nicht auch den JTL-Shop?

Do you mean that (...) {if $PIWIK_USE_PROXY} _paq.push(['setTrackerUrl', u]); {else} becomes _paq.push(['disableAlwaysUseSendBeacon']); {if $PIWIK_USE_PROXY} _paq.push(['setTrackerUrl', u]); {else}

Mollie v4.5.3 works!

Ich hole diesen Thread wieder hoch, vielleicht hat sich was getan in der Zwischenzeit.

The solution was to enable CGIPassAuth On in the .htaccess.

p.s. Are there any changes in the webservice between tb and PS 1.6 that might cause the problem in the third party's implementation?