Currently the price has to be set manually and whenever a price changes or a rebate is added, the price has to be recalculated. Some ideas:

• Maybe a price type automatic could be useful to still allow manual price.
• If the price is set to 0, calculate the price automatically and use the set currency.

Example bundle:
https://hamag-maschinenbau.de/index.php?id=12&L=43&ai[controller]=Catalog&ai[action]=detail&ai[d_name]=S%C3%A4gen_und_Anschleifen_mit_LAPIDA-Maschinen&ai[d_prodid]=453

As an alternative one could - instead of one bundle - add all products into the basket (as is done on Amazon with "buy together|all"). Though that's redundant with bought together Aimeos product associations.

Hi,

Typo3: 8.7.24
Aimeos: 2019.04.3

In the migration TablesUpdateCharsetCollation::checkTables changes to a table are executed but the default resource ("db") is used no matter the table. I did run into some problems here, as we use a separate db (not the typo3 db) for aimeos, but the customer tables are in the typo3 db.
If those migrations are executed for the table "mshop_customer" they are executed on the resource "db" instead of "db-customer".

I am not familiar with this part of the code, but I would guess all executes in TablesUpdateCharsetCollation::checkTables would need the parameter $name dependent on the table the execute is aimed at.
If my guess is correct, I'm happy to provide a pull request.

Greetings Sebastian Diez

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.

A recent update from 18.7.1 to 18.10.2 broke our attribute search. We think the following commit may have been the culprit. In particular, attributes don't seem to be aggregated prior to search any more.

We've implemented a combined attribute search, where filtering by two different
(hidden) attributes at once is possible.

An example:

Given two attributes of the name designer and manufacturer, the function \Aimeos\Controller\Frontend\Product\Standard.addFilterAttribute() is
called with the parameter

$oneIds = [
    designer => [ 1 ],
    manufacturer => [ 2 ]
]

This should mean that it filters for products which have both an attribute with ID 1 and one with ID 2.
The function addFilterAttribute indicates that by setting the condition as

index.attributeaggregate([1]) > 0 && index.attributeaggregate([2]) > 0

This behaviour doesn't exist anymore in 2017.10. The condition now becomes

index.attribute.id = [1] && index.attribute.id = [2]

This results in the following SQL (simplified, I stripped away everything from
the query that does not pertain to the problem):

SELECT DISTINCT mpro.`id`
  FROM `mshop_product` AS mpro
         LEFT JOIN `mshop_index_attribute` AS mindat USE INDEX (`idx_msindat_s_at_lt`, `unq_msindat_p_s_aid_lt`) ON mindat.`prodid` = mpro.`id`
 WHERE  ( mindat.`attrid` IN (2) AND mindat.`attrid` IN (1) )

This can never work: we're looking for an entry in mshop_index_attribute that
has both the attrid 2 and 1 at the same time. The SQL for the old
version 18.7.1 was:

SELECT DISTINCT mpro.`id`
  FROM `mshop_product` AS mpro
         LEFT JOIN `mshop_index_catalog` AS mindca USE INDEX (`idx_msindca_s_ca_lt_po`, `unq_msindca_p_s_cid_lt_po`) ON mindca.`prodid` = mpro.`id`
 WHERE ( mpro.`siteid` IN (1) AND
        ( ( SELECT COUNT(DISTINCT mindat_agg.`attrid`)
              FROM `mshop_index_attribute` AS mindat_agg
             WHERE mpro.`id` = mindat_agg.`prodid`
               AND mindat_agg.`attrid` IN ( 1 ) ) > 0 AND
               ( ( SELECT COUNT(DISTINCT mindat_agg.`attrid`)
                     FROM `mshop_index_attribute` AS mindat_agg
                    WHERE mpro.`id` = mindat_agg.`prodid`
                      AND mindat_agg.`attrid` IN ( 2 ) ) > 0 ) ) )

Is it possible to get the old behaviour in the new version, i.e. did we not notice some breaking change in the API and we should be calling the controller differently now? So far, we just set the f_oneId-parameter like this: ?ai[f_oneid][manufacturer][0]=2&ai[f_oneid][designer][0]=1.

Hi,

various servers don't have the corresponding PECL module installed for ImageMagick / GraphicMagick.
However, in those cases the binaries are most often still available which is why it would be nice to support GraphicMagick / ImageMagick using those binaries like TYPO3 does.
Not "necessary" but it would be a nice addition.

Version is from git, revision 7a3c80f27a00d779476222f6a480a03bbbbc51ec, with Aimeos running in TYPO3 8.7.8.

When editing the sites in JQAdm → Locale → Sites, deleting the default site results in:

No item found for conditions: Array ( [locale.site.code] => default )

Aimeos\MShop\Exception thrown in file
[…] vendor/aimeos/aimeos-core/lib/mshoplib/src/MShop/Common/Manager/Base.php in line 562.

This state can't be recovered from through the backend (as far as I know.) Inserting the corresponding row into the db results in a usable installation again:

insert into mshop_locale_site VALUES (1,0,'default','Default','[]',0,1,2,1,NOW(),NOW(),'USER');

Where USER is any valid user name. However, the editor field doesn't have a foreign key constraint, which means you can just input anything there 🙂

I propose guarding against removal of the default site, perhaps throwing an error when the user attempts to remove or rename it.

In object \Aimeos\MW\View\Standart, method resolve has problem.

line 242:
if( strncmp( $file, '/', 1 ) === 0 && is_file( $file ) ) {

must be

if( strncmp( $file, '/', 1 ) === 0 || is_file( $file ) ) {

How can a running webshop (17.2.1) end up with this error:

Product with array key "0" not available

The basket is empty.
This occurs after the webshop admin tried unsuccessfully to add a coupon code.
`
I requested a backup of the system, so there is no way to explore this into depth.
I have reinstalled the complete webshop and the issue remains.

But can you think of a scenario that casues this?

Hi everyone.

Aimeos may not combine tier price products in the basket.

How to reproduce:
1.) Create a simple tier price product without any options.
2.) Tier price should look like this: 100 € normal price, 50€ for more then 10.
3.) The customer adds 5 products to his basket, for 100€ each.
4.) Then the customer adds 11 products for 50€ each.

You then have two positions of the same product in the basket with 5 x 100€ and 11 x 50€.
Ideally it should combine both amounts together, resulting in 16 x 50€.

When adding a 5 products, and then adding 6 products, everything works as expected.
You get 11 x 50€ in the basket.

Tobi

I have now finished a payment provider for PayUnity & PayUnity.Flex
Due to PayUnity.Flex using JavaScript forms I decided against omnipay as I also have to modify output in aimeos to support this.

Features that are not in it and I probably won't add as we don't need them are:
option to store payment data on PayUnity server.
Notifications from PayUnity to payment provider.
And also the other way around, e.g. refund to PayUnity from shop system.

I will first have the provider used in our own system for a few weeks to see if everything behaves correctly,
Afterwards I think I will probably make it public.

However, I think adding it to ai-payments or aimeos-core itself might also be a good idea but I don't currently have the time to create the corresponding unittests I would like for that to have first,

So maybe you would be willing to add those and improve the provider accordingly for aimeos-core / ai-payunity code?

initially created in aimeos/ai-client-html#35 and a pull request set forth to aimeos/ai-typo3#5

Turned out to be a more global issue, thus now in aimeos-core.

May be valid only for TYPO3 < 8 as @worlddevelopment still is on T3 7.x.

Platform: Typo3

Hi all,

while investigating the poor image quality on rescaled product images i found myself unable to manipulate the Imagick quality settings described here: https://aimeos.org/docs/Configuration/Core/controller/common/media/standard/options

Firstly, I guess the correct value for the quality should be set in ['image']['quality'] = 100 and not in ['image']['jpeg']['quality'] = 100.

The other problem seems to be in Resources/Libraries/aimeos/aimeos-core/lib/mwlib/src/MW/Media/Image/Imagick.php:78 where the quality parameter is passed to $this->image->setImageCompression() instead of $this->image->setImageCompressionQuality().

I fixed this locally on my machine and it works, so could maybe anybody verify this and insert it into the official build?

Thank you for developing and maintaining this great project!
Nils

EDIT: fixed a mistake ("name" instead of "jpeg" in 2nd paragraph)

Adding an SVG to a delivery service results in the following error:

The image type isn't supported by GDlib., [path to project removed]\vendor\aimeos\aimeos-core\lib\mwlib\src\MW\Media\Image\Standard.php:44

Vector graphics should be supported.

Hi

Typo3: 8.7.24
Aimeos: 2019.04.3 was 2018.10.15

I'm trying to upgrade from 2018.10 to 2019.04. Even after executing the setup script all my images, texts, ... assigned to products do not have a type assigned. I would guess this should have been done through migrations in \Aimeos\MW\Setup\Task\TypesMigrateColumns.

As an example lets take "db-media". All my entries in the table "mshop_media" do have a valid "typeid" but they all have "" as "type". Is there a reason there are no entries for the table "mshop_media", "mshop_text", ... in \Aimeos\MW\Setup\Task\TypesMigrateColumns->$migrations?

I would have expected an entry like the following:

'mshop_media' => 'UPDATE "mshop_media" SET "type" = ( SELECT "code" FROM "mshop_media_type" AS t WHERE t."id" = "typeid" AND t."domain" = "domain" LIMIT 1 ) WHERE "type" IS NULL',

Furthermore is WHERE "type" IS NULL actually correct? My db schema for mshop_media_list does not allow type to be null therefore all entries start with value "".

When using the PropertyAdd plugin, it does not really work as I would expect it too.

Instead of adding the properties of a certain type that one specifies in the plugin options to the basket,

Only one property type can be "added" this way because:
\Aimeos\MShop\Plugin\Provider\Order\PropertyAdd::addAttributes
is defined,

Furthermore, instead of the property type - as shown in the example - it is necessary to use e.g. product.property.value which is also why it only works for one property correctly, as the exists already check fails afterwards.

Using: 2018.10.12
With TYPO3 integration.

Sorry I try to understand and read your document make me difficult to understand how is it going on
anyway I try to read code instead.
it is really hard to understand ur document now I'm trying to read code instead

Sorry I get stuck to create a client account

Hey there,

we have a case where a basket plugin manipulates a product's price under certain circumastances. This conflicts with the ProductPrice basket plugin, which checks for changed prices. I would like to introduce the flag \Aimeos\MShop\Order\Item\Base\Product\Base::FLAG_FIXEDPRICE and prevent the ProductPrice basket plugin from checking these products here: https://github.com/aimeos/aimeos-core/blob/master/lib/mshoplib/src/MShop/Plugin/Provider/Order/ProductPrice.php#L69

I would offer to make a PR if you merge it afterwards...?

Is there any particular reason for the private Base classes' attributes?

I am trying to overwrite createItemBase from Aimeos\MShop\Customer\Manager\Base to create an extended version of Customer's Item class.

protected function createItemBase( array $values = array(), array $listItems = array(), array $refItems = array() )
    {
        if( !isset( $this->addressManager ) ) {
            $this->addressManager = $this->getSubManager( 'address' );
        }

        $helper = $this->getPasswordHelper();
        $address = $this->addressManager->createItem();

        return new \Aimeos\MShop\Customer\Item\Standard( $address, $values, $listItems, $refItems, $this->salt, $helper );
    }

To create a new Item I'll need to access $this->salt, which is private.

Can we just change the visibility to protected? This way I would not need to "recalculate" the salt value in my extended class.

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

Hi, I'm trying to create a basket plugin but I keep getting the following error on the front end of the site:

Class "\Aimeos\MShop\Plugin\Provider\Order\ApproveOrder" not available

This is on version 2017.10

Steps:

1. Created my package np-approve_order using the Aimeos extension builder.
2. Followed the instructions at Implement basket plugins
3. Used the skeleton class from above link to create my plugin, which is now at
   /ext/np-approve-order/lib/custom/src/MShop/Plugin/Provider/Order/ApproveOrder.php
4. The class namespace is Aimeos\MShop\Plugin\Provider\Order (as per the skeleton class) and the classname is ApproveOrder.
5. The manifest.php contains the lib/custom/src folder in the includes array.

So far, so good. However, when I go the admin plugin page and I try to add the plugin, it isn't availble in the list of provider. The class also doesnt seem to be loaded by composer, even after composer dump-autoload and aimeos:cache.

I think I am missing a step or two somewhere, possible a service provider or something along those lines. Looking through the documentation for creating an extension, I don't see further instructions on how to register your extension.

I've tried looking at the other packages in the extension folder, but I couldnt find an answer there.

So basically, how do I register an extension and/or basket plugin?

I keep my request simple in this stage. And execution should choose the easiest solution, if it's a go.

Specifications

1. Download or send tickets to buyer. On the ticket, there is a QR code.
2. If a customer buys two or more tickets, he downloads that number of files with a unique QR code. So one file equals one ticket.

Remarks

• In simple cases, one download and one QR-code is enough, even for groups. If the request is complex to handle, perhaps start with this?
• A barcode for event organizers who only carry barcode reading equipment.
• Combined sales should be possible, at least in a later stage. For instance, a customer buys one book and one or more entrance tickets in one sale.

Towards a solution

• Now there is a download product already in Aimeos. Perhaps extend that? In general, customers expect PDF perhaps, but a printable mail will do (in the beginning at least).
• How to generate a QR-code per ticket, must be configurable. For instance [time + name + zipcode + housenr + country iso2 + ordernumber + ticketnumber].

I'm not a programmer, otherwise I should have created this already I think, as an extension. But it's a value adding feature for Aimeos, I think, it might fit into the core.

Hello Team of Aimeos,

Is it possible there is a bug in most implementations for isAvailable which checks the status? A text item marked as with status "archived" (-2) is still considered available. Shouldn't only items with status >= 1 be considered available?

The problem is the following code. Php only casts 0 to false, negative integers are considered true.

(bool) $this->getStatus()

There seems to be a bug/unintended change to how the quality of an image is calculated in \Aimeos\MW\Media\Image\Imagick. I suspect the change is from #f3e1eef4d44fef72fadb58dc6b4b5f50f51f5d89. As far as I can could test, \Imagick::setImageCompressionQuality() actually expects a quality instead of the inverse which \Imagick::setImageCompression() probably used.

You can easily test it with setting quality controller.common.media.standard.options.image.quality to 1 and set a product image. Then change it to 99 and add another image. For me the first image is ok while the second image has very poor quality. The default quality is 90.

Typo3 Version 8.7.24
Aimeos Version 2018.10.15

edit: I can supply a pull request changing $this->image->setImageCompressionQuality( 100 - $quality ); // inverse quality scheme to $this->image->setImageCompressionQuality( $quality );

there is any ETA for android and ios sdk for aimeos?
thanks

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.

Does exporting products in CSV format work? If so, using what configuration settings? It's not working for me. Here is my set-up:

In config/shop.php

...
  'controller' => array(
         'jobs' => array(
            'product' => array(
                'export' => array(
                    'location' => storage_path('export'),
                    'standard' => array(
                        'container' => array(
                            'type' => 'Directory',
                            'content' => 'CSV'
                        )
                    )
                )
            )
        )
    )
...

Then on the command line:

php artisan aimeos:jobs "product/export" -vvv

which gets me this:

Executing the Aimeos jobs for "default"


  [ErrorException]
  implode(): Invalid arguments passed


Exception trace:
 () at /home/dev/inuit-rebuild/inuit-web-rebuild/lar/vendor/aimeos/aimeos-core/lib/mwlib/src/MW/Container/Content/CSV.php:110
 Illuminate\Foundation\Bootstrap\HandleExceptions->handleError() at n/a:n/a
 implode() at /home/dev/inuit-rebuild/inuit-web-rebuild/lar/vendor/aimeos/aimeos-core/lib/mwlib/src/MW/Container/Content/CSV.php:110
 Aimeos\MW\Container\Content\CSV->add() at /home/dev/inuit-rebuild/inuit-web-rebuild/lar/vendor/aimeos/aimeos-core/controller/jobs/src/Controller/Jobs/Product/Export/Standard.php:228
 Aimeos\Controller\Jobs\Product\Export\Standard->createContent() at /home/dev/inuit-rebuild/inuit-web-rebuild/lar/vendor/aimeos/aimeos-core/controller/jobs/src/Controller/Jobs/Product/Export/Standard.php:298
 Aimeos\Controller\Jobs\Product\Export\Standard->export() at /home/dev/inuit-rebuild/inuit-web-rebuild/lar/vendor/aimeos/aimeos-core/controller/jobs/src/Controller/Jobs/Product/Export/Standard.php:54
 Aimeos\Controller\Jobs\Product\Export\Standard->run() at /home/dev/inuit-rebuild/inuit-web-rebuild/lar/vendor/aimeos/aimeos-laravel/src/Aimeos/Shop/Command/JobsCommand.php:60
 Aimeos\Shop\Command\JobsCommand->fire() at n/a:n/a
 call_user_func_array() at /home/dev/inuit-rebuild/inuit-web-rebuild/lar/vendor/laravel/framework/src/Illuminate/Container/Container.php:507
 Illuminate\Container\Container->call() at /home/dev/inuit-rebuild/inuit-web-rebuild/lar/vendor/laravel/framework/src/Illuminate/Console/Command.php:169
 Illuminate\Console\Command->execute() at /home/dev/inuit-rebuild/inuit-web-rebuild/lar/vendor/symfony/console/Command/Command.php:256
 Symfony\Component\Console\Command\Command->run() at /home/dev/inuit-rebuild/inuit-web-rebuild/lar/vendor/laravel/framework/src/Illuminate/Console/Command.php:155
 Illuminate\Console\Command->run() at /home/dev/inuit-rebuild/inuit-web-rebuild/lar/vendor/symfony/console/Application.php:791
 Symfony\Component\Console\Application->doRunCommand() at /home/dev/inuit-rebuild/inuit-web-rebuild/lar/vendor/symfony/console/Application.php:186
 Symfony\Component\Console\Application->doRun() at /home/dev/inuit-rebuild/inuit-web-rebuild/lar/vendor/symfony/console/Application.php:117
 Symfony\Component\Console\Application->run() at /home/dev/inuit-rebuild/inuit-web-rebuild/lar/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php:107
 Illuminate\Foundation\Console\Kernel->handle() at /home/dev/inuit-rebuild/inuit-web-rebuild/lar/artisan:36

After a little digging, I see this is because of the following lines in aimeos-core/controller/jobs/src/Controller/Jobs/Product/Export/Standard.php:

// in the method createContent()
        $content->add( $view->render( $view->config( $tplconf, $default ) ) );

// in the method addItems()
        $content->add( $view->render( $view->config( $tplconf, $default ) ) );

// in the method closeContent()
        $content->add( $view->render( $view->config( $tplconf, $default ) ) );

In all three cases $content is an instance of Aimeos\MW\Container\Content\CSV and $content->add() expects an array of data.
I know I can configure my own templates, but $view->render() always returns a string. These lines fail when $content is an instance of CSV.

I suspect that the CSV content object should actually be a subclass of View that formats csv data. Then that data can be written to the file using the default Binary content object.

https://aimeos.org/docs/Configuration/Core/mshop/price shows already a related global setting:

• mshop/price/taxflag Configuration setting if prices are [defined] inclusive or exclusive tax

It would be nice to have these new options:

If "Kleinunternehmen"

• mshop/price/tax/exclude Whether tax is excluded or included (default) in summaries, invoice, ... (effectively toggling e.g. German "Kleinunternehmerregelung" but useful for other countries too)

Else more fine-grained tuning if not "Kleinunternehmen", i.e. sales > 17 500 € / year:

• mshop/price/tax/excude_if_foreign_company_but_within_free_trade_zone Configuration setting whether prices are inclusive or exclusive tax if customer.company != '' && customer.country != shop.legal_address.country && customer.country in shop.legal_address.free_trade_zone && is_valid(customer.company_tax_number)
  For checking if a tax number is valid, we could use this site if free_trade_zone == EU:
  http://ec.europa.eu/taxation_customs/vies/?locale=de

Never show tax for companies from foreign countries:

A config setting mshop/price/tax/excude_if_outside_free_trade_zone is superfluous here because a foreign company needs not pay this tax in foreign countries. It must pay it in its own country.

I have installed a demo neos2.0.3version+ aimeos; when i try to create tables and to add the demo data

./flow aimeos:setup --option=setup/default/demo:1

It show this message:
PHP Fatal error: Class '\MW\Setup\Task\MShopAddLocaleData' not found in /public_html/test/Neos-2.0/Packages/Libraries/aimeos/aimeos-core/lib/mshoplib/setup/MShopAddLocaleLangCurData.php on line 16

When I am adding product into basket, I get following error:

    "message": "Call to undefined method Aimeos\\MShop\\Supplier\\Item\\Standard::getType()",
    "exception": "Symfony\\Component\\Debug\\Exception\\FatalThrowableError",
    "file": "/Applications/MAMP/www/damito/vendor/aimeos/aimeos-core/lib/mshoplib/src/MShop/Common/Item/ListRef/Base.php",
    "line": 225,

Method getType in Supplier\Item\Standard is indeed missing. When I add it, it works correctly.

I am on 2018.07.x-dev

Another one: I currently have 2 problems using the "Supplier" provider for pickup delivery.

1. when I add multiple addresses to a supplier (BE), the user can't choose between them - this is bad if you have a supplier with multiple warehouses
2. the user will not be able to pickup his order because there is no ways for him to find out the actual pickup address! Even worse: the summary page and the email only display the internal supplier code, like "demo-1".

So I started working on the decorator to fix these issues and provide more functionality, but I need a way to inject another string attribute during the process, which then will be displayed at the checkout page/email template. What is the best way to achieve this?

Using 17.2.1.

In the demo shop it goes wrong with coupons. You can add a coupon (e.g. "percent") but hitting the cross to remove does not work on http://typo3.demo.aimeos.org/demo/detail/d/1/Demo_article/0/

I had a similar setup, but needed to change it because of this. But now I don't get any further than making a coupon product like this:

• a normal product, type Article, with code "hithere123"
• creating a Coupon with provider "PercentRebate", give it percentrebate.rebate = 50 and percentrebate.productcode = "hithere123", setting Code under tab Codes to "hithere123"
• then have to hide it from catalog list with CSS

This is not the way it should be.

But there is no clear documentation.
I have no other configuration working, but again, it's not working on your demo either.

Hallo Norbert
/lib/mwlib/src/MW/DB/Manager/PDO.php

Es gibt ein Problem:

• In den tests ein "SET @@session.wait_timeout = 1" setzen und dann zwei Sekunden warten bevor ein test startet. Und dann werden vermutlich die Probleme klar.
  Der Pool an Verbindungen funktioniert nur solange die default "wait_timeout" nicht greift.
  Beispiel: Ein was auch immer z.B. "Job" Domain Import Prozess dauert über 10min (default wait_timeout in mysql/mariadb) wo keine DB Verbindung benötigt wird und dann soll ein Item gespeichert werden. PDO muss noch loser oder singleton werden :(

I recently downloaded this erm from aimeos docs, but is not the same i have in my installation

• typo3 7.6.9
• aimeos 16.4.3
• aimeos_dist 16.4.0

If you get the ProductPrice changes message on the summary page, another submit just displays the error again but nothing further happens.
First encountered this in combination with ai-customergroups extension.

Going back to the basket and re-sbumitting restarting the checkout process, however, works correctly.

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?

Is there a reason why the namespace for local decorators for managers does not start with "Aimeos" or is this an oversight?

Global:

Hi @aimeos team,

I just updated to 2019.1 and it kind of broke everything. Now I'm trying to fix all the "bugs" one by one, which is mildly annoying. I strongly suggest to try to avoid breaking changes and use some kind of "deprecation warnings" (e.g. in wrappers around the new function) for a few versions before ultimately removing or renaming functions. The way it goes atm is very bad in production usage IMO.

However, I can't figure out the problem which produces error 050 and logs like those:

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'mpro.type' in 'field list'
and a stracktrace like:

#0 /var/customers/webs/xxxxx/vendor/aimeos/aimeos-core/lib/mshoplib/src/MShop/Common/Manager/Base.php(377): Aimeos\MW\DB\Statement\DBAL\Simple->execute()
#1 /var/customers/webs/xxxxx/vendor/aimeos/aimeos-core/lib/mshoplib/src/MShop/Common/Manager/Base.php(774): Aimeos\MShop\Common\Manager\Base->getSearchResults(Object(Aimeos\MW\DB\Connection\DBAL), '\n\t\t\t\t\tSELECT mp...')
#2 /var/customers/webs/xxxxx/vendor/aimeos/aimeos-core/lib/mshoplib/src/MShop/Product/Manager/Standard.php(741): Aimeos\MShop\Common\Manager\Base->searchItemsBase(Object(Aimeos\MW\DB\Connection\DBAL), Object(Aimeos\MW\Criteria\SQL), 'mshop/product/m...', 'mshop/product/m...', Array, NULL, 3)
#3 /var/customers/webs/xxxxx/vendor/aimeos/aimeos-core/lib/mshoplib/src/MShop/Common/Manager/Decorator/Depth.php(43): Aimeos\MShop\Product\Manager\Standard->searchItems(Object(Aimeos\MW\Criteria\SQL), Array, NULL)
#4 /var/customers/webs/xxxxx/vendor/aimeos/aimeos-core/lib/mshoplib/src/MShop/Index/Manager/DBBase.php(358): Aimeos\MShop\Common\Manager\Decorator\Depth->searchItems(Object(Aimeos\MW\Criteria\SQL), Array)
#5 /var/customers/webs/xxxxx/vendor/aimeos/aimeos-core/lib/mshoplib/src/MShop/Index/Manager/Standard.php(498): Aimeos\MShop\Index\Manager\DBBase->searchItemsIndexBase(Object(Aimeos\MW\Criteria\SQL), Array, 53, 'mshop/index/man...', 'mshop/index/man...')
#6 /var/customers/webs/xxxxx/vendor/aimeos/aimeos-core/lib/mshoplib/src/MShop/Common/Manager/Decorator/Depth.php(43): Aimeos\MShop\Index\Manager\Standard->searchItems(Object(Aimeos\MW\Criteria\SQL), Array, 53)
#7 /var/customers/webs/xxxxx/ext/ai-controller-frontend/controller/frontend/src/Controller/Frontend/Product/Standard.php(349): Aimeos\MShop\Common\Manager\Decorator\Depth->searchItems(Object(Aimeos\MW\Criteria\SQL), Array, 53)
#8 /var/customers/webs/xxxxx/ext/ai-client-html/client/html/src/Client/Html/Catalog/Base.php(618): Aimeos\Controller\Frontend\Product\Standard->searchItems(Object(Aimeos\MW\Criteria\SQL), Array, 53)
#9 /var/customers/webs/xxxxx/ext/ai-client-html/client/html/src/Client/Html/Catalog/Base.php(206): Aimeos\Client\Html\Catalog\Base->searchProducts(Object(Aimeos\MW\View\Standard))
#10 /var/customers/webs/xxxxx/ext/ai-client-html/client/html/src/Client/Html/Catalog/Lists/Standard.php(464): Aimeos\Client\Html\Catalog\Base->getProductList(Object(Aimeos\MW\View\Standard))
#11 /var/customers/webs/xxxxx/ext/ai-client-html/client/html/src/Client/Html/Catalog/Lists/Standard.php(171): Aimeos\Client\Html\Catalog\Lists\Standard->addData(Object(Aimeos\MW\View\Standard), Array, NULL)
#12 /var/customers/webs/xxxxx/htdocs/typo3conf/ext/aimeos/Classes/Controller/AbstractController.php(157): Aimeos\Client\Html\Catalog\Lists\Standard->getBody()
#13 /var/customers/webs/xxxxx/htdocs/typo3conf/ext/aimeos/Classes/Controller/CatalogController.php(70): Aimeos\Aimeos\Controller\AbstractController->getClientOutput(Object(Aimeos\Client\Html\Catalog\Lists\Standard))
#14 [internal function]: Aimeos\Aimeos\Controller\CatalogController->listAction()
#15 /var/customers/webs/xxxxx/vendor/typo3/cms/typo3/sysext/extbase/Classes/Mvc/Controller/ActionController.php(316): call_user_func_array(Array, Array)
#16 /var/customers/webs/xxxxx/vendor/typo3/cms/typo3/sysext/extbase/Classes/Mvc/Controller/ActionController.php(176): TYPO3\CMS\Extbase\Mvc\Controller\ActionController->callActionMethod()
#17 /var/customers/webs/xxxxx/vendor/typo3/cms/typo3/sysext/extbase/Classes/Mvc/Dispatcher.php(85): TYPO3\CMS\Extbase\Mvc\Controller\ActionController->processRequest(Object(TYPO3\CMS\Extbase\Mvc\Web\Request), Object(TYPO3\CMS\Extbase\Mvc\Web\Response))
#18 /var/customers/webs/xxxxx/vendor/typo3/cms/typo3/sysext/extbase/Classes/Mvc/Web/FrontendRequestHandler.php(91): TYPO3\CMS\Extbase\Mvc\Dispatcher->dispatch(Object(TYPO3\CMS\Extbase\Mvc\Web\Request), Object(TYPO3\CMS\Extbase\Mvc\Web\Response))
#19 /var/customers/webs/xxxxx/vendor/typo3/cms/typo3/sysext/extbase/Classes/Core/Bootstrap.php(199): TYPO3\CMS\Extbase\Mvc\Web\FrontendRequestHandler->handleRequest()
#20 /var/customers/webs/xxxxx/vendor/typo3/cms/typo3/sysext/extbase/Classes/Core/Bootstrap.php(186): TYPO3\CMS\Extbase\Core\Bootstrap->handleRequest()
#21 [internal function]: TYPO3\CMS\Extbase\Core\Bootstrap->run('', Array)
#22 /var/customers/webs/xxxxx/vendor/typo3/cms/typo3/sysext/frontend/Classes/ContentObject/ContentObjectRenderer.php(6341): call_user_func_array(Array, Array)
#23 /var/customers/webs/xxxxx/vendor/typo3/cms/typo3/sysext/frontend/Classes/ContentObject/UserContentObject.php(41): TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->callUserFunction('TYPO3\\CMS\\Extba...', Array, '')
#24 /var/customers/webs/xxxxx/vendor/typo3/cms/typo3/sysext/frontend/Classes/ContentObject/ContentObjectRenderer.php(820): TYPO3\CMS\Frontend\ContentObject\UserContentObject->render(Array)
#25 /var/customers/webs/xxxxx/vendor/typo3/cms/typo3/sysext/frontend/Classes/ContentObject/ContentObjectRenderer.php(736): TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->render(Object(TYPO3\CMS\Frontend\ContentObject\UserContentObject), Array)
#26 /var/customers/webs/xxxxx/vendor/typo3/cms/typo3/sysext/frontend/Classes/Controller/TypoScriptFrontendController.php(3538): TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->cObjGetSingle('USER', Array)
#27 /var/customers/webs/xxxxx/vendor/typo3/cms/typo3/sysext/frontend/Classes/Controller/TypoScriptFrontendController.php(3500): TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->INTincScript_process(Array)
#28 /var/customers/webs/xxxxx/vendor/typo3/cms/typo3/sysext/frontend/Classes/Controller/TypoScriptFrontendController.php(3467): TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->recursivelyReplaceIntPlaceholdersInContent()
#29 /var/customers/webs/xxxxx/vendor/typo3/cms/typo3/sysext/frontend/Classes/Http/RequestHandler.php(226): TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->INTincScript()
#30 /var/customers/webs/xxxxx/vendor/typo3/cms/typo3/sysext/core/Classes/Core/Bootstrap.php(319): TYPO3\CMS\Frontend\Http\RequestHandler->handleRequest(Object(TYPO3\CMS\Core\Http\ServerRequest))
#31 /var/customers/webs/xxxxx/vendor/typo3/cms/typo3/sysext/frontend/Classes/Http/Application.php(79): TYPO3\CMS\Core\Core\Bootstrap->handleRequest(Object(TYPO3\CMS\Core\Http\ServerRequest))
#32 /var/customers/webs/xxxxx/vendor/typo3/cms/typo3/sysext/frontend/Resources/Private/Php/frontend.php(23): TYPO3\CMS\Frontend\Http\Application->run()
#33 /var/customers/webs/xxxxx/vendor/typo3/cms/typo3/sysext/frontend/Resources/Private/Php/frontend.php(24): {closure}()
#34 /var/customers/webs/xxxxx/vendor/typo3/cms/index.php(3): require('/var/customers/...')
#35 {main}

Can you please help my track this down?

In getI18nList the retrieved files by the \DirectoryIterator class are ordered by using ksort at the end, see:
https://github.com/aimeos/aimeos-core/blob/master/Bootstrap.php#L242

However, the same is not done for getManifests:

a simple ksort($manifests) before the return statement should fix this.

Without this change the manifests can be returned in basically random order as it depends on the file sytem.

Which might result in Javascript dependencies being loaded wrong (or other issues in that regard), e.g. I currently have a loading issue here in combination with ai-customergroups. It is currently loaded before ai-admin-extadm which results in missing Javascript code.
Of course, if ai-customergroups would make the ai-admin-extadm a dependency this wouldn't be an issue either but still loading it in alphabetical order would be best.

The bug is in 2016 and 2017.

Friends for whom I host websites decided against Aimeos and for Gambio due to the following reasons:

• Graphs at start page.
• Inclusion of financial book keeping functionality like e.g.
  • Delivery note,
  • Invoice generation,
  • Tax handling,
• German law conformity (like Kleinunternehmerregelung)
  This list is incomplete and it was what I figured out of comparing what convinced them of Gambio. Actually many of the things they liked so much about Gambio Aimeos also supports out of the box. Yet they always found other reasons. And the list is what it bolted down to as far as I could assemble quickly now.

Gambio forces a support contract

The forced support contract of 1 year costing 150 € (at time of writing) did not stop their conviction of Gambio.

Aimeos source code easy to find, contribute, while Gambio source code difficult to find.

Finding Gambio up to date/development source code turns out to be complicated. This implies that edge updates and development for hotfixes et alia are much more difficult than in Aimeos.

Open source prejudice

Also they thought "due to the price" Gambio must be commercial and they think open source is inferior because I already made them use FreeCAD. Poor FreeCAD, poor Aimeos whose major advantage seems its tight integration with so many content management systems.
I will later today tell them about the Content Management System integration of Aimeos and that Gambio is open source too. So that both (and not only Aimeos) are "minor" following their terms. Strange world - only few know the true powers of open source.

Idea: Conversion factor automation

"Als Basis wird im Shop eine Standardwährung bestimmt, für jede weitere Währung wird dann lediglich noch der Umrechnungskurs hinterlegt." [Gambio Features Auflistung]
If we were to code this in Aimeos using a parser - we might reduce the manual updating of the conversion factors.

Aimeos development contribution outlook

If they had decided for Aimeos, then I might have been in the position to develop missing features, while now I have to get into Gambio internals instead ...
I will compare carefully and try to iron out issues in Aimeos that I think are handled great in Gambio. Note I'm just a part time hobby developer and the hosting I do for friends and not commercially, world development, engineering and open farming is taking most resources.

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

I am not sure if this is ai-typo3 or aimeos-core but when adding a product to the basket, the quantity in the label itself is updated but the details are not, they require a page reload, this can be testet here:
http://typo3.demo.aimeos.org/performance

I think the click on the arrow should instead of just opening the information do an ajax request which provides the infromation / html.

I am not sure why but trying to access other classes if the have been included with "use" doesn't work during syncUpdate of a Payment provider.
It seems to work fine otherwise though.
I am not even sure it works all the time with the fully qualified classname there.
Probably somehow related to how the updateSync method is called?

The HTML files below client/html are php files so syntax coloring is not correct.

Would it be possible to rename theses files?

Regards
Stephan

Problem: if you apply a coupon, the rebate amount keeps immutable even if you delete or add new products to basket.

Steps to reproduce:

1. Add a product to the cart
2. Apply a coupon code (i.e: percent rebate)
   3.a. Modify the quantity of items and/or
   3.b. Add a new product to the cart and/or
   3.c. Remove a product from basket

Current behaviour: rebate amount keeps the same

Expected behaviour: rebate amount must be recalculated every time something changes in the basket (i think it does not only affects to product changes but everything that could impact coupons conditions)

e.g. in the text editor of expert mode tables are allowed, but destroyed if one saved the product in easy mode