Five Bugs

[kledo-34]

Hey,

I've set up a shop with the current aimeos extension 19.10.4 and typo 3 9.5.11.
I checked through the features and encountered a couple of bugs. If I just don't understand how things should work, I'm sorry for that.
But here we go.

1. duplicate canonical url metatag:
Aimeos generates an own correct canonical url metatag on the detail page which is great, but it doesn't replace the canonical metatag set by typo3 (or depending of your setup also yoast_seo, etc.). This leads to duplicate canonical tag with different urls which simply is bad SEO and leads to ranking penalties.

2. url_segment error on language switch:
(I just read https://aimeos.org/help/help-f15/sitemap-urls-with-url-segment-t2694.html#p10701 and agree with this behaviour, invalid url_segment links for different languages and catalog sitemap error). In addition this error also happens if you are in the details view of a product with different url_segments for different languages and you change the language, it doesn't find the product, because it tries to find the old url_segment in the new language.

3. Aimeos List Route enhancer breaks sorting grid/ list and relevance/recent/name/price:
(As already mentioned by happy-coding under a different topic here https://aimeos.org/help/help-f15/scheduler-problem-t2531.html#p10569) With the route enhancer the url is beautiful, but the sorting doesn't work anymore, without the List Route Enhancer the parameters and sorting works. More specific if I delete those lines of the Aimeos List Route Enhancer
routePath: /
_controller: 'Catalog::list'
only a part of the url is beautiful, but the sorting works, so those lines break the sorting for me.

4. aimeos advanced scheduler task - Jobs: Product notification e-mails Error:
This throws the following error for me, not sure if there is something wrong with my database I'll check this again closer, but I already ran the aimeos update script again.
Execution of task "Aimeos Shop advanced scheduler (aimeos)" failed with the following message: SQLSTATE[42S22]: Column not found: 1054 Unknown column 't3feuli.siteid' in 'where clause': SELECT DISTINCT t3feu."uid" AS "customer.id", t3feu."siteid" AS "customer.siteid", t3feu."name" AS "customer.label", t3feu."gender", t3feu."username" AS "customer.code", t3feu."title" AS "customer.title", t3feu."company" AS "customer.company", t3feu."vatid" AS "customer.vatid", t3feu."first_name" AS "customer.firstname", t3feu."last_name" AS "customer.lastname", t3feu."address" AS "customer.address1", t3feu."zip" AS "customer.postal", t3feu."city" AS "customer.city", t3feu."zone" AS "customer.state", tsc."cn_iso_2" AS "customer.countryid", t3feu."language" AS "customer.languageid", t3feu."telephone" AS "customer.telephone", t3feu."email" AS "customer.email", t3feu."fax" AS "customer.telefax", t3feu."www" AS "customer.website", t3feu."longitude" AS "customer.longitude", t3feu."latitude" AS "customer.latitude", t3feu."password" AS "customer.password", t3feu."date_of_birth", t3feu."usergroup" as "groups", t3feu."pid" AS "typo3.pageid", t3feu."disable", t3feu."crdate", t3feu."tstamp" FROM "fe_users" as t3feu LEFT JOIN "static_countries" AS tsc ON t3feu."static_info_country" = tsc."cn_iso_3" WHERE ( ( t3feu."language" = 'en' AND t3feuli."siteid" IN ('1') AND (t3feuli."key" LIKE 'product|watch|%' ESCAPE '#') AND t3feuli."id" IS NOT NULL AND t3feu."disable" = 0 ) ) AND t3feu."deleted" = 0 ORDER BY t3feu."uid" ASC LIMIT 100 OFFSET 0

5. No Bug, rather a feature: Integration with Typo3 language configuration and menu.
At the moment the shop has it's own language logic which is a great thing, but at some point it seems like it would be more comfortable if you could simply use the language menu created with typo3 and the url entry point for the languages. In fact using aimeos on a page translation doesn't work, probably also because translated pages have an own id, etc. However there are things that aimeos doesn't handle with it's language switch like the the global (again SEO), the main site menu language which therefor has to stay the same for all aimeos shop languages etc. I don't know how hard or complex it is to switch to that, but I think using the core functionality as far as possible provides an easier and richer experience in the long term. (I might be wrong ;) )

Maybe some of that makes it into the next update, looking forward to that :)

[aimeos]

1. duplicate canonical url metatag:
Aimeos generates an own correct canonical url metatag on the detail page which is great, but it doesn't replace the canonical metatag set by typo3 (or depending of your setup also yoast_seo, etc.). This leads to duplicate canonical tag with different urls which simply is bad SEO and leads to ranking penalties.

Aimeos is unable to replace any meta tags added by other extensions before or afterwards to the head section. Please make sure no other extension adds meta tags for the catalog list and catalog detail page.

[aimeos]

3. Aimeos List Route enhancer breaks sorting grid/ list and relevance/recent/name/price:
(As already mentioned by happy-coding under a different topic here https://aimeos.org/help/help-f15/scheduler-problem-t2531.html#p10569) With the route enhancer the url is beautiful, but the sorting doesn't work anymore, without the List Route Enhancer the parameters and sorting works. More specific if I delete those lines of the Aimeos List Route Enhancer
routePath: /
_controller: 'Catalog::list'
only a part of the url is beautiful, but the sorting works, so those lines break the sorting for me.

We are still looking for the best routes enhancer configuration. Can you try these rules instead?
https://aimeos.org/help/post9835.html?hilit=routePath#p9835

[aimeos]

5. No Bug, rather a feature: Integration with Typo3 language configuration and menu.
At the moment the shop has it's own language logic which is a great thing, but at some point it seems like it would be more comfortable if you could simply use the language menu created with typo3 and the url entry point for the languages. In fact using aimeos on a page translation doesn't work, probably also because translated pages have an own id, etc. However there are things that aimeos doesn't handle with it's language switch like the the global (again SEO), the main site menu language which therefor has to stay the same for all aimeos shop languages etc. I don't know how hard or complex it is to switch to that, but I think using the core functionality as far as possible provides an easier and richer experience in the long term. (I might be wrong ;) )

If you've set config.language in TS, Aimeos uses this TYPO3 setting:
https://github.com/aimeos/aimeos-typo3/blob/master/Classes/Base/Locale.php#L53

[kledo-34]

1. duplicate canonical url metatag:
Aimeos generates an own correct canonical url metatag on the detail page which is great, but it doesn't replace the canonical metatag set by typo3 (or depending of your setup also yoast_seo, etc.). This leads to duplicate canonical tag with different urls which simply is bad SEO and leads to ranking penalties.

Aimeos is unable to replace any meta tags added by other extensions before or afterwards to the head section. Please make sure no other extension adds meta tags for the catalog list and catalog detail page.

I have a clean Typo3 installation only aimeos as third party extension. the second canonical clearly comes from 'seo', the sysext of typo3. If I deactivate the plugin the second metatag disappears, if I change value in page setting seo tab, canonical url, the metatag changes. Deactivating the sysext seo for my whole site is not an option to me. If you know a typoscript setup to prevent the sysext seo from rendering the canonical url for one page only, I would be really happy, but as far as I know this is not possible. But I read it's possible to replace the canonical. I mentioned yoast_seo, because I think they override it, but I don't have that installed at the moment.
https://forge.typo3.org/issues/88242
https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ApiOverview/MetaTagApi/Index.html

[aimeos]

https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ApiOverview/MetaTagApi/Index.html

OK, we will use the new MetaTag API in the next version. Probably also backported to 2019.10

[kledo-34]

3. Aimeos List Route enhancer breaks sorting grid/ list and relevance/recent/name/price:
(As already mentioned by happy-coding under a different topic here https://aimeos.org/help/help-f15/scheduler-problem-t2531.html#p10569) With the route enhancer the url is beautiful, but the sorting doesn't work anymore, without the List Route Enhancer the parameters and sorting works. More specific if I delete those lines of the Aimeos List Route Enhancer
routePath: /
_controller: 'Catalog::list'
only a part of the url is beautiful, but the sorting works, so those lines break the sorting for me.

We are still looking for the best routes enhancer configuration. Can you try these rules instead?
https://aimeos.org/help/post9835.html?hilit=routePath#p9835

Yeah, very great, I didn't read that conversation. I don't want to give a complete result because I need more time to test this, but all first test show great results. The sorting works, the rest aswell and on the fly the catalog sitemap urls are now also beautifully rewritten. For the catalog sitemap of course the error still remains when using url_segments for the category, same as the product sitemap.
By the way the sitemaps both show the same mistake now, but category page and product detail page links from the list view show different behaviour.
For the product links as I wrote earlier, the links become invalid, when not passing the current language parameters.
In the categories links the language parameters are always kept within the url, so in some rare scenarios I got the wrong url_segment, but due to the url parameters the page content was shown in correct language (in short url_segment can be different language than content language, but due to the language parameters the correct content is found and renders, maybe helpful regarding the product links) ;)

[kledo-34]

5. No Bug, rather a feature: Integration with Typo3 language configuration and menu.
At the moment the shop has it's own language logic which is a great thing, but at some point it seems like it would be more comfortable if you could simply use the language menu created with typo3 and the url entry point for the languages. In fact using aimeos on a page translation doesn't work, probably also because translated pages have an own id, etc. However there are things that aimeos doesn't handle with it's language switch like the the global (again SEO), the main site menu language which therefor has to stay the same for all aimeos shop languages etc. I don't know how hard or complex it is to switch to that, but I think using the core functionality as far as possible provides an easier and richer experience in the long term. (I might be wrong ;) )

If you've set config.language in TS, Aimeos uses this TYPO3 setting:
https://github.com/aimeos/aimeos-typo3/blob/master/Classes/Base/Locale.php#L53

You are completely right, sorry for reporting that, I only had the configuration for the default language, for all other languages until now the site config was enough so I didn't check that, but your solution indeed works well.

[aimeos]

You are completely right, sorry for reporting that, I only had the configuration for the default language, for all other languages until now the site config was enough so I didn't check that, but your solution indeed works well.

Do you know how to get the language from the current site configuration? Maybe the new SiteFinder class may help

[kledo-34]

Yes, as far as I know the Site Finder class is the most up to date method, getSiteByPageId() is one of the easiest solutions for most things.

[kledo-34]

4. aimeos advanced scheduler task - Jobs: Product notification e-mails Error:
This throws the following error for me, not sure if there is something wrong with my database I'll check this again closer, but I already ran the aimeos update script again.
Execution of task "Aimeos Shop advanced scheduler (aimeos)" failed with the following message: SQLSTATE[42S22]: Column not found: 1054 Unknown column 't3feuli.siteid' in 'where clause': SELECT DISTINCT t3feu."uid" AS "customer.id", t3feu."siteid" AS "customer.siteid", t3feu."name" AS "customer.label", t3feu."gender", t3feu."username" AS "customer.code", t3feu."title" AS "customer.title", t3feu."company" AS "customer.company", t3feu."vatid" AS "customer.vatid", t3feu."first_name" AS "customer.firstname", t3feu."last_name" AS "customer.lastname", t3feu."address" AS "customer.address1", t3feu."zip" AS "customer.postal", t3feu."city" AS "customer.city", t3feu."zone" AS "customer.state", tsc."cn_iso_2" AS "customer.countryid", t3feu."language" AS "customer.languageid", t3feu."telephone" AS "customer.telephone", t3feu."email" AS "customer.email", t3feu."fax" AS "customer.telefax", t3feu."www" AS "customer.website", t3feu."longitude" AS "customer.longitude", t3feu."latitude" AS "customer.latitude", t3feu."password" AS "customer.password", t3feu."date_of_birth", t3feu."usergroup" as "groups", t3feu."pid" AS "typo3.pageid", t3feu."disable", t3feu."crdate", t3feu."tstamp" FROM "fe_users" as t3feu LEFT JOIN "static_countries" AS tsc ON t3feu."static_info_country" = tsc."cn_iso_3" WHERE ( ( t3feu."language" = 'en' AND t3feuli."siteid" IN ('1') AND (t3feuli."key" LIKE 'product|watch|%' ESCAPE '#') AND t3feuli."id" IS NOT NULL AND t3feu."disable" = 0 ) ) AND t3feu."deleted" = 0 ORDER BY t3feu."uid" ASC LIMIT 100 OFFSET 0

This was an Error in my databse, I fixed it, everything works as expected, not errors, sorry for reporting.

[kledo-34]

Wow, pretty cool, fast and productive, at least from my point of view. Now that 3 of my issues are solved and I know you have the sitemap/url_segment and canonical thing in mind, you can either close this issue or leave it open until an update with the actual changes comes. It's up to you, but for me things are solved so far. Thanks a lot ;)

[kledo-34]

One more thing about sitemap/url_segment that I noticed now. I wrote that the sitemap product and category links that do not match the default language are invalid, because they open up the shop in the wrong language and the segments can't be found in the wrong language. With the new configuration (config.language) I guess it should be enough if the urls are generated with the correct language entry point before the url_segment , then typo3 should recognize the correct language and from there also aimeos. (so I guess parameters are not necessarily needed)

[aimeos]

OK, we will use the new MetaTag API in the next version. Probably also backported to 2019.10

Done. The commit is d3b4c5f and it's also available in 2019.10.x-dev branch

[aimeos]

5. No Bug, rather a feature: Integration with Typo3 language configuration and menu.

Also done in commit 7ac5229 and already available in 2019.10.x-dev branch too

[kledo-34]

Wow, that's very cool, the metaTag API works great, no duplicate canonicals anymore ;)
I got one more question on the language feature, maybe I'm just looking at the wrong things now, but I can't get it. I setup the typo3 site, two language records on the Typo3 "Page" above the whole page tree. In the site configuration I set up german as first and english as second language with all flags labels, etc. I added the following code to the template setup of my root page:

config {
linkVars = L(int)
sys_language_uid = 0
language = de
locale_all = de_DE.UTF-8
htmlTag_setParams = lang="de" dir="ltr" class="no-js"
}
[globalVar = GP:L = 1]
config {
sys_language_uid = 1
language = en
locale_all = en_US.UTF-8
htmlTag_setParams = lang="en" dir="ltr" class="no-js"
}
[global]

The language uids match with the ids of the language records mentioned above. Now I added a new language (english) on all of the shop pages and "translated" all plugin elements on those pages, so they equally exist on the german and english page. I also have a "Aimeos Shop - Locale selector" plugin on each page to show me which language is activated in the shop. If I go to the frontend now and switch the language in the typo3 language menu that I have (generated with vhs viewhelper v:page.languagemenu). The wohle language of the site changes which means the url gets /en/ as an entry point to the english site, the header, menus and footer are translated and typo3 gets the translated version of the page, BUT the language of the shop, products and locale selector of the shop stays the same all the time, I have to switch this seperately with the aimeos locale selector to match the typo3 language. The only difference that came up with your change above is that the "default" language of the shop (the language that the shop initially uses on pageload is english, before/if I delete your changes it is german, but non of them change together with the main site language navigation.
The locale selector of the shop also doesn't change the page language navigation (but I didn't expect it to work that way).
On top of that using url segments for differen languages results in invalid urls, e.g. if I open a product in details view (lets say the products german url_segment is deprodukt and the english url_segment is enproduct) it opens first in english language with enproduct in the url, if I switch the shop language now on the dtails page (I have to do this with the locale selector plugin of aimeos, because the main language navigation doesn't change the shop language as explained above), aimeos now generates the url enproduct?ai__d_pos=3&ai__locale=de&ai__currency=EUR, and it says unable to find product. This is logic because the shop now tries to find the english url_segment within locale=de, instead the url should inlcude the german url_segment deprodukt to be searched in the locale=de.
Sorry for coming again with that, maybe I just don't understand the way this should work but here is how my version reacts.

This is on version 2019.10.x-dev branch of today

[aimeos]

Wow, that's very cool, the metaTag API works great, no duplicate canonicals anymore ;)

It's not the MetaTag API because there you can only change/remove tags. It's only possible to remove the canonical URL for all pages using this: https://github.com/aimeos/aimeos-typo3/blob/master/ext_localconf.php#L314

[aimeos]

I got one more question on the language feature, maybe I'm just looking at the wrong things now, but I can't get it. I setup the typo3 site, two language records on the Typo3 "Page" above the whole page tree. In the site configuration I set up german as first and english as second language with all flags labels, etc. I added the following code to the template setup of my root page:

config {
linkVars = L(int)
sys_language_uid = 0
language = de
locale_all = de_DE.UTF-8
htmlTag_setParams = lang="de" dir="ltr" class="no-js"
}
[globalVar = GP:L = 1]
config {
sys_language_uid = 1
language = en
locale_all = en_US.UTF-8
htmlTag_setParams = lang="en" dir="ltr" class="no-js"
}
[global]

The site configuration has precedence now over your TS configuration if you have a site configuration, so these lines won't have any effect if your setup.

Guess, these lines don't retrieve the actual language but the first language configured in the site configuration: https://github.com/aimeos/aimeos-typo3/blob/master/Classes/Base/Locale.php#L55-L58
Can you confirm that? If yes, how do we get the actual language?

[aimeos]

On top of that using url segments for differen languages results in invalid urls, e.g. if I open a product in details view (lets say the products german url_segment is deprodukt and the english url_segment is enproduct) it opens first in english language with enproduct in the url, if I switch the shop language now on the dtails page (I have to do this with the locale selector plugin of aimeos, because the main language navigation doesn't change the shop language as explained above), aimeos now generates the url enproduct?ai__d_pos=3&ai__locale=de&ai__currency=EUR, and it says unable to find product. This is logic because the shop now tries to find the english url_segment within locale=de, instead the url should inlcude the german url_segment deprodukt to be searched in the locale=de.

This is one of the unsolved problems when using URL segments in different languages in the standard configuration where no product IDs are part of the URL. The solution might be to resolve the product name without using the language.

[kledo-34]

It's not the MetaTag API because there you can only change/remove tags. It's only possible to remove the canonical URL for all pages using this: https://github.com/aimeos/aimeos-typo3/blob/master/ext_localconf.php#L314

True that ;) Got it, great solution and it works.

[kledo-34]

The site configuration has precedence now over your TS configuration if you have a site configuration, so these lines won't have any effect if your setup.

Guess, these lines don't retrieve the actual language but the first language configured in the site configuration: https://github.com/aimeos/aimeos-typo3/blob/master/Classes/Base/Locale.php#L55-L58
Can you confirm that? If yes, how do we get the actual language?

Alright yes that could be the problem. I'm not the best php developer so I don't know if this is the smartest way to do it, but I successfully wrote the following code to get the current Two letter ISO code.

` $siteConfigurationLanguages = GeneralUtility::makeInstance(SiteFinder::class)->getSiteByPageId($page['uid'])->getConfiguration()['languages'];

foreach ($siteConfigurationLanguages as $siteConfigurationLanguage) {
	if($siteConfigurationLanguage['languageId'] == $page['sys_language_uid']){
		$languageCode = $siteConfigurationLanguage['iso-639-1'];
		break;
	}
};`

I received all languages configured in the site configuration and then checked the languageIds against the sys_language_uid of the current page ($GLOBALS['TSFE']->sys_language_uid). If they match I get the related ISO code which was my need, but you could get any values from that language configuration now.
Maybe that helps.

[kledo-34]

This is one of the unsolved problems when using URL segments in different languages in the standard configuration where no product IDs are part of the URL. The solution might be to resolve the product name without using the language.

Sounds good to me, if the language blocks the product make the product independent of it. If you know how to do it - a good idea. :)

[aimeos]

Can you confirm that? If yes, how do we get the actual language?

Alright yes that could be the problem. I'm not the best php developer so I don't know if this is the smartest way to do it, but I successfully wrote the following code to get the current Two letter ISO code.

We would like to use the modern v9 API if possible and got the response that one of these might return the currently used language ID:

GeneralUtility::makeInstance('TYPO3\CMS\Core\Context\Context');
$context->getPropertyFromAspect('language', 'id');
// or
$context->getPropertyFromAspect('language', 'contentId');

Can you please check which one works correctly here in your situation?
https://github.com/aimeos/aimeos-typo3/blob/master/Classes/Base/Locale.php#L55-L58

[aimeos]

Sounds good to me, if the language blocks the product make the product independent of it. If you know how to do it - a good idea. :)

Done: aimeos/aimeos-core@f70a1aa

Can you please check if it works for you now?

[kledo-34]

We would like to use the modern v9 API if possible and got the response that one of these might return the currently used language ID:

GeneralUtility::makeInstance('TYPO3\CMS\Core\Context\Context');
$context->getPropertyFromAspect('language', 'id');
// or
$context->getPropertyFromAspect('language', 'contentId');

Can you please check which one works correctly here in your situation?
https://github.com/aimeos/aimeos-typo3/blob/master/Classes/Base/Locale.php#L55-L58

At first it didn't so I tried out more things and set up more languages and realized both work correctly, except for the default language, this always turns english, although it is german as earlier described.

[kledo-34]

Sounds good to me, if the language blocks the product make the product independent of it. If you know how to do it - a good idea. :)

Done: aimeos/aimeos-core@f70a1aa

Can you please check if it works for you now?

Unfortunately it doesn't, same error behaviour as before.

Additionaly a new error happens. If I use the working language switch for non default languages as mentioned above, I can switch the language on the details page, (url-segments are not resolved) and the first article that I open after flushing typo3 cashes will be opened on all further article pages after language change. Let's say I opened article3 after flushing cashes. If I go to the next article and try to switch language on the details page, the URL changes/switches to the article3 url.

[aimeos]

At first it didn't so I tried out more things and set up more languages and realized both work correctly, except for the default language, this always turns english, although it is german as earlier described.

Does $GLOBALS['TSFE']->getLanguage() yield better results and returns the right one for the default language?

[kledo-34]

Does $GLOBALS['TSFE']->getLanguage() yield better results and returns the right one for the default language?

I had a bit of time today to test and debug things a bit and I found a solution I guess. The problem was not the language ID, so you can leave the code for that in the current dev version untouched, BUT:
In my site configuration under locales I use e.g. de_DE or en_US which is also example/suggestion inputs of typo3. This is recieved, but aimeos expects a twoletterISOCode and therefore cannot resolve it and always returns the default language. I can simply change de_DE to de only or en_US to en only, but that would be a risky solution for others so if you replace getLocale() with getTwoLetterIsoCode() you should have a stable solution no matter what people type into their fields ;)

[kledo-34]

Now after the solution above, again a report about what works correctly now and what not:
The list view works completely

• I can switch languages (with the typo3 lang menu) and get the correct shop list language page and the different product translations, etc.
• I can reach the categorie pages in all different translations
• I can reach the product details page products correctly in all different languages (the language and url_segment are correct, no jumping back to default language, etc. as described earlier)

The Details View doesn't work completely

• If I change the language, I get an error if I use url_segments
• on language change the details page always switches to the first product that I opened after flushing cashes as described above

but due to debugging, my aimeos installation got a bit messy here and there so I will clean it and then check things again. I tried to get current dev version for everything (aimeos-typo3, aimeos-core, ai-admin-jqadm, ai-admin-jsonadm, ai-client-html, ai-client-jsonapi, ai-controller-frontend, ai-controller-jobs, ai-gettext, ai-typo3) to check things correctly, but when executing the tables update script I get 'Call to private Doctrine\DBAL\Types\Type::__construct() from context Aimeos\MW\Setup\Task\TablesMigrateSiteid' and in the frontend 'Class Aimeos\Client\Html\lface does not exist. Reflection failed'. So I need some time to fix this before I can report about changes again, this will take a while because I don't have lots of time left this month.

[aimeos]

In my site configuration under locales I use e.g. de_DE or en_US which is also example/suggestion inputs of typo3. This is recieved, but aimeos expects a twoletterISOCode and therefore cannot resolve it and always returns the default language. I can simply change de_DE to de only or en_US to en only, but that would be a risky solution for others so if you replace getLocale() with getTwoLetterIsoCode() you should have a stable solution no matter what people type into their fields

You need to add a new language "de_DE" to the list of languages in Aimeos and use that language in a locale record (both available in the Aimeos backend -> Navigation: Locale).

We've added a fallback from "de_DE" to "de" in the future if you haven't set up a locale for "de_DE":
aimeos/aimeos-core@d81b97e

[kledo-34]

You need to add a new language "de_DE" to the list of languages in Aimeos and use that language in a locale record (both available in the Aimeos backend -> Navigation: Locale).

We've added a fallback from "de_DE" to "de" in the future if you haven't set up a locale for "de_DE":
aimeos/aimeos-core@d81b97e

Oh ok, got it, makes sense sorry for my misunderstanding. Is this written somewhere in the documentation, that the site config locale and aimeos locales have to be exactly the same, I didn't think about that and might be a problem others will get if they're not aware of it.
Thanks a lot for the good support.

[aimeos]

Oh ok, got it, makes sense sorry for my misunderstanding. Is this written somewhere in the documentation, that the site config locale and aimeos locales have to be exactly the same, I didn't think about that and might be a problem others will get if they're not aware of it.

It won't be a problem any more starting with the upcoming release in 1-2 weeks.
Thank you for helping us to make Aimeos better! :-)

[aimeos]

The sitemap export for products and categories is working well with URL segments now.
Please remind that you need a configuration like that:

client.html.catalog.tree.url.target = <list page ID>
controller.jobs.catalog.export.sitemap.location = ../
controller.jobs.product.export.sitemap.location = ../
controller.jobs.catalog.export.sitemap.baseurl = http://127.0.0.1:8000
controller.jobs.product.export.sitemap.baseurl = http://127.0.0.1:8000

[aimeos]

• If I change the language, I get an error if I use url_segments
• on language change the details page always switches to the first product that I opened after flushing cashes as described above

That may be related to TYPO3 caching of the menu entries. Can you try this solution:
https://aimeos.org/help/typo3-extension-f16/language-menu-t840-10.html#p7139

[kledo-34]

Sure I can and will but at the moment I'm in a hurry getting projects finished until the end of february, so I think I can't test it before your next update release (that you mentioned above), sorry for that, but I'll try my best (it's also in my interest to get this work ;) )

[kledo-34]

When I update and try to run the database update script I get an Error
Fatal error: Declaration of Doctrine\DBAL\Statement::fetch($fetchMode = NULL) must be compatible with Doctrine\DBAL\Driver\ResultStatement::fetch($fetchMode = NULL, $cursorOrientation = PDO::FETCH_ORI_NEXT, $cursorOffset = 0) in /typo3conf/ext/aimeos/Resources/Libraries/doctrine/dbal/lib/Doctrine/DBAL/Statement.php on line 33
So I can't test things yet.

[aimeos]

Seems like a problem of the installed Doctrine DBAL version but has nothing to to with TYPO3 or Aimeos

[kledo-34]

Alright, yep in the meantime I tested it offline on a testserver and things are working as far as I can see. Therefore thank you very much for the effort and I'll close this issue now, I consider those things as solved ;)
Thank you