Hi @aimeos,

when I am logged in and start the checkout process, my address is automatically added to the basket, which is good.

When I return to the main page and log out, my address, billing details, etc are still part of the basket. Is this intended behaviour? When a user logs out, IMHO he wants his personal information to be "forgotten".

Should we clear the address and all service providers when a user logs out?

Currently all classes are called like Standard, Base, Factory, Iface. That makes working with an IDE way more complicated, e.g. with PhpStorm there is a good autocomplete that checks for class names and even a search by classname option. It would also automatically add corresponding use statements.

So if the the class for the Order would be called OrderStandard (or depending if it is used in aimeos-typo3 OrderTypo3) one could easily find the correct class by searching for "Order". That, however, is not so simple with only the namespaces.

In regards to backwards compatibility it would be relatively simple to achieve by adding corresponding class_aliases.

Some payment providers include the whole payment credit card form by inserting some hrml code and javascript. In 2016 version I had to overwrite the whole form by using a decorator but with 2017 this should have been improved. When updating to 2017 I want to make use of this, so I would like to know how I would do this.

Thanks for answers in advance.

It seems PayPal has gotten more strict in the last week or so.

https://github.com/aimeos/aimeos-core/blob/94d09cacf6e7973916d9b23c2e75ccca33152712/lib/mshoplib/src/MShop/Service/Provider/Payment/PayPalExpress.php#L751-L754

can result in

"MAXAMT":221.75,
"PAYMENTREQUEST_0_AMT":"221.74",
"PAYMENTREQUEST_0_ITEMAMT":"214.01",
"PAYMENTREQUEST_0_SHIPPINGAMT":"7.74",

It seems that earlier individual items were not checked and the MAXAMT field was fine for rounding errors in the total.

We get "Total mismatch. See additional message for details. / The totals of the cart item amounts do not match order amounts." back from PayPalExpress now.

Adds an option for crop thumbnail generation with Imagick. When square thumbnails are used in the product catalog list (e.g. with background-size: cover CSS code), unproportinal images cause either very large preview images or very blurry scaled ones. This configuration option adds a possibility to choose between scaling and scale-cropping thumbnails.

No breaking changes, fully backwards compatible, all documented.

What do you think?

2 Bugfixes:

• in getCoupons() matching products to coupon codes would not work, because the products are stored by their position index in $products[$baseId] but matched by their product ids.

• in loadFresh() coupon codes were not loaded, even when with \Aimeos\MShop\Order\Item\Base\Base::PARTS_COUPON bit set in the $parts bitmask. There are some extra steps required in order to get this task done, but everything should work as intended and documented now.

Hi @aimeos Team,

may I ask for when the next 2018.10.x release is scheduled? We would like to launch our new shop in a couple of weeks and need the latest bug fixes / features - if possible on the stable branch..?

Best regards, Nils

When loading an order with the order base manager as a fresh order, the order elements (address, products, services, coupons) are added successively. However, the order plugins are not registered yet. Because of this behaviour, coupons are not added properly, as the coupon item is not added and therefore the rebate is not considered in the basket. Other plugins cannot provide their functionality, too, eg. address based order manipulation etc.

We found a bug this night on selections if stock of the product is set to null. Here the exception:

Executing statement " INSERT INTO "mshop_stock" ( "productcode", "siteid", "typeid", "stocklevel", "backdate", "mtime", "editor", "ctime" ) VALUES ( 'fb-b-einfach', 1, 1, NULL, NULL, '2017-02-15 00:05:28', '', '2017-02-15 00:05:28' ) " failed: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1-fb-b-einfach-1' for key 'unq_mssto_sid_pcode_tid' #0 /var/www/clients/client15/web7/web/typo3conf/ext/aimeos/Resources/Libraries/aimeos/aimeos-core/lib/mshoplib/src/MShop/Stock/Manager/Standard.php(258): Aimeos\MW\DB\Statement\PDO\Simple->execute() #1 /var/www/clients/client15/web7/web/typo3conf/ext/aimeos/Resources/Libraries/aimeos/aimeos-core/lib/mshoplib/src/MShop/Common/Manager/Decorator/Base.php(187): Aimeos\MShop\Stock\Manager\Standard->saveItem(Object(Aimeos\MShop\Stock\Item\Standard), false) #2 /var/www/clients/client15/web7/web/typo3conf/ext/aimeos/Resources/Libraries/aimeos/aimeos-core/lib/mshoplib/src/MShop/Common/Manager/Decorator/Sitecheck.php(42): Aimeos\MShop\Common\Manager\Decorator\Base->saveItem(Object(Aimeos\MShop\Stock\Item\Standard), false) #3 /var/www/clients/client15/web7/web/typo3conf/ext/aimeos/Resources/Libraries/aimeos/aimeos-core/controller/common/src/Controller/Common/Order/Standard.php(454): Aimeos\MShop\Common\Manager\Decorator\Sitecheck->saveItem(Object(Aimeos\MShop\Stock\Item\Standard), false) #4 /var/www/clients/client15/web7/web/typo3conf/ext/aimeos/Resources/Libraries/aimeos/aimeos-core/controller/common/src/Controller/Common/Order/Standard.php(340): Aimeos\Controller\Common\Order\Standard->updateStockSelection('352', 'default') #5 /var/www/clients/client15/web7/web/typo3conf/ext/aimeos/Resources/Libraries/aimeos/aimeos-core/controller/common/src/Controller/Common/Order/Standard.php(298): Aimeos\Controller\Common\Order\Standard->updateStock(Object(Aimeos\MShop\Order\Item\Standard), -1) #6 /var/www/clients/client15/web7/web/typo3conf/ext/aimeos/Resources/Libraries/aimeos/aimeos-core/controller/common/src/Controller/Common/Order/Standard.php(58): Aimeos\Controller\Common\Order\Standard->updateStatus(Object(Aimeos\MShop\Order\Item\Standard), 'stock-update', 1, -1) #7 /var/www/clients/client15/web7/web/typo3conf/ext/aimeos/Resources/Private/Extensions/ai-controller-frontend/controller/frontend/src/Controller/Frontend/Order/Standard.php(77): Aimeos\Controller\Common\Order\Standard->block(Object(Aimeos\MShop\Order\Item\Standard)) #8 /var/www/clients/client15/web7/web/typo3conf/ext/aimeos/Resources/Private/Extensions/ai-client-html/client/html/src/Client/Html/Checkout/Standard/Order/Standard.php(273): Aimeos\Controller\Frontend\Order\Standard->block(Object(Aimeos\MShop\Order\Item\Standard)) #9 /var/www/clients/client15/web7/web/typo3conf/ext/aimeos/Resources/Private/Extensions/ai-client-html/client/html/src/Client/Html/Base.php(150): Aimeos\Client\Html\Checkout\Standard\Order\Standard->process() #10 /var/www/clients/client15/web7/web/typo3conf/ext/aimeos/Resources/Private/Extensions/ai-client-html/client/html/src/Client/Html/Checkout/Standard/Standard.php(354): Aimeos\Client\Html\Base->process() #11 /var/www/clients/client15/web7/web/typo3conf/ext/aimeos/Classes/Controller/AbstractController.php(167): Aimeos\Client\Html\Checkout\Standard\Standard->process() #12 /var/www/clients/client15/web7/web/typo3conf/ext/aimeos/Classes/Controller/CheckoutController.php(32): Aimeos\Aimeos\Controller\AbstractController->getClientOutput(Object(Aimeos\Client\Html\Checkout\Standard\Standard)) #13 [internal function]: Aimeos\Aimeos\Controller\CheckoutController->indexAction()

I am trying to retrieve the config value for

controller/jobs/product/import/csv/location

from within an admin panel, but using

$view->config('controller/jobs/product/import/csv/location', false); 

returns false. If I set the value in shop.php then the value set there is retrieved rather than the config override set in locales > sites > subsite.

Should the config helper return overridden values or is there another function to do this?

Current behaviour: When an active coupon code becomes unavailable - e.g. because a price condition is not met anymore after a product was deleted from the basket -, the coupon just disappears without a notice. It is still stored (but invisible), so when the user tries to enter it again, he recieves a cryptic error message saying the maximum limit was reached.

This PR fixes the described behaviour: When a coupon becomes unavailable, an exception is thrown. Furthermore, the coupon code is entirely removed from the basket. This is way more intuitive IMO and is standard behaviour in major online shops like Amazon.

Last but not least, the coupon provider catches the exception and integrates it into other error messages regarding unavailable coupons.

When a coupon code is entered but invalid (eg. because the basket decorator does not fit requirements), no error message is displayed. The code just becomes part of the basket but does not have any effect on the basket value.

IMHO it would make more sense to explain the problem to the user like it happened in 2018.10 so the user can enter another coupon code or change his basket contents.

Same thing happens when the coupon code gets invalid because the basket content changed - the user may not even recognize the coupon is no longer valid. The invalid coupon code should be removed from the basket (IMHO) or at least the user should see a note explaning to problem.

Following on from the discussion on the below thread, I have updated the plugin to query on product code(s) not product ID.

This enables product attributes to be stored on order products that have types of selection or bundle.

https://aimeos.org/help/viewtopic.php?p=15713#p15713

Hi everyone,

the 'Supplier' provider allows the customer to choose a supplier during the checkout process, when 'Pickup' was chosen as the delivery option. Downside: Every supplier is listed here, regarless if the product is available at this specific supplier or not.

We are discussing to implement a new decorator, which checks if the supplier can supply all products in the basket first (getting this information from the 'Products' tab at the supplier backend) and removes it from the selection list in the checout area if not.

Not sure yet if we are going to provide the 'Pickup' method at all, but IF we do - are you guys interested in adding this feature to the core or shall I implement it only for our own usage?

Regards, Nils