Occam

In thirty bees the button is called Return products. Quite simply: Because I want it to happen! Just changing the status is like saying to a child: You just have to close your eyes and the wicked witch is gone. As for your questions: Just read my PDF carefully.

Sure you can, but given a long list of purchased products a total refund is easier to handle on click. If you would try the same in partial refund mode, you would have to refund every single product.

I wouldn't agree! The distinction makes sense! See my tutorial here: https://forum.thirtybees.com/blogs/entry/43-properly-create-refunds/

Hmmh ... bleeding what? I'm not so familiar with this kind of insider tb-speak. I suppose you mean some kind of development version. A link would be fine.

Like I already told @RabbitZzZ you need to apply the the fix proposed by Karlo Šimunović. However, this alone does not solve the cache error which may happen to AEUC from time to time. The hookDisplayProductPriceBlock.tpl will not show up when the Smarty cache is enabled. This is why I patched smarty.config.inc.php, too. In some parts it is a rollback of some improvements by @datakick, who totally dropped assigning variables by reference. Regardless of advices at Stackoverflow like i.e. this one, that assigning variables (with an ampersand prefix) as reference are deprecated in PHP 7 it seems that it still makes a difference. These changes didn't allow my AEUC module to correctly display the hook for tax and delivery costs. I attach both patched files here: Fix_translations_&_avoid cache_bug for AEUC.zip (removed following the moderator's suggestion)

This is not about the size of the admin.php. As the BO is fully translated the admin.php is complete. So why don't you just apply the fix that Karlo Šimunović has proposed in the above topic at Github. Though this does not help cure the strange behavior of AEUC under 1.1.0, it's a step in the right direction. Anyway, I currently wouldn't recommend 1.1.0 in Germany in production mode.

Great! Works perfect for 5-Step-Checkout in 1.1.0, too, because this bug is still unsolved.

Just for the record: What language are we talking about? Do parts show up or is everything English in BO? Considering other weird mistakes you've posted lately: What PHP version do you have? Are all minimum requirements for thirtybees/Prestashop met?

To just change the message would have been my first (and easiest to realise) advice, too. But I would prefer to drop this message completely and display instead a linked iframe with a SMS page containing delivery options.

i tested the same for orders with single or several products. The only difference is: I did it on a fresh (and not upgraded) 1.1.0. And with only native modules installed.

Yep Same result, no matter if one or more products. Testet only with tb 1.1.0.

Which they do! But after the refund you find another document - the credit note for refund. This is the proper way to refund or partially refund an order. Neither the original order nor the invoice should be changed for legal reasons. In PrestaShop it's just the same. Must be for some other reason. I cannot confirm the described behavior. I made 2 different partial refunds for he same order (first a product, then the shipping costs) and both worked without any error message. And for each action a correct credit note was generated. This even works if a state Payment refund was added after the first refund.

No fix, but a bypass: If bigger than 49 Bytes save file /translations/<yourlanguage>/admin.php Import the English language Go to Employees Change BO language to English and save Change BO language back to your language and save Clear cache and recompile If this does not help, check length of /translations/<yourlanguage>/admin.php If it is now (emptied to) 49 bytes, replace it with the formerly saved file This should do the trick, provided that your language is fully translated. Check this at Crowdin.

Seems to be even worse. If you clear cache and even import the latest translation files, you will face this issue that the translations are perhaps nearly complete while the whole BO is in English. This even happens for a language like German that provides apart from some minor lacks a full translated thirty bees. This bug is new and first appeared with TB 1.0.1.

I wouldn't think it's a matter of the PHP version but a known issue for releases elder than thirty bees Paypal 6.0. The const DEBUG_MODE = 'PAYPAL_DEBUG' was not defined.

Seems to refer to a non-existent configuration field in the database. I guess it would help to delete the waste line Configuration::deleteByName(static::DEBUG_MODE); In function deleteConfiguration() of your paypal.php.

Anyway, your initial error message had nothing to do with this module. The advice of Traumflug referred to the PHP 7.3 notice on using count() in error.logs.

First of all this doesn't seem to be the current release of the cheque module because there is no count() argument in line 66. However, if you meet this error or warning in PHP 7.3, then do this: Open the file, in this case cheque.php, go to the the questioned line and change the expression count to is_countable. This will help to avoid the message. That said, let's go to the ERR_EMPTY_RESPONSE, an error known from the Chrome browser. Try this: https://blog.pcrisk.com/windows/12807-err-empty-response

Did you regenerate the thumbnails?

Well, I don't have a clue what your home country is, but just for the record: AEUC (abbreviation for the module advancedeucompliance) is the only way for shop systems like PrestaShop or thirty bees, that are not legally compliant by default, to comply with European law. Without such a module you cannot run TB in European countries, not in France, not in Austria, not in the Netherlands or in my homeland Germany. Nope, you got me wrong. Do whatever you think you should. what I wanted to say was just that the focus for current developments should be on issues not yet solved at all.

Babysteps, please. Let them do it one by one. Currently the latest 1.6 PrestaShop module seems to work properly, as @toplakd said. So there is one working module. It's like AEUC with tb 1.1.0. The tb module throws a 500, my own module works properly. That's enough for now, right?

You better download the convenient module directly from Github: https://github.com/PrestaShop/paypal/tree/1.6.x

1.7 modules start with 4.0; currently its 4.0.1

I guess that the tb module is based on an older release of the PrestaShop PayPal module. Just my 2 cents ...

Sounds good, I wasn't really aware of that. But for 3.11.4 as for all 3.11x the same applies: that the page structure is noticeably delayed. PayPal does a POST-Request for every page called up. And that for every single page! Result: maybe your shop has a super-fast page structure, but then comes the PayPal request and takes 2-3 seconds. @Factor You are talking of tb's own Paypal module, whereas 3.11.4 is the PrestaShop native module.