DRMasterChief

Since yesterday/today, there has been a notification regarding an update for the PayPal module. When you update it, you get a message stating that it is outdated/deprecated. Okay team @Acer, it’s time for more information. PayPal is extremely widespread and used by practically every merchant and customer alike. How do we proceed?

To be honest, you’d have to try it out. I didn't have an eye on ASM. We don't use any inventory management within the shop itself; instead, we use separate software in the office and warehouse.

Thanks for the `tbchangecarrier.zip` module; I’ve taken a quick look at it. Fundamentally, it serves a different purpose: `tbchangecarrier`: Actually changes the order's shipping carrier in the database - updating `id_carrier` in both the `order_carrier` and `orders` tables. It does not send an email to the customer; it is purely a silent correction made in the backend. My module, designed for our specific requirements, does not alter the order data at all; it simply provides the option to send the customer a different (additional) tracking email containing a different tracking link. It uses a hook to integrate into the order overview page in the backend, providing a dropdown menu for shipping methods and a field for the tracking number. Once the details are entered and submitted, the customer receives a shipping notification containing the correct link. The reason for this is that we often handle both very light and very heavy packages sometimes within a single customer order. 0.5 kg package is shipped via DHL using the native tracking link in the backend. 35 kg package is shipped via DPD using the "new" tracking link in the backend, which points to DPD tracking. However, the customer cannot actively select DPD shipping in the shopping cart at all. That is the reason why I included this information in this topic. After all, there are -so to speak- "multiple" tracking numbers involved, and this allows any number of shipping emails to be sent to the customer (for example, even for 10 packages...).

Thanks for the info - but that’s not really an issue here on the forum, nor regarding the technical feasibility. If such conditions or rules exist in a given country, each dealer is personally responsible for compliance—that goes without saying. Contractual terms can also be agreed upon online (in Germany, these are known as General Terms and Conditions), and a dealer could certainly address this there before the contract is concluded. Let’s continue discussing the "technical" side of things.

Is anyone else working on this? I’m currently creating a module that allows the admin to select from various shipping carriers, so the customer receives the correct tracking link (regardless of which carrier they chose at checkout). We run into this situation sometimes because packages can't always be shipped via DHL, so we have to use a different carrier. However, the customer needs to receive the correct tracking number with link; otherwise, Thirty Bees simply uses the standard link for the selected shipping method and appends the tracking number (then it goes wrong).

Hello, no, I haven't pursued that any further at the moment.

Claude Sonnet w/wo Codex is about 4 times better for coding than ChatGPT, especially for PHP fixes and .tpl The threadopener should give them a try, you can prompt various tests and use all this new code in a testshop. Also Qwen Coder is very impressive.

any Cronjob active?

Great, thank you for this fast fix, i already use it. The biggest problem is that the error cannot be reproduced. It is also unusual because it occurs extremely rarely. However, we regularly experience issues with orders from Ireland—though without the error message—yet the problem is similar (the order is not created). Do we have to change the others too? if ($this->context->cookie->logged) { $idCustomer = PaypalCustomer::getPayPalCustomerIdByEmail($email); if (!$idCustomer) { $ppc = new PayPalCustomer(); $ppc->id_customer = $this->context->customer->id; // ⚠️ $ppc->paypal_email = $email; $ppc->add(); } $customer = $this->context->customer; // ⚠️

The only module we have for cookies is EU Cookie Consent v1.0.2 from thirty bees (with an information for customer about session cookie) , no GeoIP, and we really do not use any cookie except the standard session cookie for cart, an no third-party checkout system or OPC. As far as I know, therefore, there is nothing the customer could "refuse to consent to" that would then cause problems.

The 500 appears at the customer's location, not in our shop 😞 Do you need any other details? Exception Message: ThirtyBeesException: Property PayPalModule\PayPalCustomer->id_customer is empty Location: classes/ObjectModel.php line 1054 Stacktrace #0 classes/ObjectModel.php(1054) #1 classes/ObjectModel.php(333): ObjectModelCore->validateFields() #2 classes/ObjectModel.php(361): ObjectModelCore->getFields() #3 classes/ObjectModel.php(610): ObjectModelCore->getFieldsPrimary() #4 modules/paypal/controllers/front/expresscheckout.php(151): ObjectModelCore->add() #5 modules/paypal/controllers/front/expresscheckout.php(63): PayPalexpresscheckoutModuleFrontController->processPayment() #6 classes/controller/Controller.php(209): PayPalexpresscheckoutModuleFrontController->initContent() #7 classes/controller/FrontController.php(264): ControllerCore->run() #8 classes/Dispatcher.php(858): FrontControllerCore->run() #9 index.php(33): DispatcherCore->dispatch()

Paypal: Error occurred please try to contact the merchant: an unknown error occured. The payment status is 'approved' Hi, we received a report of this error today from a customer in Germany; it has also happened twice in recent weeks with customers from Ireland. The customer receives a 500 error, and the order is not created in the shop, though the open shopping cart remains saved in the back office. We are running tb v1.6.0 and PHP 8.1.34, with the thirty bees PayPal module v5.6.2. We are, of course, in live mode (not sandbox), and everything had been running smoothly for weeks, but now these errors are occurring intermittently. This is a problem, so we are asking for help or a solution—specifically if any changes need to be made to the module. This is a critical issue, as a PayPal module is not something we should ideally be modifying ourselves.

I don't think the issue lies with the thirtybees system itself; it's likely due to limitations imposed by the hosting provider. There is a lot of potential here. You can find providers offering managed web hosting at a low cost, though performance and quality vary significantly. For a standard-sized online shop, it is generally never necessary to use a VPS or a dedicated server. A dedicated server represents a massive security risk that requires management—something you either need to handle yourself (you need to be a sysadmin with extensive knowledge to do this) or hire someone else to do. >> You'd better focus on your business, not on web servers 🙂 Personally, I have had far better experiences using ready-made hosting packages that offer sufficient performance. Which country are you in, or where do you need/want to host? I’m not a hosting provider myself, of course, but I’d be happy to recommend one or two excellent options where thirtybees runs smoothly with up to 300,000–400,000 products.

Hi @Smile Thanks for the module and the work you've put into it. I haven't tested it myself yet. Could you perhaps post 3–4 screenshots here—sort of a mini-guide? That way, people could get a basic idea of what it looks like. I’d be happy to do it myself, provided the developers are okay with that. However, I’m using a test shop with a third-party theme, so it wouldn't show the standard theme, and I don't think that would be ideal.

Hi Pedalman, auch wenn ich nicht Entwickler davon bin, denke ich daß das natürlich technisch geht. Gefordert ist ja eine "deutliche Abhebung" vom Rest, die du mit deinem Beispiel aber nicht mehr hättest, das aber nur als Info und dir wird das aber schon bekannt sein. Hier gibt es auch ein offizielles Modul mittlerweile: One-Click Order Withdrawal - Modules - thirty bees forum Was/wo die Unterschiede von beiden Modulen sind kann ich nicht sagen, habe sie noch nicht getestet sondern derzeit ein eigenes im Einsatz.

klingt ja schonmal cool, halte uns auf dem laufenden!

can´t wait for it - great. 🙂 👍

Due to email volume, reputation issues, and persistent problems with GMX and Hotmail (and all MS services...), we’ve been using brevo.com for the past few days (specifically for transactional emails). The setup process is fine; domain verification is quick and mandatory. However, the FAQ section is a bit outdated in places. It was important to us that the service be hosted within the EU. Their prices are lower than the provider you mentioned, though you’ll need to compare them yourself. Brevo.com doesn't strictly separate SMTP and marketing services, so you get everything bundled together in one package.

Hi, wenn du die Daten im Shop gut gepflegt hast (insbes. Gewicht etc.) könnte man damit ein kleines Modul für die (CSV-)Ausgabe bauen, die kannst du ja auch direkt an DHL übermitteln, da gab es doch mal einen Dienst der bei Verbindung dann "hört" ob Daten reinkommen und wenn, dann wird der sofortige Labeldruck angestossen (JTL macht es auch so).

Eine Lösung um die Grundpreisangabe auch in deutsch anzuzeigen. Die Werte sind ja im Backoffice hardcodiert in englisch und daher nicht einfach so bei den Übersetzungen möglich. Ich habe die product.tpl des Themes um folgendes erweitert, es wird entweder direkt die Bezeichnung abgefragt oder alternativ kann man auch mit "Anzahl der Zeichen" arbeiten. Wenn die Grundpreisangabe also bspw. in "Stück" ist, dann sind es 5 Zeichen, siehe Beispiel bei ==5 Hier mit einigen Beispielen, kann natürlich auf den jeweiligen Shop und die Grundpreisangaben angepasst werden: {if !empty($product->unity) && $product->unit_price_ratio > 0.000000} {math equation="pprice / punit_price" pprice=$productPrice punit_price=$product->unit_price_ratio assign=unit_price} {assign var='unity_display' value=$product->unity} {if $lang_iso == 'en'} {assign var='unity_len' value=$product->unity|count_characters} {if $product->unity == '1 qm'} {assign var='unity_display' value='1 sqm'} {/if} {if $product->unity == 'Auto'} {assign var='unity_display' value='Car'} {/if} {if $unity_len == 5} {assign var='unity_display' value='Piece'} {/if} {/if} <p class="unit-price"><span id="unit_price_display">{convertPrice price=$unit_price}</span> {l s='per'} {$unity_display|escape:'html':'UTF-8'}</p> {hook h="displayProductPriceBlock" product=$product type="unit_price"} {/if}

We are still using the existing PayPal module with thirtybees 1.6 on PHP 8.1, and without any problems!

Ah ok! Baust du auf einem vorhandenen Controller auf oder ist es ganz neu erstellt?

gut zu hören! magst du Screenshots von deinem Modul hier zeigen?

I'm not entirely sure, but you might be able to change the email address in the database to one that definitely works, and then use the "forgot password" function on the back-office login page. Come on, we're going to end up with a complete guide here 🙂

@Madhosh i think you should urgently install the module in BO: Mail via phpmailer v.1.1.1 (this is the new module for E-mail transport and you need this)