View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7166 [OXID eShop (all versions)] 4.09. SEO, SEO URL minor always 2020-07-30 12:42 2020-07-30 12:42
Reporter: QA Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 6.2.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Fixation of SEO URL is ignored when changing categorie assignment of article
Description: Hi there,

we encounterd the problem that seo url of an article is changend and settings resetted if you assign an article to a other categorie.

Even categorie-seo url behave diffrent, so we regard this as a bug.

Best regards

QA - SG -
Tags:
Steps To Reproduce: 1. Fixate SEO URL of any article
2. Assign this article a new categorie
3. fixation is resettet
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6822 [OXID eShop (all versions)] 2.3. Extensions (modules, themes) minor always 2018-04-27 16:18 2020-07-29 10:14
Reporter: QA Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.0.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Admin templates can't be changed in source if they are overwritten in pe/ee
Description: If a template is overwritten in PE or EE Version of OXID eShop 6, you can't do changes in the template stored in the source directory. The reason is the look up order of the shop framework:

1) oxideshop-ee
2) oxideshop-pe
3) source (ce)

So for example if you need a new block in admin template article_main, you have to make changes in the vendor -> oxideshop-ee -> article_main template, because the shop framework will take this one to render the webpage. Unfortunately it should be strictly avoided to make changes in the vendors directory.
Tags: Admin Template, Template Blocks, Theme Handling
Steps To Reproduce: 1) search for an admin template in pe/ee that's also available in source (ce)
2) make changes in the template in source
3) empty /tmp
4) reload the webpage
5) you will see no changes
6) delete/rename the corresponding template in pe/ee
7) changes will be visible
Additional Information: Changing the look up order wouldn't be a solution, but it's appreciated to have a option to change admin templates, especially for adding own blocks.
Attached Files:
Notes
(0012458)
smxsm   
2018-04-30 10:05   
That was exactly the problem we tried to describe in 0006821 - you can't add new blocks to EE admin templates right now, which is a major bug to me, because we need some extra blocks for quite some modules, so I am not sure about the "low" priority ...
And why are all the CE admin templates copied to the EE source directory anyways, but not the EE specific ones?
(0012459)
QA   
2018-04-30 10:28   
(Last edited: 2018-04-30 10:28)
Issue was classified minor, because you can extend admin templates with the included blocks and even not all admin templates are affected. Possible priority changes will be discusssed intern at the next development meeting.

Because the bugtracker is only for reporting issues, please use our Dev-General Mailing List (https://oxidforge.org/en/mailinglists) for further questions about OXID eShop.

[sp]

(0012475)
smxsm   
2018-05-04 15:59   
Well, I used the bugtracker because it IS an issue / bug to me, not something I wanted to discuss ... and only because not all templates are affected doesn't qualify it as a "non-bug" imho :)
(0012476)
tabsl   
2018-05-04 16:21   
it´s a bug NOT a feature! no comment, really ...
(0012786)
pixpro   
2019-02-21 11:45   
... same issue here!! the customer need's a better user interface / better sorting of input fields, optimized custom templates, etc. for article data entry, but we have to say "sorry not possible! even with your enterprise edition :( ..."
(0012807)
avalue   
2019-03-05 11:32   
+1 for solving this issue

We had modules extending the block, but this also does not work anymore.
(0012880)
KIRATIKdevs   
2019-05-06 11:10   
+1 - we also have some problems with this. There is some hacks but this is not good way to make it that way.
(0013275)
Pavel Stolba   
2020-07-29 10:14   
+1 - we also have some problems with this. Is there some solution to add new blocks in EE admin templates?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7163 [OXID eShop (all versions)] 1.01. Products (product, categories, manufacturer, promotions etc.) minor always 2020-07-24 09:20 2020-07-24 11:16
Reporter: DayanaLuedecke Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Flow, Wave
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Variantselector doesn't work in List View listitem_line in wave and flow
Description: no redirect to details page when selecting a variant, theme wave and theme flow

problem is a missing class listDetails for the exterior div in template listitem_line.tpl, which is necessary for jquery
Tags:
Steps To Reproduce: Select Listview "line" in Productlist an choose any variant in variantselector
Additional Information:
Attached Files: listview.JPG (110,499 bytes) 2020-07-24 09:44
https://bugs.oxid-esales.com/file_download.php?file_id=1829&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7130 [OXID eShop (all versions)] 2.3. Extensions (modules, themes) minor always 2020-04-25 12:14 2020-07-17 13:57
Reporter: leofonic Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.2.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.2.2  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: composer update changes module state in yaml
Description: When running composer update and updating module files, module state is changed in yaml to "false"
Tags:
Steps To Reproduce: 1. Activate module gdpr, module state in yaml is "configured: true"
2. run conposer update and choose "yes" when prompted to overwrite files of gdpr module only
3. Module state in yaml is now "configured: false", in Shop backend it is still active and running
Additional Information:
Attached Files:
Notes
(0013203)
QA   
2020-04-28 13:04   
(Last edited: 2020-04-28 13:04)
Looks like the state of the module is falling back to "installed" after you have overwritten the files, which does not sound wrong in the first place. Though the module is marked active by the data in the database it leads to a different state of database and configuration yaml. That's not really good. Luckily I did not encounter any negative sideeffects after the reproduction. To get the correct state in the yaml again, you could click the save button in the administration area.

If you noticed any sideeffects, please share the information with us. Thanks for your feedback. Issue is acknowledged.

[sp]

(0013204)
leofonic   
2020-04-28 14:14   
I think the only case where the setting in the yaml is used, is when the command "vendor/bin/oe-console oe:module:apply-configuration" is used to apply the configuration to the shop, for example in a deployment scenario.
(0013205)
QA   
2020-04-28 15:05   
The administration area reads the data from the configuration files and saves it to it. Data in the database is only stored, when the module is active and then the frontend reads the data from the database.
(0013268)
alfredbez   
2020-07-16 15:23   
Looks like this is already resolved here: https://github.com/OXID-eSales/oxideshop_ce/commit/7299ef2b79e3d1b649c0247eedf105e69bffd6e6

Will be included in 6.2.2
(0013270)
marco_steinhaeuser   
2020-07-17 13:56   
fixed according to https://bugs.oxid-esales.com/view.php?id=7130#c13268


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7161 [OXID eShop (all versions)] 2.3. Extensions (modules, themes) major always 2020-07-16 14:10 2020-07-16 14:10
Reporter: QA Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 6.2.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Modul deactivation of Payment-Module (e.g. Paypal) in Subshop, deactivates Payment-Method in Main-Shop
Description: Hi there,

if you deactivate the payment-module Paypa in Subshop, you also deactivates Payment-Method in Main-Shop.

Best regards

QA - SG -
Tags:
Steps To Reproduce: 1. New installed OXID 6.2
2. Create Child Subshop of Main-Shop
3. Activate Module Paypal in Main Shop
4. Activate Module Paypal in Subshop
5. Deactivate Module Paypal in Subshop

-> In Main Shop Paypal Payment-Method is deactivated
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7160 [OXID eShop (all versions)] 4.12. Subshop handling major always 2020-07-15 14:16 2020-07-16 13:58
Reporter: matths Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Articles inherited in a sub shop with an overwritten price are not sorted correctly by price
Description: When you have an OXID EE Installation with two subshops (malls) and the seconed subshop inherits the articles from the first, one can overwrite the price of the article in subshop 2. These prices are stored in the oxfield2shop table.
When an article that is in subshop 1 more expensive than another article gets cheaper in subshop 2, the category list sorted by price in subshop 2 is still sorting using the prices of subshop 1 and not 2.
Tags: Sorting
Steps To Reproduce: * setup OXID EE with at least two subshops
* subshop two needs to inherit articles from subshop one
* create a test category in subshop 2 and put inherited articles inside
* change the prices of some of those articles (for testing purpose make one expensive article cheap, and a cheap article expensive)
* open the category list view in the frontend
* sort category list view by price
* see that sorting is wrong and follows still the prices from subshop one
Additional Information: Why is this important? Developers might customize more fields to overwrite values for inherited articles in different subshops and use sorting for that. So if you you would fix sorting for price, oxfield2shop is more usable for other use cases as well.
Attached Files: oxfield2shop.JPG (134,058 bytes) 2020-07-15 14:16
https://bugs.oxid-esales.com/file_download.php?file_id=1825&type=bug
after.JPG (160,031 bytes) 2020-07-15 14:16
https://bugs.oxid-esales.com/file_download.php?file_id=1826&type=bug
before.JPG (152,915 bytes) 2020-07-15 14:16
https://bugs.oxid-esales.com/file_download.php?file_id=1827&type=bug
change_price_in_subshop.JPG (215,602 bytes) 2020-07-15 14:16
https://bugs.oxid-esales.com/file_download.php?file_id=1828&type=bug
Notes
(0013266)
QA   
2020-07-15 14:29   
Dear matths,

thank you for reporting this issue.

I could reproduce the wrong sorting in OXID 6.2

Best regards

QA - SG -


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7137 [OXID eShop (all versions)] 2.3. Extensions (modules, themes) major always 2020-05-16 00:34 2020-07-15 14:46
Reporter: DanielS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.2.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.2.2  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: 7.1
Database Version: Not defined
Summary: unable to uninstall module with metadata file not in package root folder
Description: In our module packages the module files are located in a separate subdirectory (e.g. "src"). This is configured in the composer.json in "source-directory". The installation of the module works without errors. Uninstalling with composer (composer remove d3/[packageid]) results in the following error:

[InvalidArgumentException]
File /var/www/html/.../vendor/d3/[packageid]/metadata.php is not readable or not even a file.

However, the storage location of metadata.php is /var/www/html/.../vendor/d3/[packageid]/src/metadata.php
Tags:
Steps To Reproduce: - create a module with defined source-directory
- install the module with "composer require [vendor]/[packageid]"
- try to remove the module with "composer remove [vendor]/[packageid]"

Additional Information: Exception trace:
 () at /var/www/html/.../vendor/oxid-esales/oxideshop-ce/source/Internal/Framework/Module/MetaData/Dao/MetaDataProvider.php:97
 OxidEsales\EshopCommunity\Internal\Framework\Module\MetaData\Dao\MetaDataProvider->getData() at /var/www/html/.../vendor/oxid-esales/oxideshop-ce/source/Internal/Framework/Module/MetaData/Dao/ModuleConfigurationDao.php:55
 OxidEsales\EshopCommunity\Internal\Framework\Module\MetaData\Dao\ModuleConfigurationDao->get() at /var/www/html/.../vendor/oxid-esales/oxideshop-ce/source/Internal/Framework/Module/Install/Service/ModuleInstaller.php:85
 OxidEsales\EshopCommunity\Internal\Framework\Module\Install\Service\ModuleInstaller->uninstall() at /var/www/html/.../vendor/oxid-esales/oxideshop-composer-plugin/src/Installer/Package/ModulePackageInstaller.php:56
 OxidEsales\ComposerPlugin\Installer\Package\ModulePackageInstaller->uninstall() at /var/www/html/.../vendor/oxid-esales/oxideshop-composer-plugin/src/Installer/PackageInstallerTrigger.php:90
 OxidEsales\ComposerPlugin\Installer\PackageInstallerTrigger->uninstallPackage() at phar:///usr/local/bin/composer/src/Composer/Plugin/PluginManager.php(196) : eval()'d code:105
 OxidEsales\ComposerPlugin\Plugin_composer_tmp1->uninstallPackage() at n/a:n/a
 call_user_func() at phar:///usr/local/bin/composer/src/Composer/EventDispatcher/EventDispatcher.php:164
 Composer\EventDispatcher\EventDispatcher->doDispatch() at phar:///usr/local/bin/composer/src/Composer/EventDispatcher/EventDispatcher.php:116
 Composer\EventDispatcher\EventDispatcher->dispatchPackageEvent() at phar:///usr/local/bin/composer/src/Composer/Installer.php:601
 Composer\Installer->doInstall() at phar:///usr/local/bin/composer/src/Composer/Installer.php:232
 Composer\Installer->run() at phar:///usr/local/bin/composer/src/Composer/Command/RemoveCommand.php:155
 Composer\Command\RemoveCommand->execute() at phar:///usr/local/bin/composer/vendor/symfony/console/Command/Command.php:245
 Symfony\Component\Console\Command\Command->run() at phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:835
 Symfony\Component\Console\Application->doRunCommand() at phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:185
 Symfony\Component\Console\Application->doRun() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:281
 Composer\Console\Application->doRun() at phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:117
 Symfony\Component\Console\Application->run() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:113
 Composer\Console\Application->run() at phar:///usr/local/bin/composer/bin/composer:61
 require() at /usr/local/bin/composer:24
Attached Files:
Notes
(0013225)
DanielS   
2020-05-16 00:41   
(Last edited: 2020-05-16 00:42)
Pull request: https://github.com/OXID-eSales/oxideshop_ce/pull/797

(0013227)
QA   
2020-05-19 11:49   
The development team will work on the case.

-MF
(0013267)
Igor Iegupov   
2020-07-15 14:46   
Fixed in b-6.2.x


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7159 [OXID eShop (all versions)] 4. ------ eShop Core ------- minor always 2020-07-15 11:29 2020-07-15 12:39
Reporter: Helmut L. Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: $forceFullStructure paramter or _initDataStructure doesn't always work
Description: The _initDataStructure method in BaseModel has a paramter to load the full structure, but this parameter is only used if there is no cache file. If you're using a Model class in one place with lazy loading and in another without lazy loading by calling disableLazyLoading on it, then it depends on which place was first called after clearing the cache if you get the full structure or not.

There should be either a separate cache file for the full structure or the $forceFullStructure parameter should case the cache file to not be used at all.
Tags:
Steps To Reproduce: create on file that uses a Model class with lazy loading
execute that file

create another file that uses the same Model, but calls disableLazyLoading on it
if you call for example getSelectFields, you will see that it doesn't contain all columns, but only the columns that where used in the first file
Additional Information:
Attached Files:
Notes
(0013265)
QA   
2020-07-15 12:39   
Dear Helmut L.,

thank you for reporting this issue.
In OXID 6.2 the code still only checks $forceFullStructure if is there no cache-file.

Best regards
QA - SG -


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7158 [OXID eShop (all versions)] 5. ------ UpdateApp / Update ------ minor always 2020-07-10 16:39 2020-07-10 16:41
Reporter: mikkelfilla Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.2.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Error on upgrade/migrate from CE to PE/EE
Description: When doing a `composer require oxid-esales/oxideshop-metapackage-pe`the process is stopped with the message:

  [OxidEsales\Eshop\Core\Exception\DatabaseErrorException]
  Unknown column 'oxserial' in 'field list'
                                                            
  [Doctrine\DBAL\Exception\InvalidFieldNameException]
  An exception occurred while executing 'select oxserial from oxshops where oxid = ?' with params [1]:
                                                                                                        
  SQLSTATE[42S22]: Column not found: 1054 Unknown column 'oxserial' in 'field list'
                                                                                                        
  [Doctrine\DBAL\Driver\PDOException]
  SQLSTATE[42S22]: Column not found: 1054 Unknown column 'oxserial' in 'field list'
                                                                                     
  [PDOException]
  SQLSTATE[42S22]: Column not found: 1054 Unknown column 'oxserial' in 'field list'
Tags:
Steps To Reproduce: composer config repositories.oxid-esales composer https://professional-edition.packages.oxid-esales.com
composer require oxid-esales/oxideshop-metapackage-pe
Additional Information: As a workaround its possible to do the normal setup and ignore the composer require error:
composer config repositories.oxid-esales composer https://professional-edition.packages.oxid-esales.com
composer require oxid-esales/oxideshop-metapackage-pe
vendor/bin/oe-eshop-db_migrate migrations:migrate
vendor/bin/oe-eshop-db_views_generate

And do the require again:
composer require oxid-esales/oxideshop-metapackage-pe
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7117 [OXID eShop (all versions)] 1.01. Products (product, categories, manufacturer, promotions etc.) trivial always 2020-04-09 19:37 2020-07-10 16:40
Reporter: DayanaLuedecke Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.2.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Wave
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: wrong function call in the template leads to shop offline, e.g. if a TAG is called
Description: An incorrect variable is called in the template list / list.tpl of the theme WAVE.
This leads e.g. by calling a TAG to a shop offline.

In line 32 [{$ actCategory-> getTitle ()}] is currently called, but [{$ oView-> getTitle ()}] is correct.

[{block name = "page_list_listhead"}]
<div class = "page header">
[{assign var = 'rsslinks' value = $ oView-> getRssLinks ()}]
<h1 class = "h1">
[{$ actCategory-> getTitle ()}]
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7157 [OXID eShop (all versions)] 4.01. Database handling major always 2020-07-09 13:43 2020-07-10 11:42
Reporter: pbenke Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: feedback Product Version: 6.1.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: 7.1
Database Version: MySQL 5.6
Summary: Error in SQL statement on language en, if MySQL runs in STRICT_MODE
Description: File:
vendor/oxid-esales/oxideshop-ce/source/Application/Model/ActionList.php

Row 131:
if(EXISTS(select 1 from oxobject2action, $sGroupTable where $sGroupTable.oxid=oxobject2action.oxobjectid and oxobject2action.oxactionid=$sTable.OXID and oxobject2action.oxclass='oxgroups' LIMIT 1),

=> This is wrong, the condition "$sTable.OXID" cannot work, because $sTable is not defined in "from"-clause.

=> Correct:
if(EXISTS(select 1 from oxobject2action, $sGroupTable, $sTable where $sGroupTable.oxid=oxobject2action.oxobjectid and oxobject2action.oxactionid=$sTable.OXID and oxobject2action.oxclass='oxgroups' LIMIT 1),

(...from oxobject2action, $sGroupTable, ***$sTable*** where...)
Tags: Database, SQL
Steps To Reproduce: Multi-language shop e.g. de/en
Set MySQL to Strictmode => /log/oxideshop.log will be filled with...
Unknown column 'oxv_oxactions_en.OXID' in 'where clause'...
Additional Information:
Attached Files:
Notes
(0013264)
QA   
2020-07-10 11:42   
Dear pbenke,

OXID has the Systemrequirement of MYSQL 5.5 or MYSQL 5.7, and not 5.6.

Nevertheless i tried to reproduce your report with MYSQL 5.7 but without encountering any problem.

My steps where as followed:

1. Install a fresh version of OXID
2. activate Language EN
3. Set sql_mode = strict_all_tables
4. refresh views.
5. modifie an action

can you reproduce it on an mysql 5.7 server?
i guess there is a diffrence in behavior with embedded sql-snippets like your quoted snippet.

best regard
QA -SG-


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7136 [OXID eShop (all versions)] 4.12. Subshop handling critical always 2020-05-11 16:48 2020-07-09 11:28
Reporter: matths Platform:  
Assigned To: OS:  
Priority: immediate OS Version:  
Status: resolved Product Version: 6.1.5  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.2.2  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Shop deletes savedbasket entries from other (all) subshops
Description: In an OXID Enterprise Edition (EE) Shop Setup with multiple subshops, if in the OXID Admin the shop configuration for basket reservation is enabled (blPsBasketReservationEnabled) within one subshop, the next time a user interacts with his basket in this subshop, alls saved baskets less recent than configured for this subshop (iPsBasketReservationTimeout) are removed from the database, no matter their relation to this subshop.

So userbasets of type savedbasket from users of a different subshop are deleted because of enabled basket reservation in another subshop.

https://github.com/OXID-eSales/oxideshop_ce/blob/v6.3.6/source/Application/Model/BasketReservation.php#L300

The settings for basket reservation (blPsBasketReservationEnabled and iPsBasketReservationTimeout) are stored in relation to a shopid in the config table and configured in OXID Admin with a subshop selected. So the expectation of the shop owner is, that no other subshop is harmed by that configuration.

Also when a userbasket doesn't have a shopid field, it relates to a user which might very well have a shopid.

Tags: Basket, EE, Reservation, Subshops
Steps To Reproduce: * setup OXID EE with at least two subshops
* do not share users between subshops
* put articles in your basket in shop 2 but do not order
* enable basket reservation and a short period timeout for shop 1
* put articles in your basket in shop 1
* wait the short period of time
* interact with basket in shop 1
* see saved basket of shop 2 user gone

Additional Information: shop/vendor/oxid-esales/oxideshop-ce/source/Application/Component/BasketComponent.php::init() triggers
shop/vendor/oxid-esales/oxideshop-ce/source/Application/Model/BasketReservation.php::discardUnusedReservations which deletes all the savedbasket userbasket entries

$database->execute("delete from oxuserbaskets where oxtitle = 'savedbasket' and oxupdate <= $iStartTime");

There should be a EE implementation for discardUnusedReservations. We might provide a basic example as Pull Request if we get access to the Github Repo again.

Attached Files: screenshot_story.zip (1,213,323 bytes) 2020-05-25 17:11
https://bugs.oxid-esales.com/file_download.php?file_id=1809&type=bug
Notes
(0013223)
QA   
2020-05-13 13:55   
(Last edited: 2020-05-22 19:59)
Could not been reproduced in OXID 6.2.1. Please make an update and try again.

-MF

(0013224)
matths   
2020-05-13 14:03   
Come on. Don't take my "Steps To Reproduce" as 1:1 but think about what I've written in the description and what leads to the deletion of savedbasket Userbaskets! The DELETE statement is still in the most recent CE code. I can't imagine there's an EE fix for that in between 6.1.5 and 6.2.1. I might be wrong here, but I doubt.
We have lost userbaskets and it is not a fun error reporting.
Have you tried with 6.1.5?
(0013232)
QA   
2020-05-19 17:10   
(Last edited: 2020-05-19 17:12)
We have tested it with Enterprise Edition 6.1.6 and can't reproduce it there, too.

Please provide 1:1 steps to reproduce.

(0013233)
matths   
2020-05-20 09:49   
I currently can't afford the time to setup a clean, standard 6.1.6 EE with at least two subshops, but I am reducing side effects from our customizings to ensure the problem is in the oxid standard as well. And I'm really sure, it is.
As mentioned before, it's all about the database DELETE statement in https://github.com/OXID-eSales/oxideshop_ce/blob/v6.3.6/source/Application/Model/BasketReservation.php#L300
So I expected you to find out, when this line is run through by yourself as you should know best.

So I can reproduce the savedbasket loss by foloowing these steps in our shop setup and with customizings (modules) reduced as much as possible.

You need at least two subshops.

configuration of subshop 1
blPsBasketReservationEnabled 1
iPsBasketReservationTimeout 60

configuration of subshop 2
blPsBasketReservationEnabled 0

to make it more obvious: truncate the oxuserbaskets table

1. As signed-in user A put an article into your basket in subshop 2.
In oxuserbaskets, there's an additional row "savedbasket".
oxuserbaskets table has one row.

wait for as long you like
2. As signed-in user B put an article into your basket in subshop 1.
In oxuserbaskets, there's an additional row "reservations".
oxuserbaskets table has two rows, now.

within the next 60 seconds...
3. As signed-in user C put an article into your basket in subshop 1.
In oxuserbaskets, there's an additional row "reservations".
oxuserbaskets table has three rows, now.

wait at least 60 seconds...
4. As User B, still logged in, call the start page of your shop, which consists of the mini basket widget, which initializes the BasketComponent.
Now, the oxuserbaskets table is empty again and has lost its rows, also the "savedbasket" of user A from subshop 2 is gone.

after some more time...
5. As user A I delete my session cookie and login to subshop 2 again.
I would expect my saved basket to be available again, but my basket is empty.

But again, I think my initial description has given you all what's needed:
The delete statement, once it is run through, is to general for a multi shop enterprise edition with basket reservation turned on in only one subshop:
delete from oxuserbaskets where oxtitle = 'savedbasket' and oxupdate <= $iStartTime
This deletes saved baskets from other subshops, which is not funny at all.

Br, Matthias
(0013238)
QA   
2020-05-22 19:58   
It seems your shop does not behave like a standard shop installation.

In step 1 I also have one row with savedbaskets in oxuserbaskets table. But in step 2 have three rows. Two savedbaskets and one reservations. If I follow your steps I can't reproduce the empty basket.

To verify bugs it is recommended to install a new shop with demo data on a test system to try to reproduce the behavior there as well.
(0013243)
matths   
2020-05-25 17:11   
I am upset, I point you to the obvious DELETE database query in question, and you don't even try hard enough to let the shop logic run through that line of code and see its fatal outcome.
It costs my time and my customers money to do this even more precisely:

* I installed a clean OXID 6.1 EE following the manual from https://github.com/OXID-eSales/oxvm_eshop/tree/b-6.1
* I created another mall: "subshop 2"
* for subshop 1 I disable savedbaskets in the performance settings, but enabled reservations or basket expiration of 5 minutes
* for subshop 2 savedbaskets are enabled by default and reservations disabled by default
* I logged into subshop 2 and put an article in the basket, which leads to a savedbasket row in oxuserbaskets
* Now I put different kites and stuff in my basket with different users or as guest in subshop 1
* After more than 5 minutes later I just opened the subshop 1 start page and all entries to oxuserbaskets are gone

I made a screenshot story for you to see it yourself, see attached zip archive.
(0013247)
QA   
2020-05-29 19:02   
Reproducible (also in 6.2.1) with the additional given information of the performance setting "Don't save Shopping Carts of registered Users" in subshop 1.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6064 [OXID eShop (all versions)] 4.02. Session handling major random 2015-03-03 10:53 2020-07-08 16:41
Reporter: gregor.hyneck Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: acknowledged Product Version: 6.2.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Azure
Browser: All
PHP Version: 5.3
Database Version: Not defined
Summary: Login in subshop is also valid in the parent shop
Description: When a user logs in the subshop, he is also logged in the parent shop (when opening them both in two browser tabs). The sid cookies of both shops remain the same if you refresh the tabs alternating. They do not refresh their sid cookie because the variable actshop is written to $_SESSION before session_start() was called (e.g. in oxconfig::init()). The variables written to $_SESSION before session_start() are not reliable (sometimes they get deleted, sometimes not).
Tags: EE
Steps To Reproduce: - create a subshop which inherits "settings, articles" from the parent shop (version EE 5.23)
- check that confbools[blMallUsers] is set to unchecked in the parent shop mall tab
- open 2 tabs in your Browser (Firefox 36 or Chrome 40): one with the parent shop and one with the subshop (&shp=2)
- create an account within the subshop and login
- reload the tab with the parent shop: user from subshop is logged in the parent shop. The value of the sid-cookie gets not refreshed for the parent subshop.
Additional Information: A bloody hotfix would be to save the variables of $_SESSION before session_start() and restore them afterwards.
Attached Files: create-subshop.png (60,758 bytes) 2020-06-02 11:51
https://bugs.oxid-esales.com/file_download.php?file_id=1815&type=bug
Notes
(0013248)
lambreva   
2020-06-02 11:51   
Hi, I found similar behaviour related to this issue. I worked with clean shop installation of 6.2 version (I used b-6.2.x branch) without installed modules. I created a sub-shop using 'Shop inherits all inheritable items (products, discounts etc) from it's parent shop.' option and as parent shop I used 'OXID eShop 6 (1)'. I logged in the frontend of shop 1 with 'user@oxid-esales.com' user and password 'useruser'. Then in the same tab of the browser I opened shop 2 and checked my account area, I even finalized an order in it without any problems. Then I logged out from shop 2 and tried to log in again and then I received an error message 'Wrong e-mail address or password!'.
(0013263)
QA   
2020-07-08 16:41   
If two tabs are open - one with the main shop and one with the subshop and a customer registers and logs in to the subshop and then updates the tab with the main shop, he is logged in with the user data from the subshop and can even place an order.
If you log out and try to log in again in the main shop, this is not possible with this account, because the user only has an account in the subshop.

Still reproducable in EE 6.2.1

-es-


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7155 [OXID eShop (all versions)] 4.12. Subshop handling minor always 2020-07-07 09:17 2020-07-07 09:24
Reporter: QA Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.2.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: For inherited categories it is not possible to influence the sorting
Description: If a category in the main shop is inherited by a subshop, the sorting is initially taken over and then no longer. Even if the sorting in the main shop changes.
It is also no longer possible to change the sort order in the subshop.

Workaround (In the main shop -> Manage articles -> Categories -> Mall -> delete the link to Subshop and activate it again.

So either the sorting should be taken over automatically for inherited categories or in the subshop it should be possible to change it afterwards.
Tags:
Steps To Reproduce: 1. Create Subshop (This shop inherits all articles and settings from the parent shop)
2. Inherit category tree in Subshop
3. Now try to change the category sorting in the subshop
    Only possible by de and reactivating the category link to Subshop
    (main shop -> Manage articles -> Categories -> Mall)
Additional Information: - es -
Attached Files: Shop_1.JPG (97,395 bytes) 2020-07-07 09:24
https://bugs.oxid-esales.com/file_download.php?file_id=1820&type=bug
Shop_2.JPG (67,829 bytes) 2020-07-07 09:24
https://bugs.oxid-esales.com/file_download.php?file_id=1821&type=bug
Shop_3.JPG (152,067 bytes) 2020-07-07 09:24
https://bugs.oxid-esales.com/file_download.php?file_id=1822&type=bug
Shop_4.JPG (56,714 bytes) 2020-07-07 09:24
https://bugs.oxid-esales.com/file_download.php?file_id=1823&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7153 [OXID eShop (all versions)] 2.1. Master Settings tweak always 2020-06-30 14:02 2020-07-02 08:51
Reporter: s.krenz Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Input field length for SMTP password is too small
Description: I had to configure a SMTP connection with a long password. After entering the password in OXID admin, I got an "Authentication failed" error.

After some investigation I found this issue:

I used the password "ThisIsALongPassword.TooLongForThisInputField,ButNotTooLongForTheDB." and entered into the "SMTP password" input field in OXID admin (Attachment 1). After clicking "Save" only "ThisIsALongPassword.TooLongForThisInputField,ButNo" was stored to the DB (Attachment 2).
I edited the HTML to see what is inside the input field and I found out it's already truncated (Attachment 3).

There are two different definitions of maximum field length for the SMTP password (and maybe for other fields too). In MySQL it is defined as "VARCHAR(128)", so it could be 128 characters long.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Bildschirmfoto vom 2020-06-30 13-50-46.png (6,167 bytes) 2020-06-30 14:02
https://bugs.oxid-esales.com/file_download.php?file_id=1816&type=bug
Bildschirmfoto vom 2020-06-30 13-52-34.png (12,397 bytes) 2020-06-30 14:02
https://bugs.oxid-esales.com/file_download.php?file_id=1817&type=bug
Bildschirmfoto vom 2020-06-30 13-56-18.png (6,268 bytes) 2020-06-30 14:02
https://bugs.oxid-esales.com/file_download.php?file_id=1818&type=bug
Notes
(0013260)
QA   
2020-06-30 15:48   
(Last edited: 2020-07-02 08:51)
The input field has the attribute maxlength="50", which cuts everything of after 50 characters. While typing, you may notice it, but even than it's a little tricky since it is showing only dots.

I see three possible workarounds:

1) Shorter password, obvious and easiest way.
2) Extend the admin_shop_main_leftform block in the shop_main.tpl with a module and change the maxlength attribute.
3) Add the password directly into the database, but be aware if you save again in the administration area. I don't recommend doing this.

Since 50 characters is usually enough and the restriction is on the form side, not in the database, I would not consider it a real bug. The bad thing is, that you're not getting notified about the maximum 50 characters. So I agree that some improvements should be done.

[sp]



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7014 [OXID eShop (all versions)] 4.09. SEO, SEO URL major always 2019-07-30 12:31 2020-06-30 16:20
Reporter: s.sadowski Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: resolved Product Version: 6.1.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.2.2  
    Target Version:  
Theme: Other
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Second page of article list doesn't load via SEO
Description: When trying to view second page of a custom type of article list via SEO URL (e.g. "/Sanitaer/2/") articles from first page are being displayed. The bottom-page pagination also shows first page as being active, even though second page link, and the currently opened URL both correctly point at the second page.
The corresponding `oxseo` DB table entry contains the appropriate URL params:
 SELECT * FROM oxseo WHERE oxseourl = 'Sanitaer/2/'\G
*************************** 1. row ***************************
 OXOBJECTID: e83bc6f13d80fec4062b185a4b51f0b9
    OXIDENT: 930bf46348cbf0859c211872ae379a77
   OXSHOPID: 1
     OXLANG: 0
   OXSTDURL: index.php?cl=tc_b2b_item_list_product_group&id=e83bc6f13d80fec4062b185a4b51f0b9&pgNr=1
   OXSEOURL: Sanitaer/2/
     OXTYPE: tc_product_group
    OXFIXED: 0
  OXEXPIRED: 0
   OXPARAMS: 2/
OXTIMESTAMP: 2019-07-30 09:41:23

However, looking at the logic of \OxidEsales\EshopCommunity\Core\SeoDecoder::decodeUrl() I noticed a few things. Firstly, page number is extracted from the SEO URL correctly using `SeoDecoder::extractPageNumberFromSeoUrl()` - as a result I'm getting the base URL ("Sanitaer/") and the correct page number (1 - "2" taken from the SEO link and decreased by one). Afterwards however `oxseo` table entry is fetched by key (oxident) which is generated from the base URL only, so the returned entry will be the same for all pages of that product group, which should be OK, because the page number should be added to the parsed URL parameters. Unfortunately that's not the case - in the core SeoDecoder class, line 79, we can see the condition, under which page number is added to the URL params array:
if (is_array($urlParameters) && !is_null($pageNumber) && (1 < $pageNumber))

As you can see, the last part of this condition (1 < $pageNumber) is actually not met for $pageNumber=1, which is the case for the second page. Changing that condition to (0 < $pageNumber) in an extension has resolved the issue.
Tags: SEO
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7152 [OXID eShop (all versions)] 4. ------ eShop Core ------- minor always 2020-06-30 13:35 2020-06-30 14:26
Reporter: QA Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.2.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Import of oxartextends with columns
Description: Due to
/vendor/oxid-esales/oxideshop-ce/source/Core/GenericImport/ImportObject/ArticleExtends.php:21

Where shopobject for oxartextends is set to oxI18n

you cannot get right table columns in
\OxidEsales\EshopCommunity\Core\GenericImport\ImportObject\ImportObject::getFieldList

so you cannot import oxartextends with more values than oxid

QA - SG -
Tags:
Steps To Reproduce: Try to import oxartextends in backend
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7017 [OXID eShop (all versions)] 2.8. Service minor always 2019-08-08 12:56 2020-06-30 14:26
Reporter: QA Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: It is not possible to assign database fields in generic data import.
Description: In the generic data import, it is not possible to assign database fields to the csv file if oxartextends was selected as the database table in step 1.
Tags:
Steps To Reproduce: 1. Admin -> Service -> gener. Import
2. Select table oxartextends
3. Select CSV File and seperator
4. In step 2 you can not select the corresponding database columns (only .oxid).

See screenshot attached.
Additional Information: - es -
Attached Files: csv_1.JPG (39,716 bytes) 2019-08-08 12:56
https://bugs.oxid-esales.com/file_download.php?file_id=1748&type=bug
csv_2.JPG (53,225 bytes) 2019-08-08 12:56
https://bugs.oxid-esales.com/file_download.php?file_id=1749&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7151 [OXID eShop (all versions)] 8. --- Twig engine --- block always 2020-06-24 13:44 2020-06-24 14:06
Reporter: QA Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: acknowledged Product Version: 6.2.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Twig-Theme
Description: https://github.com/OXID-eSales/twig-theme

after activation of theme you got maintaince-mode in frontend due to error:

OXID Logger.ERROR: Unknown "dump" function. ["[object] (Twig\\Error\\SyntaxError(code: 0): Unknown \"dump\" function. at /var/www/html/oxid_twig/source/Application/views/twig/tpl/widget/header/loginbox.html.twig:2)

QA - SG -
Tags:
Steps To Reproduce: 1. install twig and follow steps like described:
https://docs.oxid-esales.com/developer/en/6.2/development/modules_components_themes/theme/twig/installation.html

2. visit frontend
Additional Information: Also see pull request:

https://github.com/OXID-eSales/twig-theme/pull/1

for possible fix
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7134 [OXID eShop (all versions)] 4.04. Security minor always 2020-05-06 15:18 2020-06-23 14:03
Reporter: cesnauskast Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.2.2  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Session fixation
Description: Under specific conditions it's possible to inject a new session and trick user to fall for this scenario
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7116 [OXID eShop (all versions)] 2.3. Extensions (modules, themes) major always 2020-04-09 10:42 2020-06-05 13:25
Reporter: leofonic Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: resolved Product Version: 6.2.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.2.2  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Module class extensions cannot be sorted in backend
Description: When trying to rearrange the order of extended classes, javascript throws an error: Uncaught TypeError: Cannot read property 'safari' of undefined
This can be fixed by upgrading jquery-ui to a newer version, but the "save"-button remains inactive nevertheless.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0013174)
QA   
2020-04-09 11:36   
Confirmed for EE 6.2 and Browser Chrome
QA - SG -
(0013184)
dx_bhesse   
2020-04-14 17:42   
>but the "save"-button remains inactive nevertheless.
After upgrading to the newest jqueryui.min.js that can be fixed by changing line 34 in https://github.com/OXID-eSales/oxideshop_ce/blob/master/source/out/admin/src/js/widgets/oxmoduleslist.js#L34
from: $("#myedit [name=saveButton]").attr("disabled", "");
to: $("#myedit [name=saveButton]").prop("disabled", false);
(0013229)
aggrosoft   
2020-05-19 14:50   
Quick patch here

https://github.com/aggrosoft/oxid-patch-0007116/
(0013245)
dx_bhesse   
2020-05-27 21:42   
...and now packaged as a pull request: https://github.com/OXID-eSales/oxideshop_ce/pull/801
(0013250)
Alfons martin   
2020-06-05 13:25   
Thx for making the pull request to fix it and thanks for checking this one. I just took it and put it to the next 6.2. patch


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7138 [OXID eShop (all versions)] 2.5. Administer users minor always 2020-05-18 09:47 2020-06-03 13:23
Reporter: tte Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Deleting users won't delete user references left in other tables
Description: Invoking the user model's delete() function in Application/Model/User.php will call several other functions which should take care of deleting the remaining user references from various tables.

However, the invoked functions always try to get the user's ID using $this->getId() instead of using the $oxid param which might be present in the parent delete() function. This results in user references not being deleted properly from other tables while the original user has already been removed from oxuser.
Tags:
Steps To Reproduce: Delete a user account in the shop's backend.
Additional Information:
Attached Files:
Notes
(0013226)
QA   
2020-05-19 09:11   
(Last edited: 2020-05-19 09:13)
Reproduced in 6.2.1

ideas for a solution:
Either extend the method \OxidEsales\EshopCommunity\Application\Model\User::delete to set the object property by hand:
    public function delete($oxid = null)
    {
        if (!$oxid) {
            $oxid = $this->getId();
        }
        if (!$oxid) {
            return false;
        }
        
        if ($oxid && !$this->_sOXID) {  // <-- new
            $this->_sOXID = $oxid;      // <-- new
        }                               // <-- new


Or set the property by the calling controller: \OxidEsales\EshopCommunity\Application\Controller\Admin\AdminListController::deleteEntry
    public function deleteEntry()
    {
        $delete = oxNew($this->_sListClass);

        //disabling deletion for derived items
        if ($delete->isDerived()) {
            return;
        }

        $delete->setId($this->getEditObjectId()); // <-- new
        $blDelete = $delete->delete($this->getEditObjectId());


-MK



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7144 [OXID eShop (all versions)] 2.6. Administer orders minor always 2020-05-26 08:41 2020-05-26 08:44
Reporter: QA Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: the dropdown fields under orders in the shop admin should remain in selection in paging
Description: In shop admin the dropdown fields under orders should remain in the order view when selecting in paging.
Tags:
Steps To Reproduce: 1. Generate orders in frontend with the same payment method (20 times)
2. Go to Shop Admin -> orders
3. Select payment method selected in first step
4. Select 2nd page
5. Payment method is deselected
Additional Information: Also in 6.2.0 and 6.2.1
Attached Files: order_1.JPG (124,402 bytes) 2020-05-26 08:41
https://bugs.oxid-esales.com/file_download.php?file_id=1813&type=bug
order_2.JPG (67,246 bytes) 2020-05-26 08:41
https://bugs.oxid-esales.com/file_download.php?file_id=1814&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6914 [OXID eShop (all versions)] 4.01. Database handling minor always 2018-10-24 10:39 2020-05-25 12:16
Reporter: pbenke Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.1.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.2.0-beta.1  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Incorrect default values from database-columns, if empty
Description: For the following example, a database column with default '' is needed, e.g.
vendor/oxid-esales/oxideshop-ce/source/Setup/Sql/database_schema.sql:

CREATE TABLE `oxuser` (
  ...
  `OXSTREET` varchar(255) NOT NULL default '' COMMENT 'Street',


So, if the function metaColumns is called:

vendor/oxid-esales/oxideshop-ce/source/Core/Database/Adapter/Doctrine/Database.php
=> public function metaColumns($table)

There is the following code (Line 1112):

$item->has_default = ('' === $default || is_null($default)) ? false : true;

But, the following statement:

SELECT
COLUMN_NAME AS `Field`,
COLUMN_TYPE AS `Type`,
IS_NULLABLE AS `Null`,
COLUMN_KEY AS `Key`,
COLUMN_DEFAULT AS `Default`,
EXTRA AS `Extra`,
COLUMN_COMMENT AS `Comment`,
CHARACTER_SET_NAME AS `CharacterSet`,
COLLATION_NAME AS `Collation`
FROM information_schema.COLUMNS
WHERE
TABLE_SCHEMA = 'db'
AND
TABLE_NAME = 'oxuser'

gives this result:

OXSTREET | varchar(255) | NO | '' | Street | utf8 | utf8_general_ci

=> Default value is '' and not empty!

=> So the code above does not match.
This would be correct:

$item->has_default = ("''" === $default || '' === $default || is_null($default)) ? false : true;

Tags: Database
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012662)
QA   
2018-10-25 10:14   
That's a bit tricky.

One person would say: Yes. A empty string ('' or "") is not "empty" in the terms of null, so it is just a zero character long string and therefore not false.
Another person would say: Because of the "not null" information (so the field must have any kind of content) an empty string has to be interpreted as null and is therefore false.

Because of this I will acknowledge this entry so our Productmanager can decide if it's correct as it currently is or if the if clause has to be adopted according your proposal.

-MK
(0012768)
pbenke   
2019-01-18 15:51   
You can close this ticket.
This behaviour only happens with a MARIA-DB >= 10.2.*:
If you use an older Doctrine version with a newer MARIA-DB version...

Thank you.
(0012908)
alfredbez   
2019-06-06 15:43   
I think most people agree that an empty string means no value instead of the 2 char-long string ''.

We're already checking if the default value is an empty string here:

$item->has_default = ('' === $default || is_null($default)) ? false : true;
(0013242)
QA   
2020-05-25 12:16   
https://github.com/OXID-eSales/oxideshop_ce/blob/v6.5.5/CHANGELOG.md#fixed-5
https://github.com/OXID-eSales/oxideshop_ce/pull/709
-MK


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6888 [OXID eShop (all versions)] 4.01. Database handling minor always 2018-08-17 12:03 2020-05-25 12:16
Reporter: dirkbaumeister Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.1.0  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version: 6.2.0-beta.1  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: 7.0
Database Version: Other
Summary: Wrong default value of columns is read on mariadb 10.2.7 and higher
Description: Due to a change in mariadb 10.2.7 ( https://mariadb.com/kb/en/library/mariadb-1027-release-notes/ , MDEV-13132 ) now empty default values (no value, not null) are quoted. This leads to unexpected behaviour while reading the default value of a column by the oxid shop.

In our test-installation, for example, this leads to oxparentid fields in the oxarticles table which are filled with '' (two single quotes) instead of nothing. Every field that is empty but not null is affected by this problem.

This problem seems to be in the class Database (Core\Database\Adapter\Doctrine\Database) in the method metaColumns($table):

Here is checked if the column has a default value by the syntax:

('' === $default || is_null($default))

Obviously this will not work if the field has the default value ''.
Tags:
Steps To Reproduce: - Install oxid with mariadb database version 10.2.7 or higher.
- Create an article in the backend (It will disappear due to filled oxparentid field after save).
- Now inspect the entry in the oxarticles table. It should have a '' in several fields.
- If you look up the columns of the oxarticles table, for example, in the table COLUMNS in the information_schema you will see that the default value for empty fields is ''.
Additional Information: Tested Versions: OXID 6.0.3 and OXID 6.1.0 (I think every version of OXID 6)
Attached Files:
Notes
(0012585)
QA   
2018-08-17 12:57   
MariaDB isn't officially supported by OXID eShop. You can find the system requirements in our docs:
https://docs.oxid-esales.com/eshop/de/6.1/installation/neu-installation/server-und-systemvoraussetzungen.html

Nevertheless, if you want, you might create a pull request at our oxideshop_ce repository on GitHub:
https://github.com/OXID-eSales/oxideshop_ce

[sp]
(0013241)
QA   
2020-05-25 12:16   
https://github.com/OXID-eSales/oxideshop_ce/blob/v6.5.5/CHANGELOG.md#fixed-5
https://github.com/OXID-eSales/oxideshop_ce/pull/709
-MK


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7141 [OXID eShop (all versions)] 2.3. Extensions (modules, themes) minor always 2020-05-22 10:34 2020-05-22 13:41
Reporter: smtws Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.2.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: All
Browser: All
PHP Version: 7.0
Database Version: MySQL 5.7
Summary: error in templte preventing block override
Description: in delivery_main template there is an if condition introduced in block "admin_delivery_main_form" and only closed after the block was closed, which prevents override/extension of that block
Tags: Admin Template
Steps To Reproduce: override admin_delivery_main_form block
Additional Information: fixed template attached
Attached Files:
Notes
(0013236)
smtws   
2020-05-22 13:06   
anhang
(0013237)
QA   
2020-05-22 13:41   
Dear smtws,

thank you for reporting this issue.
I can reproduce the problem that this mismatching ifs are causing.

QA - SG -


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6987 [OXID eShop (all versions)] 2.4. Administer products major always 2019-05-28 17:00 2020-05-19 15:29
Reporter: simon.runer Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.0.3  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.2.2  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Cannot edit product description in subshop (with
Description: The Texteditor gets a disabled textarea in subshops:

<textarea disabled="" id="editor_oxarticles__oxlongdesc" name="oxarticles__oxlongdesc" style="width: 100%; height: 300px; display: none;">

This comes from the function _generateTextEditor() called with $field = 'oxarticles__oxlongdesc'

https://github.com/OXID-eSales/oxideshop_ce/blob/6bbd0b5f7d2d7571638f2644ef5fa5858095d51f/source/Application/Controller/Admin/ArticleMain.php#L98

In EE $field gets later compared in a function named canUpdateField() against entries in $aMultishopArticleFields. These entries are defined without the table name.
We have 'oxlongdesc' in $aMultishopArticleFields but not 'oxarticles__oxlongdesc'
Tags: Admin, Article, EE, Multi Shop, Products, WYSIWYG
Steps To Reproduce: see description
Additional Information:
Attached Files:
Notes
(0012904)
QA   
2019-05-31 18:43   
(Last edited: 2019-06-03 10:24)
As the comment of aMultishopArticleFields says "Define oxarticles fields which could be edited individually in subshops."
However the requested field is not in oxarticles but in oxartextends.

In earlier shop versions oxlongdesc was included in the oxarticle.

-MF

(0012905)
simon.runer   
2019-06-01 18:41   
Not sure If I got this right. Only fields from oxarticles can/should be added to aMultishopArticleFields and to the table oxfield2shop?
That would mean the article long description cannot be a multishop field?
(0012910)
QA   
2019-06-06 16:27   
Correct. Only fields from oxarticles can be added.

But since the long description is still part of the article despite the database design, I acknowledged this as a bug.
(0012911)
simon.runer   
2019-06-06 17:31   
So the correct behaviour should be that we can add oxlongdesc to aMultishopArticleFields ?
We have a MultiShop Setup with Oxid 5 and one with Oxi6 and in both we added oxlongdesc to aMultishopArticleFields and it works fine in the frontend for years/month.
If that is not supposed to work and might not work in the future when the bug is fixed, we would defentitely need to know that.
(0012912)
QA   
2019-06-07 16:10   
It should be possible to edit the oxlongdesc in sub shops which isnt currently working.
Product management is informed and will decide when it will be fixed.
(0013139)
finnegan   
2020-02-28 22:50   
I can confirm this bug.
In EE 5.x with 1 master shop for all articles and several subshops we could edit OXLONGDESC in the subshops separately, although even then the field was _not_ stored in oxarticle, but in oxfield2shop.

After upgrading to EE 6.1.5 this did not work any more.
The problem is that when editing a subshop version of the article OXLONGDESC is correctly written to oxfield2shop but _also_ to oxartextends, thus overwriting the master shop version of OXLONGDESC.

My findings:

In vendor/oxid-esales/oxideshop-ee/Application/Model/Article.php
protected function _update()

Íf you edit a subshop version of an article the if() applies, updates the field2shop table and returns.

Later in vendor/oxid-esales/oxideshop-ce/source/Application/Model/Article.php

in public function save()
$this->_saveArtLongDesc(); is called which updates the master shop version of the OXLONGDESC, which is an error.

The problem, as far as I can see, is that with the new split between EE and CE article class in EE V6.x the function
protected function _skipSaveFields()
is never called when updating the subshop version of an article.

If this function would be called then the _aSkipSaveFields array would contain OXLONGDESC and the master version of OXLONGDESC would not be updated.

In EE 5.x the function _skipSaveFields() was called within _update of the oxarticle class and everything was fine.

Another minor problem is the fact that the possibility to edit field values separately in subshops is only working when you have clicked "Allow individual price for inherited articles" in the "Mall" tab of the subshop configuration. The naming of this checkbox is misleading. For instance in our case we do not allow inherited subshop articles to have different prices from their master shop versions, but we _do_ want to edit OXSHORTDESC and OXLONGDESC in the subshop articles. So the checkbox should be renamed to something like "Allow individual values of fields defined in config.inc".
(0013218)
farzam.tahmasebmirza   
2020-05-12 10:23   
For fixing this issue you can easily add "OXLONGDESC", "OXARTICLES__OXLONGDESC" to $this->aMultishopArticleFields in config.inc.php file. For more information please check the developer documentation:
https://docs.oxid-esales.com/developer/en/6.2/development/modules_components_themes/project/configincphp.html#amultishoparticlefields
(0013220)
QA   
2020-05-12 12:15   
This way you can edit the field, but it will not be saved correctly. If you edit the field in a subshop, the data is also changed in the parent shop. At least if you save the article in the parent shop, it will not be changed in the subshops.

- MF
(0013222)
farzam.tahmasebmirza   
2020-05-12 17:35   
We will fix it
(0013228)
farzam.tahmasebmirza   
2020-05-19 14:11   
(Last edited: 2020-05-19 14:14)
We fixed the problem it is working now as same as before by adding OXLONGDESC to aMultishopArticleFields in config.inc file and oxfield2shop table. please check the documentation for more information.
https://docs.oxid-esales.com/developer/en/6.2/development/modules_components_themes/project/configincphp.html#amultishoparticlefields

(0013231)
farzam.tahmasebmirza   
2020-05-19 15:29   
We have not released it yet.Please check b-6.2.x branch in EE


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7139 [OXID eShop (all versions)] 7. --- Other tools -------------- minor always 2020-05-19 08:29 2020-05-19 08:32
Reporter: michael_keiluweit Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.2.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: After executing an insert event an update event is always executed too.
Description: Registering an insert and update event like in the given example: https://docs.oxid-esales.com/developer/en/6.2/development/tell_me_about/event/event_example.html
causes always to two entries when creating a new object. An insert log entry and an update log entry.
The reason for the two entries are a very own dispatchEvent call for the insert action, but afterwards the general "onChange" method is fired, which itself executes the dispatchEvent again.

\OxidEsales\EshopCommunity\Core\Model\BaseModel::save
// ...
if ($this->exists()) {
    // ...
} else {
    $response = $this->_insert();
    $action = ACTION_INSERT;
    $this->dispatchEvent(new AfterModelInsertEvent($this)); // <-- First time executing \OxidEsales\EshopCommunity\Core\Base::dispatchEvent
}

$this->onChange($action);  // <-- Second time executing \OxidEsales\EshopCommunity\Core\Base::dispatchEvent
Tags: Event
Steps To Reproduce: Follow the example: https://docs.oxid-esales.com/developer/en/6.2/development/tell_me_about/event/event_example.html
Additional Information: Saving a new category log:

expected:
[2020-05-19 08:31:10] OXID Logger.INFO: event: OxidEsales\EshopCommunity\Internal\Transition\ShopEvents\AfterModelInsertEvent with object object of type OxidEsales\Eshop\Application\Model\Category with id f11397b0de69d71f00445dd82c0c5aa0 [] []


actual:
[2020-05-19 08:31:10] OXID Logger.INFO: event: OxidEsales\EshopCommunity\Internal\Transition\ShopEvents\AfterModelInsertEvent with object object of type OxidEsales\Eshop\Application\Model\Category with id f11397b0de69d71f00445dd82c0c5aa0 [] []
[2020-05-19 08:31:11] OXID Logger.INFO: event: OxidEsales\EshopCommunity\Internal\Transition\ShopEvents\AfterModelUpdateEvent with object object of type OxidEsales\Eshop\Application\Model\Category with id f11397b0de69d71f00445dd82c0c5aa0 [] []






I noticed also, that an article update event causes also two log entries: a base model and a multilanguage model log entry, even when the article doesn't have a second language.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7111 [OXID eShop (all versions)] 4.08. Cache minor always 2020-04-02 16:56 2020-05-13 09:15
Reporter: QA Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.2.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.2.1  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Path of file container_cache.php is always default tmp directory (hardcoded)
Description: In the config.inc.php file you can define a custom path for your temporary directory. Default is source/tmp.

$this->sCompileDir = '/var/www/oxideshop/source/tmp';

Unfortunately the path to the file container_cache.php is always the default path since it's hardcoded to your source directory + 'tmp'.

See in code:

OxidEsales\EshopCommunity\Internal\Transition\Utility\BasicContext

public function getContainerCacheFilePath(): string
{
    return Path::join($this->getSourcePath(), 'tmp', 'container_cache.php');
}

Function getConfigParam('sCompileDir') should be used instead.
Tags:
Steps To Reproduce:
Additional Information: If you did not delete the default tmp directory, the eShop works by using this directory for the one file. Anyway, it does not look correctly.

[sp]
Attached Files:
Notes
(0013194)
Igor Iegupov   
2020-04-21 12:24   
Fixed in 6.2.1


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7126 [OXID eShop (all versions)] 8. --- Twig engine --- block always 2020-04-20 15:15 2020-05-13 09:14
Reporter: michael_keiluweit Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.2.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.2.1  
    Target Version:  
Theme: Other
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Only CE: After installing Twig Component, administration area is empty
Description: When you are installing the Twig engine then administration area is callable, but it is completely empty, like no menus entries would be existing.
That results later in a broken frontend as the Twig theme is not activateable.
Tags: Composer, Theme, Theme Handling
Steps To Reproduce: 1. Install CE 6.2.0
2. Install Twig component: composer require oxid-esales/twig-component
3. Install Twig Admin templates composer require oxid-esales/twig-admin-theme
4. Call the administration area. You will see a login box and you are able to log in actually in. But then you see an empty administration area
Additional Information: Install the component for PE or EE fixes that.
Attached Files:
Notes
(0013193)
QA   
2020-04-20 15:16   
-MK
(0013195)
QA   
2020-04-21 16:17   
https://github.com/OXID-eSales/oxideshop_ce/commit/dcd7f1b17e3dc6406053fa3f8dca62b56048930f#diff-dcd41cba8e188ee7a2b019d6a93421caL93
-MK
(0013197)
michael_keiluweit   
2020-04-22 09:37   
Removed unnecessary (and wrongly) information.
(0013198)
vilma_liorensaityte   
2020-04-22 10:02   
https://github.com/OXID-eSales/oxideshop_ce/commit/dcd7f1b17e3dc6406053fa3f8dca62b56048930f


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7119 [OXID eShop (all versions)] 2.4. Administer products minor always 2020-04-17 09:12 2020-05-11 09:20
Reporter: DayanaLuedecke Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: WYSIWYG Editor + Mediathek - error on creating relative links
Description: If you try to create a relative link, always a absolute link is saved.

Example:
Input: /kontakt (with/without / doeas not matter)
Result:http:///kontakt
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7120 [OXID eShop (all versions)] 2.3. Extensions (modules, themes) block always 2020-04-17 12:35 2020-04-27 12:48
Reporter: ivoba Platform:  
Assigned To: OS:  
Priority: urgent OS Version:  
Status: acknowledged Product Version: 6.2.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Custom Module Command breaks composer update
Description: This is related to https://bugs.oxid-esales.com/view.php?id=7112

When creating your own command inside of a module, composer update fails with

PHP Fatal error: Uncaught Error: Call to undefined method MyName\Importer\Commands\MyCommand::getDefaultName() in /var/www/html/vendor/symfony/console/DependencyInjection/AddConsoleCommandPass.php:61

This happens only when in service.yaml command in tags is not defined:
So this works:
    tags:
      - { name: 'console.command', command: 'my-name:my-module:my-command' }

But this should work without having to define command again, double to inside of Command class.

->setName('my-name:my-module:my-command')

Seems this is some symfony/console version mismatch with composer.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0013187)
QA   
2020-04-17 12:50   
Thanks for your report. This issue was known from the update component. Looks like it triggers also in your mentioned case. I acknowledge it as a bug, but want to say, that it does not block from using the module/command. The error message will be displayed during composer update, but the whole process works anyway.

[sp]
(0013201)
QA   
2020-04-27 12:39   
(Last edited: 2020-04-27 12:48)
I have to correct my note. Looks like we were lucky with the update component, but the error itself leads to a execution stop of the process. Therefore script won't be run and for example modules don't get copied or the module configuration won't be updated. This results in major issues.

Priority increased.

Please use the provided workaround: Adding the command to the services.yaml.

[sp]



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7121 [OXID eShop (all versions)] 2.3. Extensions (modules, themes) major always 2020-04-17 12:55 2020-04-22 09:25
Reporter: KIRATIKdevs Platform:  
Assigned To: OS: Linux Ubuntu  
Priority: normal OS Version: 18.04  
Status: acknowledged Product Version: 6.2.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Event onActivate executes on each SAVE module settings
Description: I noticed a weird thing…
I am testing OXID 6.2.0 EE on local VM and when I am trying to save module settings - click SAVE button in
“Extensions > Modules > MY_MODULE > Settings > Save”, then OXID executes “onActivate” event… each time I click on SAVE button.

I tested it on local VM (oxvm_base) and on online cloud server. The results are the same.
OXID 6.1.5 works OK.
Tags:
Steps To Reproduce: I tested it on my custom modules and 'visualcms'.

1. Turn on VisualCMS module
2. Make small change in code only for test purposes. In file "OxidEsales\VisualCmsModule\Core\Events::onActivate" please add:
var_dump("onActivate was executed"); die();
3. Uplod changed file
4. Try to change some module setting in visualcms
5. Click SAVE button

Additional Information:
Attached Files:
Notes
(0013196)
QA   
2020-04-22 09:25   
-MK


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7127 [OXID eShop (all versions)] 2.3. Extensions (modules, themes) minor always 2020-04-20 18:39 2020-04-21 15:15
Reporter: 8i11y Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: acknowledged Product Version: 6.2.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: All
Browser: All
PHP Version: 7.4
Database Version: MySQL 5.7
Summary: template_options.php in Application/views/child_theme/de/ is ignored - changes has no effect to the template settings
Description: Copied the folder Application/views/wave/de/ into Application/views/child_wave/
Edited some entries (especially the pathinformations of the help)
Cleared Cache (tmp-folder)
Refreshed Backend - but the text in the theme settings of child_wave are still as in wave
Edits in the lang.php file work (they are immediatly changed in the frontend)

Renaming or deleting the theme_options.php from wave theme has no effect - wether in the wave settings nor in the child_wave settings.
Tags: Admin, Admin Template, Theme, Theme Handling
Steps To Reproduce: Make a Child Theme of the theme wave.
Copy Application/views/wave/de into Application/views/child_theme/
Change something in the theme_options.php of the child_theme
Additional Information: - es -
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7123 [OXID eShop (all versions)] 6. ------ Setup ------- minor always 2020-04-18 21:00 2020-04-20 15:02
Reporter: leofonic Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: acknowledged Product Version: 6.2.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Removal of require-dev not possible
Description: Once composer has been run without --no-dev, update with --no-dev is no longer possible
Tags:
Steps To Reproduce: Install 6.2.0 without --no-dev
run composer update --no-dev

An exception is thrown:
Warning: Uncaught ErrorException: require(/var/www/html/vendor/composer/../ralouphie/getallheaders/src/getallheaders.php): failed to open stream: No such file or directory in /var/www/html/vendor/composer/autoload_real.php:73
Additional Information: - es -
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7124 [OXID eShop (all versions)] 6. ------ Setup ------- minor always 2020-04-18 21:46 2020-04-20 11:04
Reporter: leofonic Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.2.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Module with error in metadata cannot be removed
Description: If you try to install a module that has an incorrect metadata, installation fails, but deinstallation is not possible.
Tags:
Steps To Reproduce: 1. execute: composer require linslin/oxid6-example-module
    Installation fails, composer.json is reverted
   At this point, the module has already been downloaded by composer
2. execute: composer update
   Update also fails, although module is no longer present in composer.json:
  [OxidEsales\EshopCommunity\Internal\Framework\Module\MetaData\Exception\UnsupportedMetaDataKeyException]
  The metadata key "files" is not supported in metadata version "2.0".
Additional Information:
Attached Files:
Notes
(0013189)
QA   
2020-04-20 09:10   
Hi leofonic,

in my reproduction process with version 6.2 I can verify that the installation fails, also the composer update, but in my system, he doesn't remove the failed module entries in composer - data.
could you please check, if in the composer.json and composer.lock the module entries still exist?

I removed the entries in composer.json, composer.lock and vendor/composer/installed.json, then composer update worked.

Best Regards
(0013191)
leofonic   
2020-04-20 11:04   
> could you please check, if in the composer.json and composer.lock the module entries still exist?

composer.json: no entry, it was reverted after installation failed. Composer.lock is not read by composer update i think.

I think it should not be necessary to manually remove the module from vendor/composer/installed.json, errors in metadata could be ignored by oxid compooser plugin on deinstallation.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7122 [OXID eShop (all versions)] 2.3. Extensions (modules, themes) minor always 2020-04-18 19:25 2020-04-20 10:59
Reporter: leofonic Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.2.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Module translations are not available in onactivate method
Description: I use module translations in onactivate method to create some language specific database entries. This doesn't work anymore because translations are no longer available during activation.
Tags:
Steps To Reproduce: 1. Open the file source/modules/oe/gdproptin/Core/GdprOptinModule.php
2. Add this line in the onActivate method:
    var_dump(\OxidEsales\EshopCommunity\Core\Registry::getLang()->translateString('OEGDPROPTIN_STORE_DELIVERY_ADDRESS', 0, false));
3. Activate the GDPR Opt-in module and inspect the output.

In Oxid 6.1.5 Output is the translated string.
In Oxid 6.2.0 Output is 'OEGDPROPTIN_STORE_DELIVERY_ADDRESS'
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7118 [OXID eShop (all versions)] 4.07. Source code, Test minor always 2020-04-15 10:32 2020-04-15 13:38
Reporter: michael_keiluweit Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.2.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: ProjectYamlDao::saveProjectConfigFile does not check if file is writeable
Description: When a module is activated which has a service.yaml in its directory, the module activation services will register it by calling the method ProjectYamlDao::saveProjectConfigFile

\OxidEsales\EshopCommunity\Internal\Framework\Module\Setup\Service\ModuleActivationService::activate
[...]
\OxidEsales\EshopCommunity\Internal\Framework\DIContainer\Dao\ProjectYamlDao::saveProjectConfigFile

The content of the method:
    public function saveProjectConfigFile(DIConfigWrapper $config)
    {
        if (!$this->filesystem->exists($this->getGeneratedServicesFileDirectory())) {
            $this->filesystem->mkdir($this->getGeneratedServicesFileDirectory());
        }

        file_put_contents(
            $this->context->getGeneratedServicesFilePath(),
            Yaml::dump($config->getConfigAsArray(), 3, 2)
        );
    }


As you see the return value from file_put_contents isn't evaluated.
If the rights of the directory or the file itself of /var/www/shop/var/generated/generated_services.yaml are not sufficient enough, the file will not be modified, the service not registered and the administrator gets this error message in the backend:

OXID Logger.ERROR: You have requested a non-existent service "OxidEsales\GraphQL\Base\Framework\ModuleSetup". ["[object] (Symfony\\Component\\DependencyInjection\\Exception\\ServiceNotFoundException(code: 0): You have requested a non-existent service \"OxidEsales\\GraphQL\\Base\\Framework\\ModuleSetup\". at /var/www/html/vendor/symfony/dependency-injection/ContainerBuilder.php:1060)


Which would let you think that the module is broken. But truly the folder permissions are wrong, which should be checked and handled by the shop framework.
Tags: DI, Exception, File Permissions, Module, Service
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0013185)
florian.engelhardt   
2020-04-15 10:41   
Thanks for reporting this, as we already discussed I can confirm this behavior
(0013186)
QA   
2020-04-15 13:38   
-MK


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7112 [OXID eShop (all versions)] 5. ------ UpdateApp / Update ------ minor always 2020-04-04 19:41 2020-04-14 07:34
Reporter: leofonic Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.2.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.2.0  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Module update from 6.1 doesn't work in Windows operating system
Description: Following these instructions: https://docs.oxid-esales.com/developer/en/6.2/update/index.html

When using Windows operating system, command
composer require --no-interaction oxid-esales/oxideshop-update-component
throws an error:

oxid-esales/oxideshop-composer-plugin: Updating component oxid-esales/oxideshop-update-component
PHP Fatal error: Uncaught Error: Call to undefined method OxidEsales\OxidEshopUpdateComponent\Module\Command\InstallAllModulesConfigurationCommand::getDefaultName() in C:\web\www\myproject\vendor\symfony\console\DependencyInjection\AddConsoleCommandPass.php:61
Tags: Components, Composer, error, Solution Provided, Update App
Steps To Reproduce:
Additional Information: The error actually not blocks the update process. It could be ignored in QA tests. However user leofonic provided a fix the error won't occur anymore:
See comment: https://bugs.oxid-esales.com/view.php?id=7112#c13173

[sp]
Attached Files:
Notes
(0013170)
QA   
2020-04-06 08:23   
(Last edited: 2020-04-06 08:27)
The issue is reproducable with the current version of the OXVM, while connected to the VM via SSH. Luckily it does not affect the update in a bad way. The error message appears, but the step does not fail actually. The following steps of the update manual can be done correctly without any further errors. The eShop gets updated and runs without any known issues after the update process.

The error occurs on many systems, but not on all. Currently it's difficult to tell the exact circumstances, that lead to this error. We are taking more tests and try to collect further information.

[sp]

(0013171)
ox08152   
2020-04-08 15:53   
The error also occurs on our systems and we do not use windows as os, so this is not an os bug.
With the error we cannot finalize the migration from 6.1.x to 6.2.y because the module settings has now to be yaml settings. In order to go on with the OXID version 6.2, this should be fixed.

Here our complete stacktrace:
PHP Fatal error: Uncaught Error: Call to undefined method OxidEsales\OxidEshopUpdateComponent\Module\Command\InstallAllModulesConfigurationCommand::getDefaultName() in /var/www/vhosts/oxid6.weber.digital/httpdocs_oxid_project_ce/vendor/symfony/console/DependencyInjection/AddConsoleCommandPass.php:61
Stack trace:
#0 /var/www/vhosts/oxid6.weber.digital/httpdocs_oxid_project_ce/vendor/symfony/dependency-injection/Compiler/Compiler.php(140): Symfony\Component\Console\DependencyInjection\AddConsoleCommandPass->process(Object(Symfony\Component\DependencyInjection\ContainerBuilder))
#1 /var/www/vhosts/oxid6.weber.digital/httpdocs_oxid_project_ce/vendor/symfony/dependency-injection/ContainerBuilder.php(789): Symfony\Component\DependencyInjection\Compiler\Compiler->compile(Object(Symfony\Component\DependencyInjection\ContainerBuilder))
#2 /var/www/vhosts/oxid6.weber.digital/httpdocs_oxid_project_ce/vendor/oxid-esales/oxideshop-ce/source/Internal/Container/ContainerFactory.php(86): Symfony\Component\DependencyInject in /var/www/vhosts/oxid6.weber.digital/httpdocs_oxid_project_ce/vendor/symfony/console/DependencyInjection/AddConsoleCommandPass.php on line 61

Btw, the error not occurs using --no-plugins and otherwise it occurs after "Generating OXID eShop unified namespace classes ... Done".
(0013173)
leofonic   
2020-04-09 10:10   
This can be fixed by adding the commands to the services.yaml of the update component:

services:
  _defaults:
    autowire: true
    public: false

  oxid_esales.oxid_eshop_update_component.command.install_all_modules_configuration_command:
    class: OxidEsales\OxidEshopUpdateComponent\Module\Command\InstallAllModulesConfigurationCommand
    tags:
      - { name: 'console.command', command: 'oe:oxideshop-update-component:install-all-modules' }

  OxidEsales\OxidEshopUpdateComponent\Module\Command\TransferModuleDataToProjectConfigurationCommand:
    class: OxidEsales\OxidEshopUpdateComponent\Module\Command\TransferModuleDataToProjectConfigurationCommand
    tags:
      - { name: 'console.command', command: 'oe:oxideshop-update-component:transfer-module-data' }

  OxidEsales\OxidEshopUpdateComponent\Module\Command\DeleteModuleDataFromDatabaseCommand:
    class: OxidEsales\OxidEshopUpdateComponent\Module\Command\DeleteModuleDataFromDatabaseCommand
    tags:
      - { name: 'console.command', command: 'oe:oxideshop-update-component:delete-module-data-from-database' }

[...]
(0013175)
QA   
2020-04-09 11:38   
@ox08152 As said before, the error don't block the update. The error is triggered in one step even while you can clearly verify, that InstallAllModulesConfigurationCommand::getDefaultName() method is present. In the next steps the function is used correctly and the module update can be done successfully.

@leofonic thanks for your information. We will verify your suggestion.

[sp]
(0013176)
ox08152   
2020-04-09 12:57   
Extending the command configs in den service.yaml file of the module oxid-esales/oxideshop-update-component like @leofonic proposed solves the issue for us.
(0013177)
QA   
2020-04-09 14:40   
I have also tested the suggested fix by @leofonic and can confirm it is working. Therefore I did a pull request. Thank you for that.

[sp]
(0013179)
farzam.tahmasebmirza   
2020-04-09 16:52   
(Last edited: 2020-04-09 16:52)
We already released v1.0.1 of oxideshop-update-component with this fix, It should work.

(0013180)
leofonic   
2020-04-09 17:18   
It's working now, thank you!
(0013181)
mario_lorenz   
2020-04-09 20:39   
(Last edited: 2020-04-09 20:48)
I also get the Call to undefined method getDefaultName() error, but in the following situation:

I have developed a module of the new module type "oxideshop-component", with which I can extend the "oe: console" with further commands.

During the OXID install phase, in which all modules, themes and components are registered, my components repository is also instantiated at some point.

After this registration, another module is installed, then the script aborts.

In the error log I find that my first component command does not find the getDefaultName method. Since I cannot explain why the inherited (Symfony\Component\Console\Command\Command) method is not found, I have provided the getDefaultName method in my command as a workaround. So now there is no exception and the installation runs smoothly.

I think the problem will occur again and again with the new module type "oxideshop-component". The solution to write the component name in the service.yaml, or to provide the getDefaultName method again in my variant, is not the solution to the problem, since both work against the specifications of the symfony-console-commands.

(0013182)
QA   
2020-04-14 07:34   
Hello Mario, since this issue was especially focusing on the update process and the corresponding update component, I would recommend you create a new issue refering to the development of an oxideshop-component.

[sp]


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7113 [OXID eShop (all versions)] 2.3. Extensions (modules, themes) minor always 2020-04-08 22:07 2020-04-09 14:46
Reporter: leofonic Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.2.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Module information is not deleted completely
Description: If a registered module is not present in modules directory, a question is displayed:
Invalid modules were detected. Do you want to delete all registered module information and saved configurations?
Answering "yes" does not update configuration file, so the message appears again and again.
Tags: Module
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0013178)
QA   
2020-04-09 14:46   
(Last edited: 2020-04-09 14:46)
Steps to reproduce:

1. Install 6.2.0
2. Activate PayPal
3. Deactivate PayPal
4. Check var/config/shops/1.yaml and search for oepaypal
5. remove the directory source/modules/oe/oepaypal
6. goto admin -> modules and see the message "Invalid modules were detected. ".
7. Click on yes, see that it appears again.
8. remove the entry oepaypal from var/config/shops/1.yaml by yourself
9. goto admin -> modules and see the message "Invalid modules were detected. ".
10. Click on yes, see that it not appears again.

-MK



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7114 [OXID eShop (all versions)] 1.01. Products (product, categories, manufacturer, promotions etc.) trivial always 2020-04-09 08:50 2020-04-09 09:33
Reporter: DayanaLuedecke Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.2.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Wave
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: HTML error in the template lead to errors in microdata
Description: In the template productmain.tpl of the theme WAVE, a <div> is closed in the wrong place, which means that the structured microdata for "offers" cannot be read out correctly. The <div> is currently closed in line 172, but line 304 is correct.
In addition, the line class = "details-xyz" "is double closed in line 120, which also leads to an HTML error

[{* article main info block *}]
<div class = "details-information [{if $ oManufacturer-> oxmanufacturers__oxicon-> value}] hasBrand [{/ if}]" "itemprop =" offers "itemscope itemtype =" http://schema.org/Offer ">
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0013172)
QA   
2020-04-09 09:33   
Confirmed for Wave 3.4.1

QA - SG -


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7110 [OXID eShop (all versions)] 7. --- Other tools -------------- major always 2020-04-01 07:38 2020-04-01 11:24
Reporter: fbender Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.2.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: 7.2
Database Version: MySQL 5.6
Summary: vendor/bin/runtests doesn't return error exit code if setup fails
Description: For our module we use a Github Actions Workflow to automatically run tests against our module in the context of an Oxid 6 setup.

Due to https://github.blog/changelog/2020-02-21-github-actions-breaking-change-ubuntu-virtual-environments-will-no-longer-start-the-mysql-service-automatically/ the tests weren't run, because the database service wasn't there. The "runtests" Script complained about this, and rightly so, but didn't throw any kind of error code, so our builds were always green, despite the tests not being run.

I'd expect the script to fail with any non-success code if anything couldn't be set up.
Tags: Unit Tests
Steps To Reproduce: See https://github.com/PAYONE-GmbH/oxid-6/runs/550951132?check_suite_focus=true#step:10:8
Additional Information:
Attached Files:
Notes
(0013166)
QA   
2020-04-01 11:23   
-MK

EE: 6.2.0

root@a59c9b619382:/var/www/html# vendor/bin/runtests
=========
running php version 7.3.12

============
Failed to install shop with message: Could not connect to 'db' with user 'oxid'

#0 /var/www/html/vendor/oxid-esales/testing-library/library/Services/ShopInstaller/ShopInstaller.php(54): OxidEsales\TestingLibrary\Services\Library\DatabaseHandler->__construct(Object(OxidEsales\Eshop\Core\ConfigFile))
#1 /var/www/html/vendor/oxid-esales/testing-library/library/Services/ServiceFactory.php(48): OxidEsales\TestingLibrary\Services\ShopInstaller\ShopInstaller->__construct(Object(OxidEsales\TestingLibrary\Services\Library\ServiceConfig))
#2 /var/www/html/vendor/oxid-esales/testing-library/library/ServiceCaller.php(146): OxidEsales\TestingLibrary\Services\ServiceFactory->createService('ShopInstaller')
#3 /var/www/html/vendor/oxid-esales/testing-library/library/ServiceCaller.php(88): OxidEsales\TestingLibrary\ServiceCaller->callLocalService('ShopInstaller')
#4 /var/www/html/vendor/oxid-esales/testing-library/library/Bootstrap/BootstrapBase.php(133): OxidEsales\TestingLibrary\ServiceCaller->callService('ShopInstaller')
#5 /var/www/html/vendor/oxid-esales/testing-library/library/Bootstrap/BootstrapBase.php(46): OxidEsales\TestingLibrary\Bootstrap\BootstrapBase->installShop()
#6 /var/www/html/vendor/oxid-esales/testing-library/library/Bootstrap/UnitBootstrap.php(20): OxidEsales\TestingLibrary\Bootstrap\BootstrapBase->init()
#7 /var/www/html/vendor/oxid-esales/testing-library/bootstrap.php(34): OxidEsales\TestingLibrary\Bootstrap\UnitBootstrap->init()
#8 /var/www/html/vendor/phpunit/phpunit/src/Util/Fileloader.php(64): include_once('/var/www/html/v...')
#9 /var/www/html/vendor/phpunit/phpunit/src/Util/Fileloader.php(48): PHPUnit\Util\Fileloader::load('/var/www/html/v...')
#10 /var/www/html/vendor/phpunit/phpunit/src/TextUI/Command.php(991): PHPUnit\Util\Fileloader::checkAndLoad('/var/www/html/v...')
0000011 /var/www/html/vendor/phpunit/phpunit/src/TextUI/Command.php(786): PHPUnit\TextUI\Command->handleBootstrap('/var/www/html/v...')
0000012 /var/www/html/vendor/phpunit/phpunit/src/TextUI/Command.php(159): PHPUnit\TextUI\Command->handleArguments(Array)
0000013 /var/www/html/vendor/phpunit/phpunit/src/TextUI/Command.php(148): PHPUnit\TextUI\Command->run(Array, true)
0000014 /var/www/html/vendor/phpunit/phpunit/phpunit(53): PHPUnit\TextUI\Command::main()
0000015 {main}Failed to install shop with message: Could not connect to 'db' with user 'oxid'

#0 /var/www/html/vendor/oxid-esales/testing-library/library/Services/ShopInstaller/ShopInstaller.php(54): OxidEsales\TestingLibrary\Services\Library\DatabaseHandler->__construct(Object(OxidEsales\Eshop\Core\ConfigFile))
#1 /var/www/html/vendor/oxid-esales/testing-library/library/Services/ServiceFactory.php(48): OxidEsales\TestingLibrary\Services\ShopInstaller\ShopInstaller->__construct(Object(OxidEsales\TestingLibrary\Services\Library\ServiceConfig))
#2 /var/www/html/vendor/oxid-esales/testing-library/library/ServiceCaller.php(146): OxidEsales\TestingLibrary\Services\ServiceFactory->createService('ShopInstaller')
#3 /var/www/html/vendor/oxid-esales/testing-library/library/ServiceCaller.php(88): OxidEsales\TestingLibrary\ServiceCaller->callLocalService('ShopInstaller')
#4 /var/www/html/vendor/oxid-esales/testing-library/library/Bootstrap/BootstrapBase.php(133): OxidEsales\TestingLibrary\ServiceCaller->callService('ShopInstaller')
#5 /var/www/html/vendor/oxid-esales/testing-library/library/Bootstrap/BootstrapBase.php(46): OxidEsales\TestingLibrary\Bootstrap\BootstrapBase->installShop()
#6 /var/www/html/vendor/oxid-esales/testing-library/library/Bootstrap/UnitBootstrap.php(20): OxidEsales\TestingLibrary\Bootstrap\BootstrapBase->init()
#7 /var/www/html/vendor/oxid-esales/testing-library/bootstrap.php(34): OxidEsales\TestingLibrary\Bootstrap\UnitBootstrap->init()
#8 /var/www/html/vendor/phpunit/phpunit/src/Util/Fileloader.php(64): include_once('/var/www/html/v...')
#9 /var/www/html/vendor/phpunit/phpunit/src/Util/Fileloader.php(48): PHPUnit\Util\Fileloader::load('/var/www/html/v...')
#10 /var/www/html/vendor/phpunit/phpunit/src/TextUI/Command.php(991): PHPUnit\Util\Fileloader::checkAndLoad('/var/www/html/v...')
0000011 /var/www/html/vendor/phpunit/phpunit/src/TextUI/Command.php(786): PHPUnit\TextUI\Command->handleBootstrap('/var/www/html/v...')
0000012 /var/www/html/vendor/phpunit/phpunit/src/TextUI/Command.php(159): PHPUnit\TextUI\Command->handleArguments(Array)
0000013 /var/www/html/vendor/phpunit/phpunit/src/TextUI/Command.php(148): PHPUnit\TextUI\Command->run(Array, true)
0000014 /var/www/html/vendor/phpunit/phpunit/phpunit(53): PHPUnit\TextUI\Command::main()
0000015 {main}root@a59c9b619382:/var/www/html# 


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7109 [OXID eShop (all versions)] 1. ----- eShop frontend ----- minor always 2020-03-16 11:30 2020-03-27 14:42
Reporter: andrefatchip Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.2.0-rc.2  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version: 6.2.0  
    Target Version: 6.2.0  
Theme: Flow
Browser: Firefox
PHP Version: 7.1
Database Version: 5.7
Summary: Using guest account leads to alternating missing payments (or not) while checkout
Description: If one places an order with guest account, an empty payment list can appear. Reason seems to be the missing user group (See reproduction)
Tags:
Steps To Reproduce: * Install shop via composer create-project --no-dev oxid-esales/oxideshop-project ox620 dev-b-6.2-rc-ce
* Do not change any settings
* Place an order as guest
* On Payment select click back and then forward -> No payment selection available, User has not user group
* Again click back and then forward -> Payment selection reappears, User is in group "Inlandkunden"
* Rinse and repeat the issue disappears/reappears alternating
Additional Information: Using a guest account leads to alternately missing payment methods.
This behavior has already been escalated to the shop development and will be fixed with the release of OXID eShop 6.2.0 at the end of March.

 - es -
Attached Files: rc2.JPG (69,246 bytes) 2020-03-16 13:14
https://bugs.oxid-esales.com/file_download.php?file_id=1796&type=bug
Notes
(0013156)
QA   
2020-03-16 13:14   
the behavior could be simulated in a freshly installed OXID Enterprise Edition 6.2.0-rc.2

- es -
(0013165)
andrefatchip   
2020-03-27 12:47   
Hi,

great you solved this one. However, our QA would like to also test this before final release. Which method is recommended here to get the patch into own shop:
https://github.com/OXID-eSales/oxideshop_ce/commit/40860813401b5a4f370e980650f5315ab9588415

Best would be composer of course, but I cannot find the right tag:

vagrant@php71m57:/var/www/html$ composer create-project --no-dev oxid-esales/oxideshop-project OX649 dev-b-6.2-ce

                                                                                   
  [InvalidArgumentException]
  Could not find package oxid-esales/oxideshop-project with version dev-b-6.2-ce.
                                                                                   

create-project [-s|--stability STABILITY] [--prefer-source] [--prefer-dist] [--repository REPOSITORY] [--repository-url REPOSITORY-URL] [--dev] [--no-dev] [--no-custom-installers] [--no-scripts] [--no-progress] [--no-secure-http] [--keep-vcs] [--remove-vcs] [--no-install] [--ignore-platform-reqs] [--] [<package>] [<directory>] [<version>]

Thanks in advance and stay healthy @all


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5524 [OXID eShop (all versions)] 6. ------ Setup ------- minor always 2013-11-21 16:16 2020-03-26 14:52
Reporter: Stefan_Werner Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: resolved Product Version: 4.8.0 / 5.1.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.1.6  
    Target Version: Patch for 6.1  
Theme: Not defined
Browser: All
PHP Version: Not defined
Database Version: Not defined
Summary: Links in license conditions during setup are wrong
Description: Chapter 4.4

http://www.oxid-esales.com/de/eshop/ => 404 Page not found
Tags: Setup
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0010178)
martinwegele   
2014-09-23 15:08   
new link: https://www.oxid-esales.com/en/products/downloads/knowledge.html
or more specific: https://www.oxid-esales.com/fileadmin/files/Public/CorporateMarketing/Downloads/oxid-eshop-thirdpartylicenses.pdf
(0013055)
afshar5152   
2019-11-22 14:58   
The link was replaced with following link:
https://oxidforge.org/en/list-of-3rd-party-licenses


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6606 [OXID eShop (all versions)] 4.07. Source code, Test major always 2017-03-21 15:59 2020-03-26 14:50
Reporter: henrik.steffen Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 4.10.3 / 5.3.3  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.1.6  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Blacklisted by example.com / point checkAllowUrlFopen() to another destination in oxsysrequirements.php
Description: Way back in 2009 the url for testing if fsockopen is available on a host system was changed to test if www.example.com can be reached.

Well... we actually got blacklisted by example.com. They do not accept any IP-traffic from our whole network infrastructure anymore.

Probably due to the reason that we host lots of OXID eShops in our network, which all query www.example.com everytime an admin logs into the back-end.

Can you please modify the checkAllowUrlFopen() somehow, so it would either check for a different URL, or maybe even just localhost ? Or maybe amazon.com or google.com ? Or maybe the check can be disabled or configured to a custom URL ?

Right now, all our hosted shops show a "!" symbol in the setup routine and also when looking at the system requirements page for the check "allow_url_fopen or fsockopen on Port 80"
Tags: Solution Provided
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012000)
henrik.steffen   
2017-03-21 16:00   
ah, by the way, this has been an issue way back in 2009:

0001033
(0012005)
alfredbez   
2017-03-28 16:23   
PR: https://github.com/OXID-eSales/oxideshop_ce/pull/556
(0013063)
anton.fedurtsya   
2019-12-02 13:25   
Merged with a little adjustement.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7051 [OXID eShop (all versions)] 1.01. Products (product, categories, manufacturer, promotions etc.) minor always 2019-11-11 08:50 2020-03-25 16:51
Reporter: ivoba Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.1.5  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: Patch for 6.1  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: resetFilter function is missing
Description: When resetting Filter on ArticleList an error occurs:
ERROR_MESSAGE_SYSTEMCOMPONENT_FUNCTIONNOTFOUND resetFilter ["[object] (OxidEsales\\Eshop\\Core\\Exception\\SystemComponentException(code: 0):

In master branch resetFilter function is present:
https://github.com/OXID-eSales/oxideshop_ce/blob/9d4e24a16d63f159d9044c1c28791e61837c2d71/source/Application/Controller/ArticleListController.php#L351

In 6.1.5 its not.
Please make a release with a fix for this.
Tags: Attributes
Steps To Reproduce: Use Article attributes.
Go to Article List, use filters and reset filters.
Additional Information:
Attached Files:
Notes
(0013042)
QA   
2019-11-11 14:53   
-MK
(0013052)
ivoba   
2019-11-20 10:17   
PR is send: https://github.com/OXID-eSales/oxideshop_ce/pull/739


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7079 [OXID eShop (all versions)] 2.3. Extensions (modules, themes) minor always 2020-01-29 13:32 2020-03-23 11:52
Reporter: michael_keiluweit Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.2.0-rc.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.2.0  
    Target Version: 6.2.0  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Module event information is saved repeatedly to oxconfig.aModuleEvents
Description: When reactivating a module which has events, the event information for that module will be written to the config field oxconfig.aModuleEvents, although the information was already saved.
Tags: Module
Steps To Reproduce: 1. Add this to index.php:
var_dump(\OxidEsales\Eshop\Core\Registry::getConfig()->getConfigParam('aModuleEvents'));

2. Press F5 and have a look at the result.
3. Switch to the console and execute those commands
3.1.
vendor/bin/oe-console oe:module:activate oepaypal

3.2.
vendor/bin/oe-console oe:module:deactivate oepaypal

3.3.
vendor/bin/oe-console oe:module:activate oepaypal

4. Switch back to the frontend and press F5 again. You will have multiple entries for the events like this:
  0 => 
    array (size=2)
      'onActivate' => string '\OxidEsales\PayPalModule\Core\Events::onActivate' (length=48)
      'onDeactivate' => string '\OxidEsales\PayPalModule\Core\Events::onDeactivate' (length=50)
  1 => 
    array (size=2)
      'onActivate' => string '\OxidEsales\PayPalModule\Core\Events::onActivate' (length=48)
      'onDeactivate' => string '\OxidEsales\PayPalModule\Core\Events::onDeactivate' (length=50)


It is reproducible with each module which has events.
Additional Information:
Attached Files:
Notes
(0013106)
QA   
2020-01-29 16:27   
-MK


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7084 [OXID eShop (all versions)] 4.06. Language and translations minor always 2020-02-06 12:27 2020-03-02 16:44
Reporter: Helmut L. Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: OXID in _set tables has wrong collation
Description: In the main tables the OXID column is always created with "CHARACTER SET latin1 COLLATE latin1_general_ci", but in the _set tables the OXID column is created without a specified character set and collation, thus using the default of the table which is normally utf8.
This will result in having a latin1 column compared with a utf8 column in queries, which causes MySQL to convert the value from one of the columns to the charset of the other column. For smaller tables this might not be a big performance problem, but for big tables it will definitely slow down the queries.
Tags:
Steps To Reproduce: Add languages in the admin until the _set tables are created.
Additional Information: The corresponding code is in /vendor/oxid-esales/oxideshop-ce/source/Core/DbMetaDataHandler.php, line 223
Attached Files:
Notes
(0013115)
QA   
2020-02-06 14:15   
Reproduced.

1. edit config.inc.php and add this command: $this->iLangPerTable = 2;
2. goto admin, create one new language
3. compare oxarticles.oxid with oxarticles_set1.oxid. The field oxid from oxarticles has the collation latin1_general_ci, whereby the field oxid from oxarticles_set1 is utf8_general_ci.

-MK


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7103 [OXID eShop (all versions)] 4.12. Subshop handling minor always 2020-03-02 16:03 2020-03-02 16:36
Reporter: mikkelfilla Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: inheritance of SEO meta tags to sub shops does not work
Description: The inheritance of SEO meta tags to sub shops does not work. The fields remain empty, although they were filled in the parent shop.

A manual editing in sub shop is not possible by activating the inheritance.

Everything with inherited SEO meta tags is affected like:
Articles, Categories, Distributors, Brands/Manufacturers
Tags:
Steps To Reproduce: 1. insert meta tags in an article via the tab SEO
2. create a sub shop that inherits from the parent shop
3. see the meta tags in an article via the tab SEO are empty/not editable
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6708 [OXID eShop (all versions)] 2.7. Customer info feature always 2017-10-11 16:38 2020-02-27 11:27
Reporter: oxid-Christian.Wolf Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: Next Minor Version  
    Target Version: Next Minor Version  
Theme: Azure
Browser: Firefox
PHP Version: 5.6
Database Version: 5.6
Summary: Multishop Feature makes it impossible to have shopspecific news
Description: Any Subshop marked as a multishop, automaticly copies news cenerated in any other shop.

This makes it impossible to have news for just 1 subshop while still having it be a multishop.
Tags:
Steps To Reproduce: I used the following Setup:
Mastershop
Subshop A inherits everything from A + is multishop
Subshop B inherits from A
Subshop C is multishop
Subshop D is empty subshop, not related to any other

Ater changing default news in Master every shop, except D chaged news too.
Here shop C should not chance news, but the multishop feature makes it do that.
Additional Information: You need to test with Azure Theme on a standardshop, because flow dropped the news element.
Attached Files:
Notes
(0013061)
afshar5152   
2019-11-29 13:14   
We decided to create a new option for users to choose if they want their multishop to inherit all the news from other shops or not. We will have this option in 6.3 version.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5526 [OXID eShop (all versions)] 2.7. Customer info major always 2013-11-22 13:55 2020-02-27 11:27
Reporter: midiane Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 4.8.0 / 5.1.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: Next Minor Version  
    Target Version: Next Minor Version  
Theme: Azure
Browser: All
PHP Version: Not defined
Database Version: Not defined
Summary: not working actions and promotions
Description: The some of the actions and promotions are not working in the newer Version of OXID, because they become obsolete and have been used in the Basic Theme, which is no longer available for the newer OXID-Version.

Because of that, it would be the best if they would be deleted:
Actions:
-Startseite unten (only for Basic Theme)
-Topangebot Startseite (only for Basic Theme)
-Angebot der Woche (only for Basic Theme)

Promotions:
-All promotions, also the ones, that are coming from the Demo-Data

The Action "Schnäppchen" should be renamed as "Angebot der Woche", because this is the labling in the Frontend as well.

All this old actions and promotions are confusing the customers ;)
Tags: Promotion
Steps To Reproduce:
Additional Information:
Attached Files: promotion_list.zip (4,371 bytes) 2013-11-22 14:17
https://bugs.oxid-esales.com/file_download.php?file_id=1216&type=bug
Notes
(0013028)
afshar5152   
2019-10-29 14:34   
(Last edited: 2019-11-28 11:34)
Startseite unten ('OXSTART') promotion was deleted from version 6.3.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6477 [OXID eShop (all versions)] 4.07. Source code, Test minor always 2016-08-12 15:09 2020-02-26 09:13
Reporter: stg Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 4.10.0 / 5.3.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.1.0  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: 5.6
Database Version: Not defined
Summary: oxUtilsServer::getOxCookie has side effects on $_COOKIE
Description: getOxCookie uses the following line to clear Special Characters from Cookie Values:

$sValue = oxRegistry::getConfig()->checkParamSpecialChars($_COOKIE[$sName]);

checkParamSpecialChars uses call by reference and thus changes $_COOKIE. In certain cases (json_data f.e.), this happens whith every call.
Tags:
Steps To Reproduce: Insert the following code somewhere in your shop:

    $aTestData = array(
        "title" => "Jau!",
        "band" => "Fury in the Slaughterhouse",
        "year" => 1990
    );

    $oUtilsServer = oxRegistry::get("oxUtilsServer");
    $oUtilsServer->setOxCookie('wont_forget', json_encode($aTestData), time() + 600, '/');

    var_export($_COOKIE['wont_forget']); echo "\n";
    var_export($oUtilsServer->getOxCookie('wont_forget')); echo "\n";
    var_export($oUtilsServer->getOxCookie('wont_forget')); echo "\n";
    var_export($oUtilsServer->getOxCookie('wont_forget')); echo "\n";
    var_export($oUtilsServer->getOxCookie('wont_forget')); echo "\n";
    var_export($oUtilsServer->getOxCookie('wont_forget')); echo "\n";
    var_export($oUtilsServer->getOxCookie('wont_forget')); echo "\n";
    var_export($_COOKIE['wont_forget']); echo "\n";
Additional Information: The code replaces HTML special characters and produces something like the following:

'{"title":"Jau!","band":"Fury in the Slaughterhouse","year":1990}'
'{"title":"Jau!","band":"Fury in the Slaughterhouse","year":1990}'
'{"title":"Jau!","band":"Fury in the Slaughterhouse","year":1990}'
'{"title":"Jau!","band":"Fury in the Slaughterhouse","year":1990}'
'{"title":"Jau!","band":"Fury in the Slaughterhouse","year":1990}'
'{&quot;title&quot;:&quot;Jau!&quot;,&quot;band&quot;:&quot;Fury in the Slaughterhouse&quot;,&quot;year&quot;:1990}'
'{&amp;quot;title&amp;quot;:&amp;quot;Jau!&amp;quot;,&amp;quot;band&amp;quot;:&amp;quot;Fury in the Slaughterhouse&amp;quot;,&amp;quot;year&amp;quot;:1990}'
'{&amp;quot;title&amp;quot;:&amp;quot;Jau!&amp;quot;,&amp;quot;band&amp;quot;:&amp;quot;Fury in the Slaughterhouse&amp;quot;,&amp;quot;year&amp;quot;:1990}'
Attached Files:
Notes
(0011732)
stg   
2016-08-12 16:38   
Same issue as id=5307

Sorry for duplicating.
(0011738)
mikkelfilla   
2016-08-15 13:42   
https://bugs.oxid-esales.com/view.php?id=5307
(0011822)
robert blank   
2016-10-05 14:45   
The bugfix introduced a BC break and must be reverted.

This bug cannot be fixed in v5.3
The right way to fix this bug in v6.0 is to create a separate method in v5.3 and deprecate the current method checkParamSpecialChars().
In v6.0 do not change the current method, but replace it by the new one and delete the current method checkParamSpecialChars()


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5307 [OXID eShop (all versions)] 4. ------ eShop Core ------- major always 2013-07-24 11:24 2020-02-26 09:12
Reporter: Hendrik Becker Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: resolved Product Version: 4.7.6 / 5.0.6  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.0.0  
    Target Version:  
Theme: Not defined
Browser: All
PHP Version: Not defined
Database Version: Not defined
Summary: Cookies are changed by checkParamSpecialChars's several times
Description: Assumption: The Browser sends a cookie named "mycookie" containing the value "M&M"


If I access a cookie value like this: oxRegistry::get("oxUtilsServer")->getOxCookie('mycookie')
I will receive the value: "M&M"

If I access the cookie again like this: oxRegistry::get("oxUtilsServer")->getOxCookie('mycookie')
I will receive the value: "M&M"

And if I do that again, I will receive: "M&M"

And so on ...


This is, because the global $_COOKIE array is manipulated on each oxRegistry::get("oxUtilsServer")->getOxCookie('mycookie')

The method getOxCookie() in core/oxutilsserver.php calls on line 264: $sValue = oxRegistry::getConfig()->checkParamSpecialChars($_COOKIE[$sName]);

The method checkParamSpecialChars() in core/oxconfig.php takes the $sValue parameter by reference and changes its value on line 825.
Tags:
Steps To Reproduce:
Additional Information: I suggest to leave cookie values unchanged. At least in my case I don't want to receive an checkParamSpecialChars'ed version of the cookie.

Currently my workaround is simple. I simply don't access a certain cookie value, but call oxRegistry::get("oxUtilsServer")->getOxCookie() (without parameter) to receive the complete cookie array. Then I can access the certain key.
Attached Files:
Notes
(0008935)
Hendrik Becker   
2013-07-24 11:28   
It seems like this bug tracker removed 1 level of &amp; from my example.

So here is the example again (hopefully) correct:

--- START ---

If I access a cookie value like this: oxRegistry::get("oxUtilsServer")->getOxCookie('mycookie')
I will receive the value: "M&amp;M"

If I access the cookie again like this: oxRegistry::get("oxUtilsServer")->getOxCookie('mycookie')
I will receive the value: "M&amp;amp;M"

And if I do that again, I will receive: "M&amp;amp;amp;M"

And so on ...


--- STOP ---
(0010281)
Aivaras   
2014-10-28 09:52   
+1. Same problem here.

Easy fix (replace getOxCookie in oxutilsserver.php):

public function getOxCookie($sName = null)
    {
        $sValue = null;
        if ($sName && isset($_COOKIE[$sName])) {
            $sRawValue = $_COOKIE[$sName];
            $sValue = oxRegistry::getConfig()->checkParamSpecialChars($sRawValue);
        } elseif ($sName && !isset($_COOKIE[$sName])) {
            $sValue = isset($this->_sSessionCookies[$sName]) ? $this->_sSessionCookies[$sName] : null;
        } elseif (!$sName && isset($_COOKIE)) {
            $sValue = $_COOKIE;
        }

        return $sValue;
    }
(0011807)
gregor.hyneck   
2016-09-29 07:39   
(Last edited: 2016-09-29 07:40)
Currently I'm working on https://github.com/OXID-eSales/oxideshop_ce/pull/460 which solves this issue.

(0011823)
robert blank   
2016-10-05 14:47   
The bugfix introduced a BC break and must be reverted.

This bug cannot be fixed in v5.3
The right way to fix this bug in v6.0 is to create a separate method in v5.3 and deprecate the current method checkParamSpecialChars().
In v6.0 do not change the current method, but replace it by the new one and delete the current method checkParamSpecialChars()


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7100 [OXID eShop (all versions)] 1.02. Price calculations (discounts, coupons, additional costs etc.) minor always 2020-02-21 17:08 2020-02-24 08:59
Reporter: nitin.singh Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: voucher doesn't work in case same voucher number been used for multiple voucherseries
Description: We had one use case where customer used some voucher number for multiple voucherseries and one voucherseries got expired and second voucherseries is still live. Then, if you use related voucher then it doesn't work and give you error.
Tags:
Steps To Reproduce: Added by QA - SG - :
1. Add Serie "Test 1" with code "test"
2. Add Serie "Test 2" with code "test"
3. Set Test 1 to be deactivated
4. the code "test" won't be accepted.

Additional Information:
Attached Files: oxps_patches_oxvoucher.php (6,329 bytes) 2020-02-21 17:11
https://bugs.oxid-esales.com/file_download.php?file_id=1788&type=bug
Notes
(0013134)
nitin.singh   
2020-02-21 17:11   
We have fixed this issue with attached patch.
(0013135)
QA   
2020-02-24 08:59   
For me personally it is more a bug to allow the same code to be used. If both series are active, how can the shop know with series should be assigned?
Therefore to prevent such behavior, I recommend forbidding usage of the same code.
QA - SG -


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7099 [OXID eShop (all versions)] 4.07. Source code, Test minor always 2020-02-20 16:03 2020-02-20 16:05
Reporter: QA Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.2.0-rc.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: The package oxid-esales/oxideshop-ce contains demo data
Description: The folder out/pictures of the package oxid-esales/oxideshop-ce contains demo data. Actually those files belong to the package oxideshop-demodata-ce or the theme package.
Tags: Composer
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0013131)
QA   
2020-02-20 16:04   
-MK


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7098 [OXID eShop (all versions)] 4.07. Source code, Test minor always 2020-02-20 15:13 2020-02-20 16:05
Reporter: QA Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.2.0-rc.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: composer does overwrite files which are often adapted
Description: After executing the commands "composer update" or "composer install" at least the files offline.html, favicon.ico, .htaccess, robots.txt and nopic.jpg are always overwritten.
Better would be if the files are only copied to the directory when the target file doesn't exist. And do nothing when the file is already there. So the changes are not gone and doesn't need to get restored all the time.
Tags: Composer
Steps To Reproduce: 1. Make changes to one or more or all of the listed files.
2. Execute composer update or composer install
3. Have a look at your changes. They are gone.
Additional Information: Please note that those files have in common that they get in most cases customized. Maybe there are even more of those "customized"-like files.
Idea: An extendable blacklist of files which will not be overwritten after executing composer install/update.
Attached Files:
Notes
(0013130)
QA   
2020-02-20 15:13   
-MK


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3101 [OXID eShop (all versions)] 1.02. Price calculations (discounts, coupons, additional costs etc.) major always 2011-07-29 14:53 2020-02-12 14:35
Reporter: michael_keiluweit Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 4.5.0 revision 34568  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: All
Browser: All
PHP Version: Not defined
Database Version: Not defined
Summary: delivery cost is not recalculated after discount in basket
Description: first, we have a delivery for free rule for a basket with final value of 150€.
If the final value of the basket is bigger than 150€, delivery cost is free. Without discount it works as is should.
But if a discount reduce the final price - for example, to 140€ - the delivery cost is still free. Normally it should set to 10€ delivery cost, because the final value is fewer than 150€.

The solution:
Implement additional option for calculating the Shipping Costs with Discounts included. Means - current option in Shipping cost rules "Price" should be replaced with two options:
1. Order Value. When this option is selected, when counting costs of Shipping (also checks availability of Shipping rule) it should valuate only the Total Value of the Order, which includes only Product prices multiplied by Quantities (before the Discounts and Additional Costs included). Currently it works the same way as described.
2. Discounted Order Value. When this option is selected, during calculation of shipping costs (and checking availability of Shipping rules), it should count the Order value WITH the all discounts deducted (discounts and coupons also), but before the Additional costs (such costs like Payment, Greeting Card, etc. should not be counted).

Also need to change description in Help text to proper one, which explains both options in details.
Tags: Calculations, Delivery, Discount, Order Recalculation
Steps To Reproduce: make a discount 11%
set two delivery sets:

1. < 150 -> 10 € delivery cost.
2. > 150 -> 0 € delivery cost.

add 6x article number 3552-1. (27,90 €)

Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7090 [OXID eShop (all versions)] 1. ----- eShop frontend ----- minor always 2020-02-11 12:57 2020-02-12 08:08
Reporter: Hal_platzke Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: All
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Oxscript handles relative URI without protocol as local file
Description: If you pass "//cdnjs.cloudflare.com/ajax/libs/jquery/3.4.1/jquery.slim.js" as include for oxscript,
it gets handle as a local file and wont load.

A relative URI without protocol is valid, see RFC 3986 Section 4.2:
http://www.ietf.org/rfc/rfc3986.txt

possible fix:
in file: OxidEsales\EshopCommunity\Core\ViewHelper\JavaScriptRegistrator.php:50
replace regex: #^https?://#
with: /^(https?:\/\/|\/\/)/
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0013124)
QA   
2020-02-12 08:08   
-MK


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6283 [OXID eShop (all versions)] 1.02. Price calculations (discounts, coupons, additional costs etc.) minor always 2015-12-08 08:09 2020-02-11 13:26
Reporter: rhuelsberg Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.0.0  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Voucher vat calculation
Description: If you create a voucher for 1 of 2 articles in a basket.
The voucher vat will be calculated from all articles.
Tags:
Steps To Reproduce: 1. Create a voucher on Category 1 with 15% (TEST15)
2. Create a basket with one article from Category 1 and one article from Category 2
3. Enter the Voucher Code TEST15

Watch out the image file: oxid.png from today.
We found these bug at OXID EE 5.1.4 and reduce it in OXID PE 4.9.6.
Additional Information: (i) 19% vat in Germany.

Article 1 / Category 1: (105 € / 100 * 15) / 119 * 19 = 2,51 €
Article 2 / Category 2: (129 € / 100 * 15) / 119 * 19 = 3,09 €

Real voucher vat: 2,51 €
OXID voucher vat: 5,60 €
Attached Files: OXID.PNG (92,444 bytes) 2015-12-08 08:09
https://bugs.oxid-esales.com/file_download.php?file_id=1403&type=bug
OXID2.PNG (281,449 bytes) 2015-12-08 08:11
https://bugs.oxid-esales.com/file_download.php?file_id=1404&type=bug
Notes
(0011424)
rhuelsberg   
2016-01-11 07:26   
Any updates?
(0011437)
Adrian.Kirchner   
2016-01-16 18:53   
Fixed in PR https://github.com/OXID-eSales/oxideshop_ce/pull/311
(0013085)
benjamin.joerger   
2020-01-03 09:39   
Issue was solved in OXID eShop 6.0.0


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7085 [OXID eShop (all versions)] 4.09. SEO, SEO URL minor always 2020-02-06 14:23 2020-02-10 10:02
Reporter: ieickenbusch Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Seo url for inactive or not existent language views are calculated
Description: In wave theme alternate language urls are rendered like this:

        [{if $oView->isLanguageLoaded()}]
            [{assign var="oConfig" value=$oViewConf->getConfig()}]
            [{foreach from=$oxcmp_lang item=_lng}]
                [{if $_lng->id == $oConfig->getConfigParam('sDefaultLang')}]
                    <link rel="alternate" hreflang="x-default" href="[{$_lng->link}]"/>
                [{/if}]
                <link rel="alternate" hreflang="[{$_lng->abbr}]" href="[{$_lng->link|oxaddparams:$oView->getDynUrlParams()}]"/>
            [{/foreach}]
        [{/if}]

But if there is a cms page which has inactive or not existent language, the url seo url is calculated like this:
en/oxid/

It is also saved into oxseo table. Even the language switch in header show wrong the wrong seo url. In my opinion it should not be rendered as alternate link and in language switch it should lead to the startpage.
Tags:
Steps To Reproduce: Setup demo shop.
Activate english as second language.
Build new CMS page without english copy.
Check language switch in header and alternate link tag in output source.
Check oxseo for new entry.
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7087 [OXID eShop (all versions)] 4.06. Language and translations minor always 2020-02-06 17:53 2020-02-07 10:20
Reporter: Helmut L. Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: views for multi language tables with lowercase oxid column can't be created
Description: If you have created an own multi language table that has a lowercase oxid column the views can't be created.
In the _set tables the oxid column is always created in uppercase and when the columns for the view are collected the lowercase and the uppercase column are both added to the view, which results in a duplicate column name error from MySQL.
Tags:
Steps To Reproduce: Create a multilanguage table with a lowercase oxid column:
 create table test (
  oxid char(32) CHARACTER SET latin1 COLLATE latin1_general_ci not null,
  test_field varchar(10),
  test_field_1 varchar(10),
  primary key (oxid)
 );

~ Start: Added by MK ~

edit config.inc.php
change $this->aMultiLangTables = null; to $this->aMultiLangTables = ['test'];
add $this->iLangPerTable = 2;

~ End: Added by MK ~

Add languages to the shop until the _set tables are created.

Try to generate the views:
php vendor/oxid-esales/oxideshop-db-views-generator/generate_views.php
Additional Information: This problem exists only since OXID 6, in the older versions there was already a fix for it.

In the older versions the column name was always converted to uppercase:
/core/adodblite/adodbSQL_drivers/mysqli/mysqli_meta_module.inc, line 287

Since OXID 6, the column name is no longer converted to uppercase:
/vendor/oxid-esales/oxideshop-ce/source/Core/Database/Adapter/Doctrine/Database.php, line 1151

Added by MK: Exception message:
[2020-02-07 10:17:49] OXID Logger.ERROR: Duplicate column name 'OXID' ["[object] (OxidEsales\\Eshop\\Core\\Exception\\DatabaseErrorException(code: 1060): Duplicate column name 'OXID' at /var/www/html/vendor/oxid-esales/oxideshop-ce/source/Core/Database/Adapter/Doctrine/Database.php:938, Doctrine\\DBAL\\Exception\\NonUniqueFieldNameException(code: 0): An exception occurred while executing 'CREATE OR REPLACE SQL SECURITY INVOKER VIEW `oxv_test` AS SELECT test.oxid,test.test_field,test.test_field_1,test.test_field_2,test_set1.OXID,test_set1.test_field_3 FROM test LEFT JOIN test_set1 USING (OXID) ':\n\nSQLSTATE[42S21]: Column already exists: 1060 Duplicate column name 'OXID' at /var/www/html/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php:76, Doctrine\\DBAL\\Driver\\PDOException(code: 42S21): SQLSTATE[42S21]: Column already exists: 1060 Duplicate column name 'OXID' at /var/www/html/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:59, PDOException(code: 42S21): SQLSTATE[42S21]: Column already exists: 1060 Duplicate column name 'OXID' at /var/www/html/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:57)\n[stacktrace]\n#0 /var/www/html/vendor/oxid-esales/oxideshop-ce/source/Core/Database/Adapter/Doctrine/Database.php(779): OxidEsales\\EshopCommunity\\Core\\Database\\Adapter\\Doctrine\\Database->convertException(Object(Doctrine\\DBAL\\Exception\\NonUniqueFieldNameException))\n#1 /var/www/html/vendor/oxid-esales/oxideshop-ce/source/Core/Database/Adapter/Doctrine/Database.php(576): OxidEsales\\EshopCommunity\\Core\\Database\\Adapter\\Doctrine\\Database->executeUpdate('CREATE OR REPLA...', Array)\n#2 /var/www/html/vendor/oxid-esales/oxideshop-ce/source/Application/Model/Shop.php(360): OxidEsales\\EshopCommunity\\Core\\Database\\Adapter\\Doctrine\\Database->execute('CREATE OR REPLA...')\n#3 /var/www/html/vendor/oxid-esales/oxideshop-ce/source/Application/Model/Shop.php(141): OxidEsales\\EshopCommunity\\Application\\Model\\Shop->_runQueries()\n#4 /var/www/html/vendor/oxid-esales/oxideshop-ce/source/Core/DbMetaDataHandler.php(569): OxidEsales\\EshopCommunity\\Application\\Model\\Shop->generateViews(false, Array)\n#5 /var/www/html/vendor/oxid-esales/oxideshop-ce/source/Application/Controller/Admin/ToolsList.php(36): OxidEsales\\EshopCommunity\\Core\\DbMetaDataHandler->updateViews()\n#6 /var/www/html/vendor/oxid-esales/oxideshop-ce/source/Core/Controller/BaseController.php(524): OxidEsales\\EshopCommunity\\Application\\Controller\\Admin\\ToolsList->updateViews()\n#7 /var/www/html/vendor/oxid-esales/oxideshop-ce/source/Core/ShopControl.php(332): OxidEsales\\EshopCommunity\\Core\\Controller\\BaseController->executeFunction('updateViews')\n#8 /var/www/html/vendor/oxid-esales/oxideshop-ce/source/Core/ShopControl.php(274): OxidEsales\\EshopCommunity\\Core\\ShopControl->executeAction(Object(OxidEsales\\Eshop\\Application\\Controller\\Admin\\ToolsList), 'updateViews')\n#9 /var/www/html/vendor/oxid-esales/oxideshop-ce/source/Core/ShopControl.php(137): OxidEsales\\EshopCommunity\\Core\\ShopControl->_process('OxidEsales\\\\Esho...', 'updateViews', NULL, NULL)\n#10 /var/www/html/vendor/oxid-esales/oxideshop-ce/source/Core/Oxid.php(26): OxidEsales\\EshopCommunity\\Core\\ShopControl->start()\n#11 /var/www/html/source/index.php(15): OxidEsales\\EshopCommunity\\Core\\Oxid::run()\n#12 /var/www/html/source/admin/index.php(11): require_once('/var/www/html/s...')\n#13 {main}\n"] []
Attached Files:
Notes
(0013118)
QA   
2020-02-07 10:18   
-MK


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6247 [OXID eShop (all versions)] 1.03. Basket, checkout process major always 2015-10-16 10:34 2020-02-07 08:06
Reporter: flowcontrol Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 4.9.4 / 5.2.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: All
Browser: All
PHP Version: 5.4
Database Version: 5.6
Summary: SQL Bug in oxDeliverySetList::_getFilterSelect()
Description: in Line 158 it reads:
if(EXISTS(select 1 from oxobject2delivery, $sCountryTable where $sCountryTable.oxid=oxobject2delivery.oxobjectid and oxobject2delivery.oxdeliveryid=$sTable.OXID and oxobject2delivery.oxtype='oxdelset' LIMIT 1)

Shouldn't it be:
if(EXISTS(select 1 from oxobject2delivery, $sCountryTable where $sCountryTable.oxid=oxobject2delivery.oxobjectid and oxobject2delivery.oxdeliveryid=$sTable.OXID and oxobject2delivery.oxtype='oxcountry' LIMIT 1),
Tags: EE, MySQL
Steps To Reproduce: - create a EE Shop with two Subshops
- delivery and deliverysets to germany and austria
- everything ist configured correct
- go shopping in the shop frontend
- ship to austria
- shop says there is no shipping configuration for this country
Additional Information:
Attached Files:
Notes
(0011261)
flowcontrol   
2015-10-16 10:37   
And i missed line 152, this should read:
  152 $sCountrySql = $sCountryId ? "EXISTS(select oxobject2delivery.oxid from oxobject2delivery where oxobject2delivery.oxdeliveryid=$sTable.OXID and oxobject2delivery.oxtype='oxcountry' and oxobject2delivery.OXOBJECTID=" . $oDb->quote($sCountryId) . ")" : '0';

instead of

  152 $sCountrySql = $sCountryId ? "EXISTS(select oxobject2delivery.oxid from oxobject2delivery where oxobject2delivery.oxdeliveryid=$sTable.OXID and oxobject2delivery.oxtype='oxdelset' and oxobject2delivery.OXOBJECTID=" . $oDb->quote($sCountryId) . ")" : '0';
(0011265)
QA   
2015-10-19 11:03   
I tried to reproduce in a locally installed OXID eShop Enterprise Edition, Version 5.2.5 shop, but didn't get the message "there is no shipping configuration for this country".

So maybe your delivery and deliverysets settings are not correct.
So please check settings or let us know the settings.
(0011271)
flowcontrol   
2015-10-20 10:39   
(Last edited: 2015-10-20 10:40)
it seems .sql files are not allowed to be uploaded, i pasted the sql for the configuration here: http://pastebin.com/k2fPxA4y
It is unlisted and will expire in one week from now.

(0011365)
matths   
2015-12-07 16:14   
Let 6282 be a duplicate or not.

First, the 'duplicate' ticket (this ticket) doesn't offer steps for a solution.

Else the mentioned blog article http://planet.oxidforge.org/2015/11/set-mysql-5-6-optimizer-setting-block_nested_loop-off-for-oxid-eshop-enterprise-edition.html offers some hint, which also doesn't lead to a result for us.

We tried to do:
SELECT @@optimizer_switch\G;
SET GLOBAL optimizer_switch='block_nested_loop=off';

But still, our query gets us an empty result. To be correct, if it's the first request of a database session, the correct result is returned. If executed later, it again does not work.

Maybe you could share more of your MySQL settings?

The other workaround could be to remove the "SELECT" before "if(EXISTS", unless you have arguments to not do so.

Br,
@matths
(0011369)
matths   
2015-12-07 16:53   
You could also point out, that you filled a bug for mysql with exactly the same result, that we get. Would have saved us time.

https://bugs.mysql.com/bug.php?id=79203
(0011527)
flowcontrol   
2016-04-08 13:03   
In our case we needed not only to set optimizer_switch='block_nested_loop=off', but also batched_key_access=on, mrr=on and mrr_cost_based=off. So the "fix" was:

SET optimizer_switch="block_nested_loop=off,batched_key_access=on,mrr=on,mrr_cost_based=off"

The real fix was to update to MySQL 5.7 ;-)
(0012045)
m0rb   
2017-04-24 16:08   
(Last edited: 2017-04-24 16:08)
The latest hint to do

'SET optimizer_switch="block_nested_loop=off,batched_key_access=on,mrr=on,mrr_cost_based=off"'

doesn't work for us. Is there any other solution than updating to MySQL 5.7?

(0012046)
matths   
2017-04-24 17:21   
@m0rb: to quote myself:

> The other workaround could be to remove the "SELECT" before "if(EXISTS", unless you have arguments to not do so.

<?php

class mod_mymod__oxdeliverysetlist extends mod_mymod__oxdeliverysetlist_parent
{
    protected function _getFilterSelect($oUser, $sCountryId)
    {
        $sQ = parent::_getFilterSelect($oUser, $sCountryId);

        // temporary fix for Bug introduced with MySQL 5.6
        // remove 'select' between 'and (' and 'if(EXISTS'
        $count = null;
        $sQ = preg_replace('/(and\\s\\(\\W*)(select\\W*)(if\\(EXISTS)/', '$1$3', $sQ, -1, $count);

        return $sQ;
    }
}
(0013116)
finnegan   
2020-02-06 22:52   
May I bring this topic up again?

We tested Oxid EE 6.1.5 on MySQL 5.5 - everything works fine.
On MySQL 5.6 the error is as described here. No deliveryset is found although 1 matching deliveryset exists.

The comments state that the problem could be solved by upgrading to MySQL 5.7.
BUT we found (on 2 different machines) that the error still exists on MySQL 5.7 in its default configuration.

When we edited my.cnf and added the optimizer_switch settings

optimizer_switch="block_nested_loop=off,batched_key_access=on,mrr=on,mrr_cost_based=off"

as described by user flowcontrol the query gave the correct result.
Since not all Oxid admins have the chance to fiddle with my.cnf it would be great if this problem could be resolved soon.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7083 [OXID eShop (all versions)] 1.05. Users trivial always 2020-02-06 07:12 2020-02-06 09:25
Reporter: Moehlis Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: acknowledged Product Version: 6.1.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: changeuser doesn't check raw password input
Description: When registering, using a password containing ">" is no problem.
But when changing email address in my-account, the password is not accepted.

Problem is located in OxidEsales\EshopCommunity\Core\InputValidator:checkLogin

is:
\OxidEsales\Eshop\Core\Registry::getConfig()->getRequestParameter('user_password');

should be:
\OxidEsales\Eshop\Core\Registry::getConfig()->getRequestParameter('user_password', true);

See OxidEsales\EshopCommunity\Application\Component\UserComponent:createUser for reference.


Affects _all_ Shop Versions.
Tags: User, Validation
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0013114)
QA   
2020-02-06 09:25   
-MK


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7082 [OXID eShop (all versions)] 6. ------ Setup ------- minor always 2020-02-04 01:35 2020-02-04 12:55
Reporter: marco_steinhaeuser Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.2.0-rc.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: avoid force_sid URL parameter
Description: Wenn running through setup process, variable $this->sSSLShopURL = null; // eShop SSL url, optional will not be filled although you define a SSL URL as standard. Please also fill $this->sSSLShopURL = null; // eShop SSL url, optional additionally to $this->sShopURL = ''; // eShop base url, required.
Tags: SEO, Setup
Steps To Reproduce: Set up an OXID eShop running through the setup process. Only $this->sShopURL = ''; // eShop base url, required will be filled. One has to manually fix $this->sSSLShopURL = null; // eShop SSL url, optional.
Additional Information: Bumped up earlier and was firstly documented here:
https://bisweb.me/blog/force-sid-url-parameter-verhindern-durch-https-umstellung.html
Attached Files:
Notes
(0013112)
QA   
2020-02-04 12:55   
More or less a feature request, but because SSL is the norm today it's kind of wrong to only work with the HTTP URL.

-MK


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6846 [OXID eShop (all versions)] 4.12. Subshop handling minor always 2018-06-21 10:00 2020-01-31 11:33
Reporter: anton.fedurtsya Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: acknowledged Product Version: 6.0.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Wrong language id used in views fields generation
Description: Wrong language id is used in views fields linking when we have a gap in language ids, like 0, 1, 2, 4 (no 3), so for last language the field ids will be wrong.
Tags:
Steps To Reproduce: Ensure you have some 3 or more languages in subshop: de(0), en(1), ru(2)
Regenerate views, so you can see correct ids are used for "ru" language views:
select `oxarticles`.`OXID` AS `OXID`, ... `oxarticles`.`OXTITLE_2` AS `OXTITLE` ...

Remove some not first and not last language, in our case only "en" fits the requirement.
Run console views regeneration command, or in admin, activate some other then "subshop" shop, and run views regeneration in mall.
You can see wrong language fields are used for "ru" language views:

select `oxarticles`.`OXID` AS `OXID`, ... `oxarticles`.`OXTITLE_1` AS `OXTITLE` ...

which is wrong, and will cause huge problems on more complex shops.
Additional Information: The method OxidEsales\EshopCommunity\Core\Language::getLanguageIds name is missleading, it do not care about the actual id's of the languages, but just gives the list of languages somehow calculated from several shops. The problem is - what method returns while used with shopId which doesnt match current active shop id. Need to check this case everywhere in code, but looks like its only used in views generation.
Attached Files:
Notes
(0012516)
anton.fedurtsya   
2018-06-21 10:06   
Related pull request with views regeneration fix:

https://github.com/OXID-eSales/oxideshop_ce/pull/647
(0013108)
nitin.singh   
2020-01-31 11:26   
(Last edited: 2020-01-31 11:33)
Interesting, regenerating views for languages in subshop: de(0), en(1), da(4) worked for me. I am using shop Enterprise Edition 6.2.0-rc.1 version.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7075 [OXID eShop (all versions)] 2.6. Administer orders minor always 2020-01-20 22:37 2020-01-22 07:59
Reporter: timwetter Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.2.0-rc.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: currency rate change on update e.g. shipping costs in order_main
Description: 1)
open backend and set exchange rate for e.g. YEN to 180.10

2)
make order in shopfronend as normal user in YEN (YEN is not your default currency)

3)
open backend and set exchange rate for YEN to 8888.88

4)
open your order in backend and go to order_main

5)
change e.g. shipping costs and click save

6)
SELECT OXCURRATE FROM oxorder WHERE {your order}

RESULT:
8888.88
But it should be 180.10 or why is OXCURRATE a field of table oxorder?

As an idea:
Maybe the value from OXCURRATE should not change on (recalculate -> finalizeOrder -> _loadFromBasket) and (_getOrderBasket),
but there could be an update button in e.g. order_main for the case user explicit wish to update currency rate in an order


Tags: Calculations, Currency
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0013096)
QA   
2020-01-21 12:41   
-MK


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7074 [OXID eShop (all versions)] 4.05. Performance minor always 2020-01-20 18:30 2020-01-21 09:08
Reporter: timwetter Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.2.0-rc.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: workaround for #36008 bug in php in file Utils.php wihtout phpversion check
Description: the workaround for php bug #36008 is obsolet for phpversion >= 5.3.
it may be better for performance to check if someone still uses php < 5.3 and then do the workaround!?


    /**
     * Rounds the value to currency cents. This method does NOT format the number.
     *
     * @param string $sVal the value that should be rounded
     * @param object $oCur Currency Object
     *
     * @return float
     */
    public function fRound($sVal, $oCur = null)
    {
        startProfile('fround');

        //cached currency precision, this saves about 1% of execution time
        $iCurPrecision = $this->_iCurPrecision;

        if (is_null($iCurPrecision)) {
            if (!$oCur) {
                $oCur = $this->getConfig()->getActShopCurrencyObject();
            }

            $iCurPrecision = $oCur->decimal;
            $this->_iCurPrecision = $iCurPrecision;
        }

        // if < 5.3.x this is a workaround for #36008 bug in php - incorrect round() & number_format() result (R)
++ $sVal = (float) $sVal;
++ if (phpversion() < '5.3') {
            static $dprez = null;
            if (!$dprez) {
                $prez = @ini_get("precision");
                if (!$prez || $prez > 12) {
                    $prez = 12;
                }
                $dprez = pow(10, -$prez);
            }

++ stopProfile('fround');
++ return round($sVal + $dprez * ($sVal >= 0 ? 1 : -1), $iCurPrecision);
++ }
        stopProfile('fround');

-- $sVal = (float) $sVal;
        return round($sVal, $iCurPrecision);
    }
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0013093)
florian.engelhardt   
2020-01-21 08:41   
Hey Tim,

looks reasonable to me, would you mind opening a pull request on our GitHub Repository?
https://github.com/OXID-eSales/oxideshop_ce/blob/b-6.x/source/Core/Utils.php

Kind regards
Florian
(0013094)
QA   
2020-01-21 09:06   
-MK
(0013095)
QA   
2020-01-21 09:08   
Fixed wrong status. -MK


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7052 [OXID eShop (all versions)] 4.01. Database handling minor always 2019-11-19 00:39 2020-01-20 08:33
Reporter: timwetter Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: acknowledged Product Version: 6.2.0-rc.1  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: DB 'NULL' value for DB float/double types not possible
Description: why are you deleting my entrie?
so if i am wrong you can say it!

but you can't set DB NULL value for float,double types in MySQL

because of:
protected function _setFieldData($fieldName, $fieldValue, $dataType = Field::T_TEXT)
    {
        $longFieldName = $this->_getFieldLongName($fieldName);
        //$sLongFieldName = $this->_sCoreTable . "__" . strtolower($sFieldName);
        // doing this because in lazy loaded lists on first load it is harmful to have initialised fields but not yet set
        // situation: only first article is loaded fully for "select oxid from oxarticles"
        //if ($this->_blUseLazyLoading && !isset($this->$sLongFieldName))
        // return;
        //in non lazy loading case we just add a field and do not care about it more
        if (!$this->_blUseLazyLoading
            && !$this->isPropertyLoaded($longFieldName)
        ) {
            $fieldsList = $this->_getAllFields(true);
            if (isset($fieldsList[strtolower($fieldName)])) {
                $this->_addField($fieldName, $this->_getFieldStatus($fieldName));
            }
        }
        // if we have a double field we replace "," with "." in case somebody enters it in european format
        $isPropertyLoaded = $this->isPropertyLoaded($longFieldName);
        if ($isPropertyLoaded
            && isset($this->$longFieldName->fldtype)
            && $this->$longFieldName->fldtype == 'double'
++ && $fieldValue !==null
        ) {
            $fieldValue = str_replace(',', '.', $fieldValue);
        }


if you think that I am wrong , please let me know and all the others, too
Tags:
Steps To Reproduce: 1)
ALTER TABLE oxcountry
ADD COLUMN `DENIX1` int DEFAULT NULL,
ADD COLUMN `DENIX2` VARCHAR(30) DEFAULT NULL,
ADD COLUMN `DENIX3` double DEFAULT NULL

2)
insert input field for denix 1 to 3 in country:main.tpl
<tr>
    <td class="edittext">
        denix1 int<br_>
        denix2 varchar<br_>
        denix3 double
    </td>
    <td class="edittext">
        <input type="text" class="editinput" size="10" maxlength="[{$edit->oxcountry__denix1->fldmax_length}]" name="editval[oxcountry__denix1]" value="[{$edit->oxcountry__denix1->value}]"[{$readonly}]><br_>
        <input type="text" class="editinput" size="10" maxlength="[{$edit->oxcountry__denix2->fldmax_length}]" name="editval[oxcountry__denix2]" value="[{$edit->oxcountry__denix2->value}]"[{$readonly}]><br_>
        <input type="text" class="editinput" size="10" maxlength="[{$edit->oxcountry__denix3->fldmax_length}]" name="editval[oxcountry__denix3]" value="[{$edit->oxcountry__denix3->value}]"[{$readonly}]>
    </td>
</tr>

3)
alter function save() in Application/Model/Country.php: add lines to function:
    if (isset($aParams['oxcountry__denix1']) && $aParams['oxcountry__denix1'] === '') {
        $aParams['oxcountry__denix1'] = null;
    }
    if (isset($aParams['oxcountry__denix2']) && $aParams['oxcountry__denix2'] === '') {
        $aParams['oxcountry__denix2'] = null;
    }
    if (isset($aParams['oxcountry__denix3']) && $aParams['oxcountry__denix3'] === '') {
        $aParams['oxcountry__denix3'] = null;
    }

4)
clear oxid's tmp cache && generate views

5)
open oxid admin backend and save a country

6)
SELECT DENIX1, DENIX2, DENIX3 FROM oxcountry WHERE {country you saved};

RESULT:
DENIX1 = NULL (for int/numeric value)
DENIX2 = NULL (for varchar/string)
DENIX3 = 0 (for double/numeric value)
Additional Information: /vendor/oxid-esales/oxideshop-ce/source/Core/Model/BaseModel.php:1264
possible fix:
if ($isPropertyLoaded
            && isset($this->$longFieldName->fldtype)
            && $this->$longFieldName->fldtype == 'double'
            && $fieldValue
        )
Attached Files:
Notes
(0013047)
timwetter   
2019-11-19 00:44   
so again, the extra check, if new value is set to 'NULL' can not hurt performance or everythign else.
I am using php 7.3 for testing
and if I do not check this - the str_replace will causes a '0' instead of 'NULL' in DB mysql
(0013048)
QA   
2019-11-19 08:21   
(Last edited: 2019-11-19 08:21)
the bug entry was not simply closed, but set to unable to reproduce with the following comment:

Can‘t reproduce the behavior.
If I add a new column with type float NULL and add as described:

\OxidEsales\Eshop\Core\Registry::getConfig()->getRequestParameter("editval");
$aParams[oxcountry__oxnix] = 2;

Then I have OXINIX 2 in the field. If I changed the line to save with null afterwards, I also get NULL in the database field.

It seems to be more of a DB problem/configuration/non-supported DB.
Can you reproduce that with 6.1.x?

If you still have something to comment, please always reply to the first entry made, so as not to create a lot of duplicates.
https://bugs.oxid-esales.com/view.php?id=7049

- es -

(0013049)
timwetter   
2019-11-19 09:42   
php > $t=null;
php > echo $t===null?"y":"n";
y
php > echo (str_replace("d","c",$t)===null)?"y":"n";
n
(0013050)
QA   
2019-11-19 10:49   
(Last edited: 2019-11-19 10:56)
Hi timwetter,

to be able to reproduce the issue described by your first entry (0007049) the form of the country main template (country_main.tpl) has to be extended with the input field for the new column oxnix. This point is missing in your description. If there is an input field in the backend, then the shop will always write a 0 instead of null. As the summary of the entry 0007049 states.
But when I add your code for the method CountryMain.php then the framework will of course write NULL, as the code overwrites the value from the form. Which is contradictory to the summary as it shows that the framework is able to write NULL to float fields.

As it is not clear if you wanted to report if either the framework does not allow NULL in float fields or that the framework uses 0 instead of null, I suggest that you simply create a Pull Request for that case, as the first claim is not reproducible and the second is more a feature request than a bug: https://github.com/OXID-eSales/oxideshop_ce/blob/master/CONTRIBUTING.md

Thank you!

- MK

(0013051)
timwetter   
2019-11-19 22:44   
the framework does allow NULL in DB float fields, BUT saves 0 instead of null to DB!

And if you take your time and see why that is the case, then you can clearly see that this behavior was not intended.
Why should only fields of the type float not be able to assume the value 'null'?

1) this shows, that a null value as input will be converted to an empty string via str_replace
---%<----%<----%<----%<----%<----%<---
php > $t = null;
php > var_dump($t);
NULL
php > $t = str_replace('','',$t);
php > var_dump($t);
string(0) ""
php >
---%<----%<----%<----%<----%<----%<---

2)
the function _setFieldData will do the same with a $fieldValue=null and fldtype == 'double'

3)
function _getUpdateFieldValue in BaseModel:
---%<----%<----%<----%<----%<----%<---
if ((null === $fieldValue)) {
            if ($this->_canFieldBeNull($fieldName)) {
                return 'null';
---%<----%<----%<----%<----%<----%<---
function _canFieldBeNull would return true, but will never be entered, because value of $fieldValue is an empty string and !== null, but original value was null
(0013088)
QA   
2020-01-08 15:56   
Dear timwetter,

I’m SG and have also tried to understand this report 7052 and 7049.

I cannot replicate the problem "save 0 instead of null", if I follow your instructions as I understand it.

That would be:
A)
1, add column denix (your oxnix) as float with default null
2. change /Apllication/Controller/Admin/CountryMain::Save() as followd:
++ $aParams['oxcountry__denix'] = null;
3. save country by pressing save button.

I can reproduce your "save 0 instead of null" if I undergo the following steps:
B)
1, add column denix (your oxnix) as float with default null
2. insert input field for denix in country:main.tpl
 <tr>
                    <td class="edittext">
                        denix
                    </td>
                    <td class="edittext">
                        <input type="text" class="editinput" size="10" maxlength="[{$edit->oxcountry__denix->fldmax_length}]" name="editval[oxcountry__denix]" value="[{$edit->oxcountry__denix->value}]"[{$readonly}]>

                    </td>
                </tr>
3. save country by pressing save button.

I suggest you undergo following steps, so you really can save null by submitting "" and save any valid value. I also see oxvat from oxarticles as a model:

1. create column
2. change .tpl (as described)
3. change save() :
if (isset($aParams['oxcountry__denix']) && $aParams['oxcountry__denix'] === '') {
            $aParams['oxcountry__denix'] = null;
        }
4. save per button



In Case B:
In my testing, no data-type, no text, no double got "null" as value. they were empty ("strings") or 0 ("number-based").
The reason is denix = ''
you see an '' is submitted, therefore it gets 0, because of:
http://www.sqlines.com/oracle/insert_empty_string_to_numeric_column

This behavior is not new to oxid.

Best regards

SG
(0013091)
timwetter   
2020-01-18 22:17   
(Last edited: 2020-01-18 22:19)
1)
ALTER TABLE oxcountry
ADD COLUMN `DENIX1` int DEFAULT NULL,
ADD COLUMN `DENIX2` VARCHAR(30) DEFAULT NULL,
ADD COLUMN `DENIX3` double DEFAULT NULL

2)
insert input field for denix 1 to 3 in country:main.tpl
<tr>
    <td class="edittext">
        denix1 int<br_>
        denix2 varchar<br_>
        denix3 double
    </td>
    <td class="edittext">
        <input type="text" class="editinput" size="10" maxlength="[{$edit->oxcountry__denix1->fldmax_length}]" name="editval[oxcountry__denix1]" value="[{$edit->oxcountry__denix1->value}]"[{$readonly}]><br_>
        <input type="text" class="editinput" size="10" maxlength="[{$edit->oxcountry__denix2->fldmax_length}]" name="editval[oxcountry__denix2]" value="[{$edit->oxcountry__denix2->value}]"[{$readonly}]><br_>
        <input type="text" class="editinput" size="10" maxlength="[{$edit->oxcountry__denix3->fldmax_length}]" name="editval[oxcountry__denix3]" value="[{$edit->oxcountry__denix3->value}]"[{$readonly}]>
    </td>
</tr>

3)
alter function save() in Application/Model/Country.php: add lines to function:
    if (isset($aParams['oxcountry__denix1']) && $aParams['oxcountry__denix1'] === '') {
        $aParams['oxcountry__denix1'] = null;
    }
    if (isset($aParams['oxcountry__denix2']) && $aParams['oxcountry__denix2'] === '') {
        $aParams['oxcountry__denix2'] = null;
    }
    if (isset($aParams['oxcountry__denix3']) && $aParams['oxcountry__denix3'] === '') {
        $aParams['oxcountry__denix3'] = null;
    }

4)
clear oxid's tmp cache

5)
open oxid admin backend and save a country

6)
SELECT DENIX1, DENIX2, DENIX3 FROM oxcountry WHERE {country you saved};

RESULT:
DENIX1 = NULL (for int/numeric value)
DENIX2 = NULL (for varchar/string)
DENIX3 = 0 (for double/numeric value)

------------------------------------
why should NULL only work for all types except double type?
please check the result of php str_replace function with NULL as input and oxids _setFieldData function

(0013092)
QA   
2020-01-20 08:33   
Dear Timwetter,

thanks!

I tested it again and this time i can reproduce it.

Best regards

-SG-


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7073 [OXID eShop (all versions)] 2.4. Administer products minor always 2020-01-14 14:52 2020-01-14 15:14
Reporter: Topleiter-IT Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.2.0-rc.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Firefox, Google Chrome
PHP Version: 7.1
Database Version: Not defined
Summary: Left entries from the popup "Assign article" in the category management do not disappear after assignment
Description: If you move articles in the popup from the left column "All articles" to the right column "Articles in this category" under Categories->Master->"Assign articles", this article will not disappear from the left column.
Tags:
Steps To Reproduce: 1. navigate to "Manage items"->categories (and select a category) -> trunk
2. select popup for article assignment (button "Assign article")
3. in the popup, drag an article from the left column "All articles" to the right column "Articles in this category
4. the article now also appears in the right column, but it is not removed from the left column.
Additional Information: confirmed for the category, for example not in crossselling.
translated by -SG- with
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6138 [OXID eShop (all versions)] 4.12. Subshop handling minor always 2015-04-29 15:01 2020-01-14 09:24
Reporter: hendrikfreytag Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Azure
Browser: All
PHP Version: Not defined
Database Version: Not defined
Summary: Search function does not use oxfield2shop
Description: The search function selects articles direct from oxarticles and doesn't use oxfield2shop. So you can't find an article by it's title in subshop if it is different from the title of the supershop.
Tags:
Steps To Reproduce: - In config.inc.php add OXTITLE to $this->aMultishopArticleFields
- Create field OXTITLE in oxfield2shop
- create subshop
- make Category Kiteboarding available in subshop
- change title of "Kiteboard NAISH MOMENTUM" to "blabla" in subshop
- search for "blabla" in subshop -> you find nothing
- search for "MOMENTUM" in subshop -> you find "blabla"
Additional Information:
Attached Files:
Notes
(0012997)
simon.runer   
2019-09-13 14:27   
Is there any plan in fixing/changing this?
(0013089)
QA   
2020-01-14 09:23   
confirmed for 6.2

- SG -


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7072 [OXID eShop (all versions)] 2.6. Administer orders minor always 2020-01-11 12:34 2020-01-13 09:58
Reporter: micha23 Platform: Desktop  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: acknowledged Product Version: 6.1.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Flow
Browser: Google Chrome
PHP Version: 7.1
Database Version: Not defined
Summary: Fehler bei Änderung der Versandart
Description: If the shipping method of an existing order is changed and saved in Admin, the payment method is set to "Empty".
Tags:
Steps To Reproduce: An order was created in the demo shop. Then the shipping method was changed from "Standard" to "Example Set1" and saved in the admin.
So the displayed payment method is then "Empty".
Additional Information: /vendor/oxid-esales/oxideshop-ce/source/Application/Controller/Admin/OrderMain.php:135
sets the payment method to empty. It can result in data loss.

translated and edited by SG
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7069 [OXID eShop (all versions)] 1.03. Basket, checkout process minor always 2019-12-30 10:42 2019-12-30 11:21
Reporter: heju Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Variant selection drop down list in wish list has no effect
Description: In case a father article (which cannot be purchased) is added to the wish list:

- the wish list shows the variant drop down selector for this article
- whatever variant is chosen, has no effect

expected behaviour:
either:
- do not display the variant list, customer has to choose product details from wish list and can order from there
OR
- display the variant list in wish list and update the wish list item with the selected variant in case the user selects a value
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7068 [OXID eShop (all versions)] 1.01. Products (product, categories, manufacturer, promotions etc.) minor always 2019-12-30 10:26 2019-12-30 10:38
Reporter: heju Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Product rating not displayed in case no review text was entered
Description: In case the customer rates the product by
- adjusting the amount of stars (e.g. 3 out of 5)
AND
- not entering any review text

Then
- his "star rating" does not show up in the product details
- he is not allowed to submit another "star rating"
Tags:
Steps To Reproduce: - Log in as registered customer
- open product details
- rate product by
  - adjusting the stars count
  - leaving the review textbox empty
- submit rating

--> reload product details, check if stars rating has changed
--> try to rate again
Additional Information:
Attached Files:
Notes
(0013081)
QA   
2019-12-30 10:38   
-MK


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7065 [OXID eShop (all versions)] 2.4. Administer products feature always 2019-12-20 17:27 2019-12-20 17:56
Reporter: QA Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: redirect if smarty code in article description and empty meta description
Description: If you have maintained attributes for the product item and additionally include them in the longdesc via the attribute template, an error will occur if you have not set a "description text for meta tags" in the tab.

Longdesc:
[{include file="page/details/inc/attributes.tpl"}]

-> reported bei o.ramm (web-grips) who was not able to place a bug entry here as for too rigid spam protection options


Error message:

[2019-12-17 14:03:43] OXID Logger.ERROR: Function 'getAttributes' does not exist or is not accessible! (OxidEsales\Eshop\Application\Controller\FrontendController)
 ["[object] (OxidEsales\\Eshop\\Core\\Exception\\SystemComponentException(code: 0): Function 'getAttributes' does not exist or is not accessible! (OxidEsales\\Eshop\\Application\\Controller\\FrontendController)\n at /home/[user]/webseiten/shop/vendor/oxid-esales/oxideshop-ce/source/Core/Base.php:76)\n[stacktrace]\n#0 /home/[user]/webseiten/shop/source/tmp/smarty/741a9a249c1bbdcc3d505852ec274b13^%%05^050^05096B0C%%attributes.tpl.php(4): OxidEsales\\EshopCommunity\\Core\\Base->__call('getAttributes', Array)\n#1 /home/[user]/webseiten/shop/vendor/smarty/smarty/libs/Smarty.class.php(1876): include('/home/[user]/...')\n#2 /home/[user]/webseiten/shop/source/tmp/smarty/741a9a249c1bbdcc3d505852ec274b13^%%9E^9E8^9E87ACF6%%ox%3A073c1257cd78c5387e326476fde7b47500.php(29): Smarty->_smarty_include(Array)\n#3 /home/[user]/webseiten/shop/vendor/smarty/smarty/libs/Smarty.class.php(1270): include('/home/[user]/...')\n#4 /home/[user]/webseiten/shop/vendor/oxid-esales/oxideshop-ce/source/Core/UtilsView.php(250): Smarty->fetch('ox:073c1257cd78...')\n#5 /home/[user]/webseiten/shop/vendor/oxid-esales/oxideshop-ce/source/Application/Model/Article.php(2545): OxidEsales\\EshopCommunity\\Core\\UtilsView->parseThroughSmarty('<h2><span style...', '073c1257cd78c53...', Object(OxidEsales\\Eshop\\Application\\Controller\\FrontendController), true)\n#6 /home/[user]/webseiten/shop/vendor/oxid-esales/oxideshop-ce/source/Application/Controller/ArticleDetailsController.php(327): OxidEsales\\EshopCommunity\\Application\\Model\\Article->getLongDesc()\n#7 /home/[user]/webseiten/shop/vendor/oxid-esales/oxideshop-ce/source/Application/Controller/FrontendController.php(1097): OxidEsales\\EshopCommunity\\Application\\Controller\\ArticleDetailsController->_prepareMetaDescription(false)\n#8 /home/[user]/webseiten/shop/source/modules/oe/oetags/controllers/oetagsArticleDetailsController.php(237): OxidEsales\\EshopCommunity\\Application\\Controller\\FrontendController->getMetaDescription()\n#9 /home/[user]/webseiten/shop/source/tmp/smarty/741a9a249c1bbdcc3d505852ec274b13^%%90^90B^90B7B94A%%base.tpl.php(6): oetagsArticleDetailsController->getMetaDescription()\n#10 /home/[user]/webseiten/shop/vendor/smarty/smarty/libs/Smarty.class.php(1876): include('/home/[user]/...')\n#11 /home/[user]/webseiten/shop/source/tmp/smarty/741a9a249c1bbdcc3d505852ec274b13^%%36^366^366ECF91%%page.tpl.php(125): Smarty->_smarty_include(Array)\n#12 /home/[user]/webseiten/shop/vendor/smarty/smarty/libs/Smarty.class.php(1876): include('/home/[user]/...')\n#13 /home/[user]/webseiten/shop/source/tmp/smarty/741a9a249c1bbdcc3d505852ec274b13^%%08^08A^08ABD53A%%details.tpl.php(14): Smarty->_smarty_include(Array)\n#14 /home/[user]/webseiten/shop/vendor/smarty/smarty/libs/Smarty.class.php(1270): include('/home/[user]/...')\n#15 /home/[user]/webseiten/shop/vendor/oxid-esales/oxideshop-ce/source/Core/ShopControl.php(488): Smarty->fetch('page/details/de...', 'ox|0|0|0|0|ssl|...')\n#16 /home/[user]/webseiten/shop/vendor/oxid-esales/oxideshop-ce/source/Core/ShopControl.php(344): OxidEsales\\EshopCommunity\\Core\\ShopControl->_render(Object(oetagsArticleDetailsController))\n#17 /home/[user]/webseiten/shop/vendor/oxid-esales/oxideshop-ce/source/Core/ShopControl.php(276): OxidEsales\\EshopCommunity\\Core\\ShopControl->formOutput(Object(oetagsArticleDetailsController))\n#18 /home/[user]/webseiten/shop/vendor/oxid-esales/oxideshop-ce/source/Core/ShopControl.php(137): OxidEsales\\EshopCommunity\\Core\\ShopControl->_process('OxidEsales\\\\Esho...', NULL, NULL, NULL)\n#19 /home/[user]/webseiten/shop/vendor/oxid-esales/oxideshop-ce/source/Core/Oxid.php(26): OxidEsales\\EshopCommunity\\Core\\ShopControl->start()\n#20 /home/[user]/webseiten/shop/source/index.php(15): OxidEsales\\EshopCommunity\\Core\\Oxid::run()\n#21 /home/[user]/webseiten/shop/source/oxseo.php(28): require('/home/[user]/...')\n#22 {main}\n"] []
Tags:
Steps To Reproduce: 1. Activate Smarty code interpretation in article description under performance settings
2. Add smarty code in an article (without meta data in SEO Tab) description: [{include file="page/details/inc/attributes.tpl"}]
3. open article in frontend leads to redirect
Additional Information:
Attached Files:
Notes
(0013078)
QA   
2019-12-20 17:56   
The reason for the redirect is, that the shop automatically fills an empty meta description field with the article description. It also interprets the smarty. But the FrontendController, which is responsible for filling the meta data, does not have the method to get the attribute data.

Possible solutions:
1. Fill meta data with content if attribute smarty code should be used in article description.
2. Add the smarty code into a template file instead inside article description like source/Application/views/flow/tpl/page/details/inc/fullproductinfo.tpl
3. Extend the FrontendController with a getAttributes method
4. Change the following method to change the behavior of auto filling empty meta data: \OxidEsales\EshopCommunity\Application\Controller\FrontendController::_getMetaFromContent

-MF


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7061 [OXID eShop (all versions)] 1.03. Basket, checkout process minor always 2019-12-16 08:26 2019-12-16 08:29
Reporter: QA Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: Patch for 6.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: It is not possible to delete the bonus article in basket
Description: It is not possible to delete the bonus article, regardless of whether the bonus was created for an article in the products -> extended -> assign product or as a discount -> itm.
Tags:
Steps To Reproduce: 1. Create bonus article either in the products -> extended -> assign product or discount -> itm
2. Add item with bonus to basket
3. Try to delete bonus article

-> not possible

- es -
Additional Information:
Attached Files: Dreingabe.png (107,141 bytes) 2019-12-16 08:26
https://bugs.oxid-esales.com/file_download.php?file_id=1775&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6992 [OXID eShop (all versions)] 1. ----- eShop frontend ----- minor always 2019-06-06 13:18 2019-12-12 13:35
Reporter: it artvera Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: call "widget.php" without parameters throws exception
Description: [2019-06-06 12:53:20] OXID Logger.ERROR: OxidEsales\Eshop\Application\Controller\ExceptionErrorController is not an instance of OxidEsales\Eshop\Application\Component\Widget\WidgetController
["[object] (OxidEsales\\Eshop\\Core\\Exception\\ObjectException(code: 0): OxidEsales\\Eshop\\Application\\Controller\\ExceptionErrorController is not an instance of OxidEsales\\Eshop\\Application\\Component\\Widget\\WidgetController at \vendor\\oxid-esales\\oxideshop-ce\\source\\Core\\UtilsObject.php:231)
[stacktrace]
#0 \source\\oxfunctions.php(101): OxidEsales\\EshopCommunity\\Core\\UtilsObject->oxNew('OxidEsales\\\\Esho...', 'OxidEsales\\\\Esho...')
#1 \vendor\\oxid-esales\\oxideshop-ce\\source\\Core\\WidgetControl.php(130): oxNew('OxidEsales\\\\Esho...', 'OxidEsales\\\\Esho...')
#2 \vendor\\oxid-esales\\oxideshop-ce\\source\\Core\\ShopControl.php(272): OxidEsales\\EshopCommunity\\Core\\WidgetControl->_initializeViewObject('exceptionError', 'displayExceptio...', NULL, NULL)
#3 \vendor\\oxid-esales\\oxideshop-ce\\source\\Core\\ShopControl.php(794): OxidEsales\\EshopCommunity\\Core\\ShopControl->_process('exceptionError', 'displayExceptio...')
#4 \vendor\\oxid-esales\\oxideshop-ce\\source\\Core\\ShopControl.php(145): OxidEsales\\EshopCommunity\\Core\\ShopControl->_handleBaseException(Object(OxidEsales\\Eshop\\Core\\Exception\\ObjectException))
#5 \vendor\\oxid-esales\\oxideshop-ce\\source\\Core\\WidgetControl.php(62): OxidEsales\\EshopCommunity\\Core\\ShopControl->start('start', NULL, NULL, NULL)
#6 \source\\modules\\ava\\Utils\\Core\\WidgetControl.php(16): OxidEsales\\EshopCommunity\\Core\\WidgetControl->start(NULL, NULL, NULL, NULL)
#7 \vendor\\oxid-esales\\oxideshop-ce\\source\\Core\\Oxid.php(41): De\\Artvera\\Oxid\\Module\\Utils\\Core\\WidgetControl->start()
#8 \source\\widget.php(10): OxidEsales\\EshopCommunity\\Core\\Oxid::runWidget()
#9 {main}
"] []
Tags:
Steps To Reproduce: just call "widget.php" in the browser
Additional Information:
Attached Files:
Notes
(0012909)
QA   
2019-06-06 16:05   
-MK
(0012994)
mario_lorenz   
2019-09-11 13:54   
I can confirm the behavior. Throwing an Exception is Ok, the shop owner or the developer should already hear the wrong call, but the shop should not show a white page with the status 200. It is better to do the redirect to the start page here as well, as happens when I call widget.php with a fantasy controller (widget.php?cl=FantasyXYC).
The background is that in our shop SearchBots are responsible for the "empty"-call and keep coming back, because the status 200 causes them to do so.

In my opion is the status 302 (temporary not available) for a fantasy-Controller call in the index.php and the widget.php also not the right solution. Because a robot will come back for a 302 page. Better is 404 or 503.
(0013066)
DayanaLuedecke   
2019-12-12 13:35   
We can reproduce. Had a lot of Exception in Logfile, because of doing a page scan with robot "Gtmetrix.com".


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7056 [OXID eShop (all versions)] 3.2. HTML, CSS, JavaScript minor always 2019-11-26 14:43 2019-11-26 15:38
Reporter: henrik.steffen Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.2.0-rc.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Flow
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: giftcard getCardMessage never displayed in order_owner.tpl
Description: the if-condition in the order_owner.tpl is wrong:
$basket->oCard is always false

owner template should contain same if-condition as customer template:

 [{if $oViewConf->getShowGiftWrapping() && $basket->getCard()}]


same applies to plain e-mail messages

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7024 [OXID eShop (all versions)] 4.04. Security minor always 2019-09-02 14:46 2019-11-14 08:52
Reporter: cesnauskast Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.2.0-rc.1  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Outdated jQuery library in admin panel
Description: Currently used jQuery library version 1.5.1 has some security vulnerabilities. It's advisable to updated it to a new one.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6993 [OXID eShop (all versions)] 2.4. Administer products minor always 2019-06-12 12:21 2019-11-12 08:58
Reporter: pbenke Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: resolved Product Version: 6.1.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.2.0-rc.1  
    Target Version:  
Theme: Not defined
Browser: All
PHP Version: Not defined
Database Version: Not defined
Summary: Wrong format in external url on article input
Description: For example:
Stored value in database in oxarticles.OXEXTURL: https://www.google.com
The form will show http://https://www.google.com

Reason:
source/Application/views/admin/tpl/article_extend.tpl

=> line 133
input ... name="editval[oxarticles__oxexturl]" value="http://[{$edit->oxarticles__oxexturl->value}]"...
(Look at value)
Tags: Admin Template, Article
Steps To Reproduce: Input an article with an external url (tab "Erweitert")
Additional Information:
Attached Files:
Notes
(0012913)
QA   
2019-06-12 13:23   
(Last edited: 2019-06-12 13:24)
Thanks for your report. I agree that the form is showing a wrong URL since it always adds "http://" to the beginning, but unlike your description I don't run in any issue with that behavior present.

I did the following:
1) Chose an article.
Extern URL form field shows "http://".
Database field shows "".
2) Filled in the url https://www.myexternurl.de
3) Saved.
Extern URL form field shows: "http://https://www.myexternurl.de/".
Database field shows "https://www.myexternurl.de/".
4) Saved again.
Extern URL form field still shows: "http://https://www.myexternurl.de/".
Database field still shows "https://www.myexternurl.de/".

Therefore the form doesn't look good, but the behavior have not led into a problem with the saved value. The URL is stored correctly in the database even after resaving. As a result I have acknowledge your issue as a bug because the form shows a wrong value. But since the mechanism isn't affected, I've edited the issue description and set the priority to low.

[sp]

(0012914)
pbenke   
2019-06-12 13:36   
Thanky you,
sorry, I reported not everything.

The error occurs in Frontend!

Please have a look inside the wrong template:
source/Application/views/flow/tpl/page/details/inc/tabs.tpl
Line 12

Thank you.
(0012915)
QA   
2019-06-12 14:43   
Please specify your concern. The link in the shop frontend works fine in my testing environment.

[sp]
(0012916)
pbenke   
2019-06-12 15:00   
Sorry, my fault.
Has been already fixed in the last Flow theme version.

Thank you.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6999 [OXID eShop (all versions)] 4.01. Database handling feature always 2019-06-21 14:03 2019-11-12 08:54
Reporter: pvanhemmen Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.0.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.2.0-rc.1  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: oxadminlog adodb extension not ported to PDO / OXID 6
Description: In shop Versions prior to v6 logging of sql queries was done through the adodb extension oxadminlog. With the introduction of PDO this feature is gone, although all references in code like the setting blLogChangesInAdmin are still there. Since this has been a useful feature and i can find no deprecation entries whatsoever that this was going to be removed it seems like this feature was unintentionally forgotten in v6.
Tags: Admin, Database, Log, SQL
Steps To Reproduce: Try to log something to oxadminlog
Additional Information: Please bring back this feature (preferred solution) or otherwise remove references to it as well as the corresponding table.
Attached Files:
Notes
(0012923)
QA   
2019-06-25 14:08   
-MK


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6673 [OXID eShop (all versions)] 1. ----- eShop frontend ----- minor always 2017-07-31 15:48 2019-11-08 11:46
Reporter: AlexN Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 4.10.4 / 5.3.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Flow
Browser: Google Chrome
PHP Version: Not defined
Database Version: Not defined
Summary: OXID eShop flow - address setting - mobile & tablet
Description: See attachment. Says everything :)
Tags:
Steps To Reproduce: 1. open https://demoshop.oxid-esales.com/professional-edition/
2. log into an frontend account
3. head to address setting
4. change browser size to tablet / mobile
5. collapse shipping address
6. scroll down
Additional Information:
Attached Files: oxid_flow_bug_address_form_bug.png (97,788 bytes) 2017-07-31 15:48
https://bugs.oxid-esales.com/file_download.php?file_id=1538&type=bug
Notes
(0012197)
AlexN   
2017-07-31 15:49   
ps: when using height: initial; it works properly - at least I did not find an other bug caused by this change yet.
(0013041)
marco_steinhaeuser   
2019-11-08 11:46   
Solution: https://forum.oxid-esales.com/t/anzeige-rechnungs-lieferanschrift-im-browser-safari-fehlerhaft/95916/3


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7043 [OXID eShop (all versions)] 1.02. Price calculations (discounts, coupons, additional costs etc.) minor always 2019-10-16 16:52 2019-11-06 13:15
Reporter: afshar5152 Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: acknowledged Product Version: 6.0.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 6.0.6  
Theme: Flow
Browser: Google Chrome
PHP Version: Not defined
Database Version: Not defined
Summary: User can not use his added coupon after logout and login again
Description: when a user has added a coupon to his basket, then he has logged out and then he logged in again. he can not see his added coupon in his basket and when he want to add it again he will get following error:
"Coupon is invalid"
This is because the coupon has been reserved for 3 hours and it has not mentioned for who. So user can not use it because of his logout and login.
Tags: coupon
Steps To Reproduce: 1- add a coupon to your basket
2- logout
3- login
4- go to your basket
5- you can not use your coupon any more
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7046 [OXID eShop (all versions)] 4.05. Performance tweak always 2019-11-05 09:57 2019-11-05 11:09
Reporter: Sven Brunk Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Ungefähr 95 Queries auf der Datenbank beim Speichern der Objektrechte in den Rolleneinstellungen
Description: Beim Speichern der Einstellungen unter Admin Rollen->Objekte werden ca. 95 Queries and die Datenbank gesendet um die Einstellungen zu speichern. Danach kommen nochmal gut 2 Dutzend Queries, um das Ergebnis zu lesen und anzuzeigen.
76 dieser Queries sind inserts in oxfield2role mit einzelnen Feld-spezifischen Rollen, selbst wenn die Settings nur auf oberer Ebene vorgenommen wurden.
Vielleicht könnte man die Settings so kaskadiert speichern, dass das Lesen aus der Datenbank und das Speichern darin ähnlich ablaufen, wie es auch im Frontend dargestellt wird:
Gibt es keine Anpassungen auf der untersten Ebene, zeigt die darüber globale Rechte, sonst "angepasst". Wird das "Angepasst" tatsächlich gespeichert könnte man darauf aufbauend weiter kaskadieren.
Tags: Admin, Database, Rights & Roles
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0013034)
Sven Brunk   
2019-11-05 11:07   
English:
When saving the settings under Admin Roles->Objects about 95 queries are sent to the database to save the settings. Then there are another 2 dozen queries to read and display the result.
76 of these queries are inserts in oxfield2role with individual field-specific roles, even if the settings were only made at the upper level.
Maybe you could save the settings cascaded so that reading from and saving to the database is similar to the way it is displayed in the frontend:
If there are no adjustments on the lowest level, the one above shows global rights, otherwise "adapted". If the "Adapted" flag is actually saved, it could be cascaded further.
(0013035)
QA   
2019-11-05 11:09   
-MK


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7023 [OXID eShop (all versions)] 4.04. Security major always 2019-09-02 14:43 2019-11-05 10:38
Reporter: cesnauskast Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.0.6  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Unauthorized access to admin panel
Description: By using a specially crafted URL, users with administrative rights could unintentionally grant unauthorized users access to the admin panel
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6698 [OXID eShop (all versions)] 4.04. Security minor always 2017-09-25 09:28 2019-10-29 11:24
Reporter: cesnauskast Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.0.6  
    Target Version: 6.1.5  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: It's possible to search for e-mail addresses via gift registry search
Description: It's possible to find out e-mail addresses from gift registry search panel
Tags: Data Privacy, Email, Gift Registry
Steps To Reproduce: Pre-conditions:
1. There exist a registered user (i.e. john_doe@gmail.com) with at least 1 item added to gift registry
2. Under My account->My gift registry an option "Everyone shall be able to search and display my gift registry" is set to "Yes"

1. Open shop (i.e. demoshop)
2. Go to "Public gift registries" (at the bottom of the page, under "Services")
3. Enter part of the possible e-mail address (i.e. @gmail.com or just "@")

In the search results you will see something like "Gift registry of John Doe"
By knowing this information you can guess the username of the email (i.e. jdoe@gmail.com, johnd@gmail.com, johndoe@gmail.com, etc.)

Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6732 [OXID eShop (all versions)] 4.04. Security minor always 2017-11-29 12:27 2019-10-29 11:22
Reporter: cesnauskast Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.0.0  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: oxdefaultadmin is still used as user ID
Description: The user with the ID oxdefaultadmin can simply be identified and it leads to information leakage
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0013009)
vilma_liorensaityte   
2019-09-24 15:47   
Fixed in 6.0.0 version


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6931 [OXID eShop (all versions)] 4.08. Cache major always 2018-12-12 10:48 2019-10-28 11:08
Reporter: michael_keiluweit Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: acknowledged Product Version: 6.1.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: EE: Article::onChange calls ContentCache::reset twice.
Description: The method \OxidEsales\EshopEnterprise\Application\Model\Article::onChange calls \OxidEsales\EshopEnterprise\Application\Model\Article::_resetCache which has a logic to control the cache wether it should be flushed completely or only particular.
After the call of _resetCache is an additional flushing of the cache, which is too much as it makes the work before completely unnecessary.

We have to possible cases in _resetCache:
1. The cache was flushed completely, then the second flush is overhead.
2. The cache was flushed particularly, then the second flush flushes too much.

Furthermore the method _resetCache checks if the call was made in the frontend and if the cache is active. The other call of the flushing doesn't check the context.
That means:
1. Either the second call is overhead and has to be removed
2. Or there is a missing check if the call was made in the context of the backend like: If the call came from the frontend check if the cache only have to flush particular or check if the call comes from the backend and if so, flush the cache in every case completely.
Tags: Cache, EE
Steps To Reproduce:
Additional Information: The Method \OxidEsales\EshopEnterprise\Application\Model\Article::onChange
// cache control ..
$this->_resetCache($articleId);  

[...]

if ($config->getConfigParam('blUseContentCaching')) {
    $genericCache = oxNew(\OxidEsales\Eshop\Core\Cache\DynamicContent\ContentCache::class);
    $genericCache->reset();
}


If you would add the cache logic from _resetCache to onChange:

// cache control ..

// < instead of calling the method _resetCache>
if (!$this->isAdmin() && $config->getConfigParam('blUseContentCaching')) {
    $contentCache = oxNew(\OxidEsales\Eshop\Core\Cache\DynamicContent\ContentCache::class);
    
    if ($database->getOne($query)) {
        $contentCache->reset();
        return;
    }
    [...]
    $contentCache->resetOn($resetOn);
// </ instead of calling the method _resetCache>

[...]

if ($config->getConfigParam('blUseContentCaching')) {
    $genericCache = oxNew(\OxidEsales\Eshop\Core\Cache\DynamicContent\ContentCache::class);
    $genericCache->reset();
}


As you see, the logic from _resetCache is completely unnecessary as at the end of onChange the cache is flushed every time completely.
Because of that, I think, there is a missing check if the method was called in the context of the administration area.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7011 [OXID eShop (all versions)] 4.12. Subshop handling critical always 2019-07-11 14:23 2019-10-17 13:16
Reporter: QA Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: resolved Product Version: 6.1.4  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: Next Major Version  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: when assigning rights (rights -> assign user groups) to a category in the subshop, these are also transferred to the main shop
Description: Scenario:
In a supershop, articles are passed on to a subshop. (in the tab page Article -> Mall a tick is set)

In this Subshop (dealer portal) only logged in users should see/buy the articles because this subshop has different prices.
We have created extra categories in the subshop so that these can only be made visible for the logged in customers / dealers.
As soon as we add the user groups (in the subshop and for the categories of the subshop) (dealers), the articles are no longer displayed either in the supershop.

After we do not change any rights in the supershop, it is not allowed that changes of the subshop affect the supershop.
Tags:
Steps To Reproduce: 1. Create new subshop
2. Assign articles in supershop to subshop (Articles -> mall -> assign)
3. Create categorie in subshop
4. Assign articles to subshop category
5. Assign in subshop rights to category (category -> rights -> assign user group "Händler"
6. After that the articles also disappear in the main shop
Additional Information:
Attached Files:
Notes
(0012937)
QA   
2019-07-12 10:32   
(Last edited: 2019-07-12 10:33)
in the oxobjectrights table, if rights are set in the category (Category -> Rights) these are set not only for the categories, but also for the articles (which is incorrect).
But since the articles are inherited from the main shop, this right also applies here and the articles disappear.

Thus Workaround: First set rights for category (without article assignment) and after articles were assigned, do not touch the rights again. :-)

- es -



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6927 [OXID eShop (all versions)] 4.01. Database handling major always 2018-12-04 10:14 2019-10-16 10:57
Reporter: michael_keiluweit Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.1.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.1.2  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Master Slave Database balancing improvement
Description: By executing the method \OxidEsales\EshopCommunity\Core\SystemEventHandler::validateOnline a transaction is started. This validation will be executed on every request, nearly at the beginning. Because of this and that a transaction is used, the database connection will force switch to the master database. The consequence is that the master ~ slave balancing is disrupted.
Tags: Database, EE, Master-Slave
Steps To Reproduce: 1. Open vendor/oxid-esales/oxideshop-ee/Core/Database/Adapter/Doctrine/Database.php
2. Add this method:
public function getConnection()
{
    $debug = 'No Master/Slave connection used' . PHP_EOL;

    if ($this->isMasterSlaveConnection($this->connection)) {
        /** @var $connection MasterSlaveConnection */
        $connection = $this->connection;
        $debugBacktrace = debug_backtrace();
        $count = count($debugBacktrace) - 1; //skip require_once

        $debug = 'Used Connection: ';
        $debug .= $connection->isConnectedToMaster() ? 'master' : 'slave';
        $debug .= PHP_EOL;

         // 0 is always this method.
         for ($i = 1; $i < $count; $i++) {
             $debug .= $debugBacktrace[$i]['class'] . ' :: ' . $debugBacktrace[$i]['function'] . PHP_EOL;
         }
    }

    $logger = getLogger();
    $logger->error($debug);

    return parent::getConnection();
}
(Note: Don't use the administration area while this code is used. You will run into a nested loop. It will only work at the frontend.)
3. Check the oxideshop.log

Additional Information: The numbers are a bit out of sync as I tested it on the second or third page refresh, but you will get the idea.
The value of DAO means: 1 = true, it was active; 0 = false, I removed the call of $appServerService->updateAppServerInformationInFrontend();
+----------+-----+--------+-------+
|   Page   | DAO | Master | Slave |
+----------+-----+--------+-------+
| Start    |   1 |    626 |    18 |
| Start    |   0 |      0 |   641 |
| Category |   1 |    404 |    21 |
| Category |   0 |      0 |   421 |
| Detail   |   1 |    874 |    21 |
| Detail   |   0 |      0 |   887 |
+----------+-----+--------+-------+
Attached Files:
Notes
(0013022)
HR   
2019-10-16 10:04   
This issue had been fixed in CE [6.3.2] - 2019-01-22, compilation v6.1.2.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6892 [OXID eShop (all versions)] 4.01. Database handling major always 2018-08-20 18:29 2019-10-15 13:20
Reporter: timwetter Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.1.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.2.0-rc.1  
    Target Version: 6.2.0-rc.1  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: oxDB:: quoteArray & getTableDescription breaks $ADODB_FETCH_MODE
Description: there are many ways to break db fetch_mode, but one example

do this in one function:
- on top write $oDb = oxDb::getDb(true);
- make a oxlist
- call selectString with a wildcard (e.g. "select * from oxarticles limit 55")
- after that do something like this in the same function:
$rs = $oDb->execute("select oxartnum, oxtitle from oxarticles");
            if ($rs != false && $rs->recordCount() > 0) {
                while (!$rs->EOF) {
                      print_r($rs->fields) // look at the numeric fields -> but they should be assoc
                }
             }

please have a look @"additional information" to see my fix for this
maybe you'll find more of this bullsh*

Tags:
Steps To Reproduce:
Additional Information:     /**
     * Quotes an array.
     *
     * @param array $aStrArray array of strings to quote
     *
     * @return array
     */
    public function quoteArray( $aStrArray)
    {
        global $ADODB_FETCH_MODE;
        $save = $ADODB_FETCH_MODE;

        foreach ( $aStrArray as $sKey => $sString ) {
            $aStrArray[$sKey] = self::getDb()->quote($sString);
        }

        // restore fetchmode
        $ADODB_FETCH_MODE = $save;

        return $aStrArray;
    }

    /**
     * Extracts and returns table metadata from DB.
     *
     * @param string $sTableName Name of table to invest.
     *
     * @return array
     */
    public function getTableDescription( $sTableName )
    {
        // simple cache
        if ( isset( self::$_aTblDescCache[$sTableName] ) ) {
            return self::$_aTblDescCache[$sTableName];
        }

        global $ADODB_FETCH_MODE;
        $save = $ADODB_FETCH_MODE;

        $aFields = self::getDb()->MetaColumns( $sTableName );

        // restore fetchmode
        $ADODB_FETCH_MODE = $save;

        self::$_aTblDescCache[$sTableName] = $aFields;

        return $aFields;
    }
Attached Files:
Notes
(0012589)
QA   
2018-08-21 10:55   
(Last edited: 2018-08-21 10:58)
Script to reproduce (execute it in bin/):
<?php

echo PHP_EOL . 'fetch mode test.' . PHP_EOL;

require_once '../bootstrap.php';

$db = \OxidEsales\Eshop\Core\DatabaseProvider::getDb();


echo 'set fetch mode to assoc (equals string)'; 
echo PHP_EOL;
$db->setFetchMode(\OxidEsales\Eshop\Core\Database\Adapter\DatabaseInterface::FETCH_MODE_ASSOC);


$query = 'select oxid from oxuser limit 1';

$a = $db->getAll($query);
echo 'get fetch mode: ';
echo gettype(key($a[0]));
echo PHP_EOL;


echo 'execute some native methods... ';
echo PHP_EOL;

$c = oxNew(\OxidEsales\Eshop\Application\Model\Category::class);
$c->load('0f40c6a077b68c21f164767c4a903fd2');
$s = oxNew(\OxidEsales\Eshop\Application\Model\SeoEncoderCategory::class);
$s->markRelatedAsExpired($c);


$a = $db->getAll($query);
echo 'get fetch mode: ';
echo gettype(key($a[0]));
echo PHP_EOL;

echo 'test done.' . PHP_EOL;

MK

(0013018)
afshar5152   
2019-10-14 17:30   
(Last edited: 2019-10-15 13:20)
This bug was fixed in version 6.2, but it is still lives in version 6.1 and for handling that the best solution is using "setFetchMode" method before using "getAll" or "getOne" methods. Therefore fetch_mode will be set before fetching data from database.
For example:

$c = oxNew(\OxidEsales\Eshop\Application\Model\Category::class);
$c->load('0f40c6a077b68c21f164767c4a903fd2');
$s = oxNew(\OxidEsales\Eshop\Application\Model\SeoEncoderCategory::class);
$s->markRelatedAsExpired($c);

$db->setFetchMode(DatabaseProvider::FETCH_MODE_NUM);
$a = $db->getAll($query);

In version 6.2, DatabaseProvider was deprecated and replaced by OxidEsales\EshopCommunity\Internal\Framework\Database\QueryBuilderFactoryInterface. So there is not this bug anymore.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7038 [OXID eShop (all versions)] 1.01. Products (product, categories, manufacturer, promotions etc.) tweak always 2019-10-01 22:11 2019-10-02 09:00
Reporter: mario_lorenz Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: All
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: manipulable GET request parameter executes wrong dynamic method call
Description: The OxidEsales\EshopCommunity\Application\Controller\FrontendController->getListType() returns the content of RequestParameter 'listtype'.

This content would be used in OxidEsales\EshopCommunity\Application\Component\Locator->setLocatorData($oCurrArticle, $oLocatorTarget) to create a dynamic method-call:

$sLocfnc = "_set{$this->_sType}LocatorData";
$this->$sLocfnc($oLocatorTarget, $oCurrArticle);

At this point there is no verification that the method "$sLocfnc" exists at all.

If I now manipulate the GET variable "listtype", an exception is thrown and written into the error log.

So i have various error-log-entries like this: Function '_setsearch AND 1=1LocatorData' does not exist or is not accessible!
For me, this is a sign that the shop is being "investigated" for SQL injections or similar vulnerabilities.

That's not bad, but not nice either. It would be better to check in advance if the method exits. So no meaningless log entries are generated.


_setsearch AND 1=1LocatorData
Tags:
Steps To Reproduce: Manipulate the listtype-GET-Parameter in the links of an article-details-page. Then have a look to your OXID-error-log.
Additional Information:
Attached Files:
Notes
(0013013)
QA   
2019-10-02 09:00   
-MK


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7037 [OXID eShop (all versions)] 4.07. Source code, Test major always 2019-09-25 17:01 2019-09-25 17:50
Reporter: pbenke Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: 7.1
Database Version: Not defined
Summary: Misspelling in function call
Description: Misspelling in function call:

File:
vendor/oxid-esales/oxideshop-ce/source/Application/Model/Order.php

Function:
_sendOrderByEmail()

Misspelling function calls:
- sendOrderEMailToUser => correct would be: sendOrderEmailToUser (small "m")
- sendOrderEMailToOwner => correct would be sendOrderEmailToOwner (small "m")




Tags: Email, Order
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7036 [OXID eShop (all versions)] 1.03. Basket, checkout process feature always 2019-09-18 13:32 2019-09-20 12:30
Reporter: mikkelfilla Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: method for handling packingunits exists only in OXID eShop EE
Description: The content of the following method should be in the OXID eShop CE:

\OxidEsales\EshopEnterprise\Application\Model\Article::checkForVpe

The reason for my proposal is that the method does not include any special OXID eShop EE (sub shop) functionality and in the OXID eShop CE this method is empty.

The method handles the article field "Packingunit" which defines the amount that should be added to the basket.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6966 [OXID eShop (all versions)] 2.4. Administer products minor always 2019-03-28 12:52 2019-09-19 16:26
Reporter: tho90 Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: resolved Product Version: 6.1.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.1.5  
    Target Version:  
Theme: Wave
Browser: Internet Explorer
PHP Version: Not defined
Database Version: Not defined
Summary: Article status: active
Description: We have uploaded some articles with a certain activation date.
Result: The articles were displayed at the time in the shop, but in the backend not marked as "active" with a green symbol.
These articles are also not displayed on the start page “Just arrived”
Tags: Article
Steps To Reproduce:
Additional Information:
Attached Files: Article_active.PNG (48,201 bytes) 2019-03-28 12:52
https://bugs.oxid-esales.com/file_download.php?file_id=1697&type=bug
Artikel_1208.JPG (291,510 bytes) 2019-04-01 09:12
https://bugs.oxid-esales.com/file_download.php?file_id=1698&type=bug
active.PNG (36,256 bytes) 2019-04-01 10:45
https://bugs.oxid-esales.com/file_download.php?file_id=1699&type=bug
Notes
(0012828)
QA   
2019-04-01 09:11   
(Last edited: 2019-04-02 07:55)
looks as if no articles are displayed as active (green) in your shop installation.
In a reference shop EE 6.1.2 the articles are marked as "active" with a green symbol.
Therefore the bug will be closed as not reproducible.

es

(0012829)
tho90   
2019-04-01 09:57   
The problem is that articles are visible on the frontend even though they are not shown as active in the Baclend (green marked)
(0012830)
QA   
2019-04-01 10:41   
In a reference installation (see attached file above Article_1208.jpg) articles are also shown as active in the Baclend (green marked)
(0012831)
tho90   
2019-04-01 10:44   
yes, because you have checked the checkbox!
(0012832)
tho90   
2019-04-01 10:47   
can we have a call? +436649696880
(0012833)
QA   
2019-04-01 11:11   
If set to inactive, the articles are still displayed in the frontend.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5925 [OXID eShop (all versions)] 2.3. Extensions (modules, themes) major always 2014-10-22 12:40 2019-09-19 10:58
Reporter: leofonic Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 4.9.0 / 5.2.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Azure
Browser: All
PHP Version: Not defined
Database Version: Not defined
Summary: Template Blocks are not cleared when deactivating module
Description: If you have a module with template blocks and deactivate the module, template blocks are still active until /tmp is emptied manually.
Tags: Template Blocks
Steps To Reproduce: To reproduce install attached module, activate and deactivate.
Additional Information: Reason is in oxmoduleinstaller::deactivate, template blocks are deleted from database. After this module cache is cleared, but because template blocks have already been deleted, no cache files to delete are found. If the order is reversed and template cache is cleared first, the error is gone.
Attached Files: testblocks.zip (1,507 bytes) 2014-10-22 12:40
https://bugs.oxid-esales.com/file_download.php?file_id=1327&type=bug
Notes
(0013005)
dominik_ziegler   
2019-09-19 09:35   
Also, when re-activating a module which got deactivated automatically due to module errors, template blocks in database table oxtplblocks gets duplicated (they are inserted again), because they are not removed on auto deactivation or on re-activating via backend. This gets really annoying in module development.
(0013006)
QA   
2019-09-19 10:58   
Hello dominik_ziegler,

there is already another issue entry regarding your described behavior:
https://bugs.oxid-esales.com/view.php?id=6261

[sp]


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7032 [OXID eShop (all versions)] 4.08. Cache minor always 2019-09-12 10:56 2019-09-17 16:04
Reporter: bdreissig Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: 7.1
Database Version: 5.7
Summary: [EE] Cache-Control entry adds falsy semicolon
Description: In ReverseProxyHeader.php, the setCacheAge() Method adds a falsy semicolon to the end of the Cache-Control HTTP header.

This breaks Varnish 6.0 header parsing and leaves beresp.ttl at zero for every request.
Tags:
Steps To Reproduce: - Use Varnish 6.0 as reverse proxy for an oxid EE 6.1.4 shop
- Add some logging for beresp.ttl in and header values in the Varnish VCL's vcl_backend_response sub
- Use varnishlog to track the header set by the shop on requests
Additional Information:
Attached Files:
Notes
(0013004)
QA   
2019-09-17 16:04   
There is indeed no syntax description which says how the line should end.
Both RFC and developer.mozilla.org are talking only about comma separated lists

See:
- https://tools.ietf.org/html/rfc7234#section-5.2.2.9
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control

-MK


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7031 [OXID eShop (all versions)] 6. ------ Setup ------- minor always 2019-09-11 15:38 2019-09-12 09:30
Reporter: kaistrecker Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: For Mexico there are no states stored in OXID, which can lead to problems with PayPal.
Description: No states are deposited in OXID for Mexico. This means that you cannot pay via PayPal, because PayPal returns an error message if no state is specified.
I have attached a file with SQL queries, which adapt the database accordingly.
I took the states and country codes directly from the PayPal website: https://developer.paypal.com/docs/api/reference/state-codes/#mexico .
Tags:
Steps To Reproduce:
Additional Information: - es -
Attached Files: OXID Mexiko Staaten Fix.txt (2,985 bytes) 2019-09-11 15:38
https://bugs.oxid-esales.com/file_download.php?file_id=1765&type=bug
Notes
(0012996)
QA   
2019-09-12 09:30   
ALTER TABLE `oxstates` CHANGE COLUMN `OXISOALPHA2` `OXISOALPHA2` CHAR(5) NOT NULL DEFAULT '' COMMENT 'SEO short name' AFTER `OXTITLE`;

INSERT INTO `oxstates` (`OXID`, `OXCOUNTRYID`, `OXTITLE`, `OXISOALPHA2`, `OXTITLE_1`, `OXTITLE_2`, `OXTITLE_3`) VALUES
('AGS', '8f241f11095ebf3a6.86388577', 'Aguascalientes', 'AGS', 'Aguascalientes', '', ''),
('BC', '8f241f11095ebf3a6.86388577', 'Baja California', 'BC', 'Baja California', '', ''),
('BCS', '8f241f11095ebf3a6.86388577', 'Baja California Sur', 'BCS', 'Baja California Sur', '', ''),
('CAMP', '8f241f11095ebf3a6.86388577', 'Campeche', 'CAMP', 'Campeche', '', ''),
('CHIS', '8f241f11095ebf3a6.86388577', 'Chiapas', 'CHIS', 'Chiapas', '', ''),
('CHIH', '8f241f11095ebf3a6.86388577', 'Chihuahua', 'CHIH', 'Chihuahua', '', ''),
('CDMX', '8f241f11095ebf3a6.86388577', 'Ciudad de México', 'CDMX', 'Ciudad de México', '', ''),
('COAH', '8f241f11095ebf3a6.86388577', 'Coahuila', 'COAH', 'Coahuila', '', ''),
('COL', '8f241f11095ebf3a6.86388577', 'Colima', 'COL', 'Colima', '', ''),
('DF', '8f241f11095ebf3a6.86388577', 'Distrito Federal', 'DF', 'Distrito Federal', '', ''),
('DGO', '8f241f11095ebf3a6.86388577', 'Durango', 'DGO', 'Durango', '', ''),
('MEX', '8f241f11095ebf3a6.86388577', 'Estado de México', 'MEX', 'Estado de México', '', ''),
('GTO', '8f241f11095ebf3a6.86388577', 'Guanajuato', 'GTO', 'Guanajuato', '', ''),
('GRO', '8f241f11095ebf3a6.86388577', 'Guerrero', 'GRO', 'Guerrero', '', ''),
('HGO', '8f241f11095ebf3a6.86388577', 'Hidalgo', 'HGO', 'Hidalgo', '', ''),
('JAL', '8f241f11095ebf3a6.86388577', 'Jalisco', 'JAL', 'Jalisco', '', ''),
('MICH', '8f241f11095ebf3a6.86388577', 'Michoacán', 'MICH', 'Michoacán', '', ''),
('MOR', '8f241f11095ebf3a6.86388577', 'Morelos', 'MOR', 'Morelos', '', ''),
('NAY', '8f241f11095ebf3a6.86388577', 'Nayarit', 'NAY', 'Nayarit', '', ''),
('NL', '8f241f11095ebf3a6.86388577', 'Nuevo León', 'NL', 'Nuevo León', '', ''),
('OAX', '8f241f11095ebf3a6.86388577', 'Oaxaca', 'OAX', 'Oaxaca', '', ''),
('PUE', '8f241f11095ebf3a6.86388577', 'Puebla', 'PUE', 'Puebla', '', ''),
('QRO', '8f241f11095ebf3a6.86388577', 'Querétaro', 'QRO', 'Querétaro', '', ''),
('ROO', '8f241f11095ebf3a6.86388577', 'Quintana Roo Q', 'ROO', 'Quintana Roo Q', '', ''),
('SLP', '8f241f11095ebf3a6.86388577', 'San Luis Potosí', 'SLP', 'San Luis Potosí', '', ''),
('SIN', '8f241f11095ebf3a6.86388577', 'Sinaloa', 'SIN', 'Sinaloa', '', ''),
('SON', '8f241f11095ebf3a6.86388577', 'Sonora', 'SON', 'Sonora', '', ''),
('TAB', '8f241f11095ebf3a6.86388577', 'Tabasco', 'TAB', 'Tabasco', '', ''),
('TAMPS', '8f241f11095ebf3a6.86388577', 'Tamaulipas', 'TAMPS', 'Tamaulipas', '', ''),
('TLAX', '8f241f11095ebf3a6.86388577', 'Tlaxcala', 'TLAX', 'Tlaxcala', '', ''),
('VER', '8f241f11095ebf3a6.86388577', 'Veracruz', 'VER', 'Veracruz', '', ''),
('YUC', '8f241f11095ebf3a6.86388577', 'Yucatán', 'YUC', 'Yucatán', '', ''),
('ZAC', '8f241f11095ebf3a6.86388577', 'Zacatecas', 'ZAC', 'Zacatecas', '', '');


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7029 [OXID eShop (all versions)] 1.02. Price calculations (discounts, coupons, additional costs etc.) minor always 2019-09-09 11:08 2019-09-09 11:43
Reporter: ano19 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.0.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Flow
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Redeem voucher "0" breaks frontend
Description: Redeem voucher "0" breaks frontend
Tags:
Steps To Reproduce:
Additional Information: - es -
Attached Files:
Notes
(0012990)
QA   
2019-09-09 11:21   
Need more Infos or screenshot so that the bug can be adjusted
(0012991)
ano19   
2019-09-09 11:38   
Just go to demoshop, add article to basket, go to basket, type voucher "0" and try to redeem. White page appears then and frontend breaks.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7028 [OXID eShop (all versions)] 2. ----- eShop backend (admin) ----- minor always 2019-09-06 10:00 2019-09-06 10:25
Reporter: juergen_busch Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Export: dataset is incomplete
Description: During the export this dataset per product is written:
"Prod.No.";"Title";"?";"Short Description","Long Description";?;RRP ;Price;?;SEO URL
Positions 3, 6 and 9 are always empty.

From vendor/oxid-esales/oxideshop-ce/source/Application/views/admin/tpl/genexport.tpl:

1. [{$article->oxarticles__oxartnum->value|oxenclose:$encl}][{$spr}]
2. [{$article->oxarticles__oxtitle->value|strip_tags|oxenclose:$encl}][{$spr}]
3. [{$article->oxcategories__oxtitle->value|strip_tags|oxenclose:$encl}][{$spr}]
4. [{$article->oxarticles__oxshortdesc->value|strip_tags|oxenclose:$encl}][{$spr}]
5. [{$article->getLongDesc()|strip_tags|oxenclose:$encl}][{$spr}]
6. [{$article->pic1}][{$spr}]
7. [{$article->oxarticles__oxtprice->value}][{$spr}][{$article->getFPrice()}][{$spr}]
8. [{$article->valid}][{$spr}]
9. [{$article->getLink()|replace:"&":"&"}]
Tags:
Steps To Reproduce: Export demo data and have a look at the datasets in genexport.txt.
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7027 [OXID eShop (all versions)] 1.02. Price calculations (discounts, coupons, additional costs etc.) minor always 2019-09-05 12:32 2019-09-05 12:41
Reporter: QA Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: demodata discount is not possible with other discounts, because non-existent article is assigned
Description: The demo data discounts cannot be combined with each other, because the discount "10% from 200 Euro purchase value" is assigned an article, which is not visible in the backend, but is assigned in the oxobject2discounts (see screenshot).

When deleted the discounts can be combined.
Tags:
Steps To Reproduce: 1. in shop Backend activate the discount "10% ab 200 Euro Einkaufswert" as shown in screenshot.
    Both discounts have no articles / categories and no user / usergroups assigned
2. In frontend put an article in basket.
    Now both discounts should be considered.

But only one is considered.
Delete entry in oxobject2discounts with oxobjectid 1771
Now both were considered.
Additional Information: - es -
Attached Files: oxobject2discount.JPG (172,237 bytes) 2019-09-05 12:32
https://bugs.oxid-esales.com/file_download.php?file_id=1759&type=bug
discount.JPG (78,935 bytes) 2019-09-05 12:32
https://bugs.oxid-esales.com/file_download.php?file_id=1760&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6001 [OXID eShop (all versions)] 1.01. Products (product, categories, manufacturer, promotions etc.) minor always 2014-12-16 11:06 2019-09-04 14:25
Reporter: michael_keiluweit Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 4.9.2 / 5.2.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Azure
Browser: All
PHP Version: Not defined
Database Version: Not defined
Summary: R&R for not listing variants doesn't work
Description: When setting an variant invisible for a user by using the rights and roles, then the shop doesn't consider R&R and simply lists all variants.
If the parent is set invisible by R&R it works fine.
Tags: Article, Rights & Roles, Variants
Steps To Reproduce: 1. Use a EE shop
2. Create a article
3. Create two variants for the article from step 2.
4. Edit one of the two variant articles and switch to the tab "rights".
5. Add only the admin user to the left site of the ajax fields.
6. Goto the frontend (be aware that you haven't a session with admin rights) and navigate to the article from step 2. Expand the select list and see that the variant is still listed.

7. Go back to the administration area and repeat the steps 5 and 6 for the parent article. At the frontend it will be gone now, because it works and you haven't the rights to get it displayed.
Additional Information:
Attached Files:
Notes
(0012980)
dominik_ziegler   
2019-09-04 14:25   
In method getLoadVariantsQuery getSqlActiveSnippet should be called instead of getActiveCheckQuery.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7026 [OXID eShop (all versions)] 2. ----- eShop backend (admin) ----- minor always 2019-09-03 09:47 2019-09-03 11:01
Reporter: juergen_busch Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Campaign and its main category are still not exported
Description: There is a possibility to add "Promotion Parameter" and "Add category to campaign parameter" to the exported data.
* Campaign and its main category are not exported as a part of the URL of the products
* "Promotion Parameter" should be "Campaign Parameter"
* "Add category to campaign parameter" should be "Add main category to campaign parameter"
* This bug should be fixed in 2008: https://bugs.oxid-esales.com/bug_update_page.php?bug_id=179
Tags:
Steps To Reproduce: * Fill in a campaign name (only 10 characters possible!)
* Check "Add category to campaign parameter"
* Export products
* Have a look at the exported URLs: nothing happened
Additional Information: -es-
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6928 [OXID eShop (all versions)] 1.01. Products (product, categories, manufacturer, promotions etc.) feature always 2018-12-04 11:04 2019-09-02 13:20
Reporter: mediaworker Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.0.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Categorienames at the end of an url consisting only of digits are interpreted as page numbers
Description: Suppose to have a category structure like batterie/2032/ then clicking to this categorie the shop will make an redirect to batterie/

This happens in Controller/ArticleListController.php in function _checkRequestedPage():

...
        if ($pageCount && (($pageCount - 1) < $currentPageNumber)) {
            \OxidEsales\Eshop\Core\Registry::getUtils()->redirect($this->getActiveCategory()->getLink(), false);
        }

the interpretion of digits in an url only as page number happens in Core/SeoDecoder.php, function extractPageNumberFromSeoUrl($seoUrl). With this grep pattern all numbers become page numbers:

preg_match('/(.*?)\/(\d+)\/(.*)/', $seoUrl, $matches)

We think at this point the software has to check if the number ist an exsting category.
Tags: 404, Category, Redirect
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012718)
QA   
2018-12-04 14:21   
Hi

as this is a specific use case I changed the entry to a feature request, so our PM can check it. Also because the shop is working as intended: Digits at the end of an URL are to interpreted as page numbers.
In the meantime I suggest to give the category a prefix to identify them as a category and not as a page number like "https://example.com/batterie/c-665/"

Kind regards,
QA

-MK
(0012970)
d3   
2019-09-02 13:20   
Why is that a feature? Categories can be created with number names and create exactly this SEO address without error message. The call of this generated SEO address then no longer works. The definition of a specific case does not necessarily exclude the definition as a (rare) bug.

By the way: In shop version 4.7, these SEO addresses also worked with page switches.

DS


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7022 [OXID eShop (all versions)] 2. ----- eShop backend (admin) ----- minor always 2019-09-02 11:32 2019-09-02 12:04
Reporter: juergen_busch Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: EE 6: links to documentation are wrong
Description: Links from the admin area are wrong. Example:
EE 6.1.3: http://docu.oxid-esales.com/PE/6.1.3/0/admin/article_main.html
EE 5.3.2: http://docu.oxid-esales.com/EE/5.3.2/0/admin/article_main.html

The /PE/ in the URL prevents EE specific documents (caching, rights, mall) from being called.
Tags:
Steps To Reproduce: Compare links to the documentation in EE 5 and EE 6.
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6671 [OXID eShop (all versions)] 2.6. Administer orders minor always 2017-07-25 22:25 2019-08-28 17:40
Reporter: Pauleo77 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 4.10.4 / 5.3.4  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.1.5  
    Target Version:  
Theme: Flow
Browser: Firefox
PHP Version: Not defined
Database Version: Not defined
Summary: Function "Variants inherit Scale Prices from "Parent" Product" does not work in backend
Description: The recalculation of an order in the backend does not work for products with variants. The variants does not inherit the scale prices from the parent product. If I use the button "Update" within an order under "Administer Orders" --> "Orders --> "Select Order" --> "Products", the scale prices from the parent product are ignored for products with variants. The issue only occures, if the product has a variant. The recalculation does work correctly with products without variants.
In the frontend/basket the calculation of the scale prices does work for products without variants and does also work for products with variants.
The problem only exists in the backend, if the ordered product has a variant.

If I create additional scale prices for the variant, the recalculation does work in the backend. So it seems that the function "Variants inherit Scale Prices from "Parent" Product" does not work in backend.
Tags:
Steps To Reproduce: The steps below are tested in the demo ce shop:
1. Create a selection list called "Color" and add the field "red"
2. Edit the product "Trapez ION SOL KITE 2011" and create a scale price (Quantity From: 2 To: 10 Price: 100 €)
3. Add a variant to the product "Trapez ION SOL KITE 2011". Choose the selection list created above and activate the variant.
4. Edit the existing order (order no. 1) and add the product "Trapez ION SOL KITE 2011" with the variant (color = red) to the order (Quantity = 1).
5. Now the order contains the product "Trapez ION SOL KITE 2011" two times. One time without a variant and one time with a variant. Both products have the same price of 129,00 €.
6. Edit the quantity of both products to the value 2.
7. Press the button "Update".
8. The scale price does only work for the product without variant.
Additional Information:
Attached Files:
Notes
(0012634)
Pauleo77   
2018-10-08 14:41   
The problem still appears with Oxid CE 6.1.0.
In my opinion the severity should be raised to "major", because the recalculation of an existing order in the backend does not work correctly.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6811 [OXID eShop (all versions)] 1.02. Price calculations (discounts, coupons, additional costs etc.) minor always 2018-03-20 11:57 2019-08-23 11:15
Reporter: fthielen Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.0.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.2.0-rc.1  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Scale Prices in Netto
Description: In OXID 6 the Scale Prices are always shown as entered, even if the option "Enter Product Prices as Net Prices (plus VAT)" is enabled.
All other prices are shown in brutto, as they should.
Tags: Scale Price, VAT
Steps To Reproduce: 1. Enable the Option "Enter Product Prices as Net Prices (plus VAT)" in the Backend
2. Set a scale price for a article
Additional Information:
Attached Files:
Notes
(0012424)
marco_steinhaeuser   
2018-03-20 16:36   
https://forum.oxid-esales.com/t/oxid-6-mengenstaffelpreise-werden-nicht-brutto-angezeigt/93258/
(0012436)
hrieth   
2018-04-12 15:10   
Hello,
i think there are two problem:

1. \OxidEsales\EshopCommunity\Application\Model\Article::_prepareModifiedPrice
    /**
     * @param double $dPrice
     *
     * @return double
     */
    protected function _prepareModifiedPrice($dPrice)
    {
        $this->_preparePrice($dPrice, $this->getArticleVat());

        return $dPrice;
    }

should be

    /**
     * @param double $dPrice
     *
     * @return double
     */
    protected function _prepareModifiedPrice($dPrice)
    {
        $dPrice = $this->_preparePrice($dPrice, $this->getArticleVat());

        return $dPrice;
    }

2. in Flow source/Application/views/flow/tpl/page/details/inc/priceinfo.tpl:21

                                [{block name="details_productmain_price"}]
                                    [{$priceItem->fbrutprice}] [{$currency->sign}]
                                    [{if $oDetailsProduct->getUnitName() and $priceItem->fbrutamountprice}]
                                         ([{$priceItem->fbrutamountprice}] [{$currency->sign}] / [{$oDetailsProduct->getUnitName()}])
                                    [{/if}]
                                [{/block}]

should be

                                [{block name="details_productmain_price"}]
                                [{assign var="oConfig" value=$oView->getConfig()}]
                                [{if $oConfig->getConfigParam('blShowNetPrice')}]
                                    [{$priceItem->fnetprice}] [{$currency->sign}]
                                    [{if $oDetailsProduct->getUnitName() and $priceItem->fnetamountprice}]
                                         ([{$priceItem->fnetamountprice}] [{$currency->sign}] / [{$oDetailsProduct->getUnitName()}])
                                    [{/if}]
                                [{else}]
                                    [{$priceItem->fbrutprice}] [{$currency->sign}]
                                    [{if $oDetailsProduct->getUnitName() and $priceItem->fbrutamountprice}]
                                         ([{$priceItem->fbrutamountprice}] [{$currency->sign}] / [{$oDetailsProduct->getUnitName()}])
                                    [{/if}]
                                [{/if}]
                                [{/block}]

Greetings
Helmut
(0012945)
bYemma   
2019-07-18 14:07   
Thank you, Helmuth. Your solution works like a charm.

This should be fixed!
(0012955)
Alpha-Sys   
2019-08-01 17:20   
I created a pull request for the first part of the bugfix: https://github.com/OXID-eSales/oxideshop_ce/pull/720
(0012969)
bYemma   
2019-08-23 10:03   
Bugfix is now merged into wave and flow.

Flow commit: https://github.com/OXID-eSales/flow_theme/pull/151
Wave commit: https://github.com/OXID-eSales/wave-theme/pull/65


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6312 [OXID eShop (all versions)] 2.6. Administer orders feature unable to reproduce 2016-01-14 16:12 2019-08-12 16:24
Reporter: vschmi Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 4.9.6 / 5.2.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: 5.6
Database Version: 5.6
Summary: Duplicate invoice numbers
Description: On our system duplicate invoice numbers are generated. OXID does not prevent this from happening. This is a serious issue, especially it is unnoticed.

Suggestion: Create an unique index over OXSHOPID and OXBILLNR to prevent that from happening. An error with log entries is much better than silently creating duplicate invoice numbers.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0011430)
vschmi   
2016-01-14 16:13   
Also, this issue happens only rarely so it's currently not possible to provide any information how to reproduce this issue, especially because it goes by unnoticed as OXID's database structure allows for duplicate invoice numbers.

From 64250 orders, 14 orders are affected. But that's 14 orders too many.
(0011432)
vschmi   
2016-01-14 17:45   
In fact the index alone is not enough, since by default there's no invoice number.

To me this looks like a race condition which is probably caused since we got multiple users working at the same time.

To solve this properly, a separate invoice table would be required.
(0011433)
FibreFoX   
2016-01-14 17:59   
This is more a bug than a feature (IMHO)
(0012863)
anton.fedurtsya   
2019-04-23 16:12   
Hello there. There is a pull request (https://github.com/OXID-eSales/oxideshop_ce/pull/553), which could help solve the problem, but its not prepared to merge. Please check the solution suggested there while working on fixing this issue.
(0012958)
tte   
2019-08-12 16:14   
(Last edited: 2019-08-12 16:24)
A few months back, we had a similar problem with duplicate values in the OXORDERNR column. It didn't happen again since then, but adding a UNIQUE constraint might help as a workaround (besides logging if there's a constraint violation for finding the root cause).

OXID version: 6.1.4
Additional payment types: PayPal



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6696 [OXID eShop (all versions)] 6. ------ Setup ------- minor always 2017-09-14 11:36 2019-08-02 11:17
Reporter: juergen_busch Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.1.4  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Guestbook option remains in footer settings of the Flow theme
Description: Guestbook option remains in the footer settings of the Flow theme and shows this label: "ERROR: Translation for SHOP_THEME_blFooterShowGuestbook not found!".
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012861)
anton.fedurtsya   
2019-04-18 14:51   
This one will is fixed in new demodata version: v6.0.2. There should be no problem with this question in the release which will use new demodata.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7002 [OXID eShop (all versions)] 4.04. Security critical always 2019-06-26 14:52 2019-08-02 09:32
Reporter: marco_steinhaeuser Platform:  
Assigned To: OS:  
Priority: urgent OS Version:  
Status: resolved Product Version: 6.1.3  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.0.5  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Pre-Auth SQL injection possible
Description: Remote Code Execution possible due to the possibility of Pre-Auth SQL injection.
Tags:
Steps To Reproduce:
Additional Information: Credits: Robin Peraglie (ripstech.com)
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6973 [OXID eShop (all versions)] 4.04. Security minor always 2019-04-24 13:25 2019-07-31 11:19
Reporter: marco_steinhaeuser Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.1.3  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.1.4  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Admin: File upload extension filter can be bypassed
Description: The security of other file uploads in the admin interface was questioned and subsequently assessed. The reporter found that these endpoints use an insufficient blacklist approach to prohibit an admin from uploading potentially malicious files.
Tags:
Steps To Reproduce: for steps to reproduce pls visit https://bugs.oxid-esales.com/view.php?id=6973#c12864
Additional Information: Affected File:
vendor/oxid-esales/oxideshop-ce/source/Core/UtilsFile.php

Affected Code:
protected $_aBadFiles = ['php', 'php3', 'php4', 'php5', 'phps', 'php6', 'jsp', 'cgi', 'cmf', 'exe'];

Not filtered extensions:
.phtml
.pht
Attached Files:
Notes
(0012871)
QA   
2019-04-24 14:02   
-MK


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6890 [OXID eShop (all versions)] 4.04. Security minor always 2018-08-20 14:39 2019-07-31 11:18
Reporter: anton.fedurtsya Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.1.4  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: SQL injections possible in admin interface
Description: There are 2 SQL Injection possibilities in

oxideshop_ce/source/Application/Controller/Admin/CategoryOrderAjax.php

Line 120 in ec33d6d

             $sSelect .= "where $sO2CView.oxcatnid = '$soxId' and $sArticleTable.oxparentid = '' and $sArticleTable.oxid ";

as $soxId is not escaped when in admin.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6974 [OXID eShop (all versions)] 4.04. Security minor always 2019-04-24 13:50 2019-07-31 11:14
Reporter: marco_steinhaeuser Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.1.3  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.1.4  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Parameters are not escaped in RDFa payment data
Description: The user-controlled parameter is directly placed into the SQL statement without any escaping
Tags:
Steps To Reproduce: see https://bugs.oxid-esales.com/view.php?id=6974#c12867 for steps to reproduce
Additional Information: Pls see https://bugs.oxid-esales.com/view.php?id=6974#c12868 for additional information
Attached Files:
Notes
(0012870)
QA   
2019-04-24 14:02   
-MK


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6895 [OXID eShop (all versions)] 4.01. Database handling tweak always 2018-09-03 11:10 2019-07-30 21:42
Reporter: simon.runer Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.0.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Column OXTYPE missing in oxobject2group and misleading MySql comment
Description: The comment on table oxobject2group says (https://github.com/OXID-eSales/oxideshop_ce/blob/master/source/Setup/Sql/database_schema.sql)
"Shows many-to-many relationship between users and groups" which is incorrect. There are stored also relationships between oxpayments and oxgroups and probably others.
As in other tables there should by a OXTYPE column to identify the related table.

Tags: Database
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012604)
QA   
2018-09-03 11:53   
Also misleading is the comment for the attribute oxobjectid, which reads "User id".

[sp]
(0012951)
simon.runer   
2019-07-30 21:42   
In case it helps, with this query you can get the table with OXTYPE. You might need to add tables from modules which added entries to oxobject2group.
Any chance OXTYPE will be added to oxobject2group?

SELECT o2g.OXID, o2g.OXSHOPID, o2g.OXOBJECTID, o2g.OXGROUPSID, o2g.OXTIMESTAMP,
   CASE
       WHEN u.OXID IS NOT NULL THEN 'oxuser'
       WHEN p.OXID IS NOT NULL THEN 'oxpayments'
       WHEN di.OXID IS NOT NULL THEN 'oxdiscount'
       WHEN de.OXID IS NOT NULL THEN 'oxdelivery'
       WHEN des.OXID IS NOT NULL THEN 'oxdeliveryset'
       WHEN v.OXID IS NOT NULL THEN 'oxvouchers'
       WHEN vs.OXID IS NOT NULL THEN 'oxvoucherseries'
       WHEN n.OXID IS NOT NULL THEN 'oxnews'
       WHEN nl.OXID IS NOT NULL THEN 'oxnewsletter'
       WHEN sp.OXID IS NOT NULL THEN 'smx_promotions'
       ELSE ''
   END AS OXTYPE
FROM oxobject2group AS o2g
LEFT JOIN oxuser AS u ON o2g.OXOBJECTID = u.OXID
LEFT JOIN oxpayments AS p ON o2g.OXOBJECTID = p.OXID
LEFT JOIN oxdiscount AS di ON o2g.OXOBJECTID = di.OXID
LEFT JOIN oxdelivery AS de ON o2g.OXOBJECTID = de.OXID
LEFT JOIN oxdeliveryset AS des ON o2g.OXOBJECTID = des.OXID
LEFT JOIN oxvouchers AS v ON o2g.OXOBJECTID = v.OXID
LEFT JOIN oxvoucherseries AS vs ON o2g.OXOBJECTID = vs.OXID;
LEFT JOIN oxnews AS n ON o2g.OXOBJECTID = n.OXID
LEFT JOIN oxnewsletter AS nl ON o2g.OXOBJECTID = nl.OXID;


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7013 [OXID eShop (all versions)] 4.01. Database handling minor always 2019-07-23 15:45 2019-07-23 15:46
Reporter: michael_keiluweit Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 6.1.4  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Migration from CE to PE works not when demodata were installed.
Description: Some database fields are missing when installing a CE shop with demo data. Those information are later needed to upgrade and run a PE edition. After doing the migration, the shop throws an exception (see additional information) and is not callable anymore, until the missing fields are added manually.

Tags: migration
Steps To Reproduce: 1. Install CE with demo data
2.
composer config repositories.oxid-esales composer https://professional-edition.packages.oxid-esales.com
composer require oxid-esales/oxideshop-metapackage-pe
3.
vendor/bin/oe-eshop-db_migrate migrations:migrate
vendor/bin/oe-eshop-db_views_generate
4. call the shop
Additional Information: The reason is located in \OxidEsales\EshopCommunity\Setup\Controller::installShopData.
There is a logic to determine if the demodata should be installed. If yes: execute demodata.sql. if no: execute initial_data.sql.



[2019-07-23 14:27:25] OXID Logger.ERROR: Unknown column 'oxv_oxshops_de.oxserial' in 'field list' ["[object] (OxidEsales\\Eshop\\Core\\Exception\\DatabaseErrorException(code: 1054): Unknown column 'oxv_oxshops_de.oxserial' in 'field list' at /var/www/html/vendor/oxid-esales/oxideshop-ce/source/Core/Database/Adapter/Doctrine/Database.php:938, Doctrine\\DBAL\\Exception\\InvalidFieldNameException(code: 0): An exception occurred while executing 'select `oxv_oxshops_de`.`oxid`, `oxv_oxshops_de`.`oxactive`, `oxv_oxshops_de`.`oxproductive`, `oxv_oxshops_de`.`oxdefcurrency`, `oxv_oxshops_de`.`oxdeflanguage`, `oxv_oxshops_de`.`oxname`, `oxv_oxshops_de`.`oxtitleprefix`, `oxv_oxshops_de`.`oxtitlesuffix`, `oxv_oxshops_de`.`oxstarttitle`, `oxv_oxshops_de`.`oxinfoemail`, `oxv_oxshops_de`.`oxorderemail`, `oxv_oxshops_de`.`oxowneremail`, `oxv_oxshops_de`.`oxordersubject`, `oxv_oxshops_de`.`oxregistersubject`, `oxv_oxshops_de`.`oxforgotpwdsubject`, `oxv_oxshops_de`.`oxsendednowsubject`, `oxv_oxshops_de`.`oxsmtp`, `oxv_oxshops_de`.`oxsmtpuser`, `oxv_oxshops_de`.`oxsmtppwd`, `oxv_oxshops_de`.`oxcompany`, `oxv_oxshops_de`.`oxstreet`, `oxv_oxshops_de`.`oxzip`, `oxv_oxshops_de`.`oxcity`, `oxv_oxshops_de`.`oxcountry`, `oxv_oxshops_de`.`oxbankname`, `oxv_oxshops_de`.`oxbanknumber`, `oxv_oxshops_de`.`oxbankcode`, `oxv_oxshops_de`.`oxvatnumber`, `oxv_oxshops_de`.`oxtaxnumber`, `oxv_oxshops_de`.`oxbiccode`, `oxv_oxshops_de`.`oxibannumber`, `oxv_oxshops_de`.`oxfname`, `oxv_oxshops_de`.`oxlname`, `oxv_oxshops_de`.`oxtelefon`, `oxv_oxshops_de`.`oxtelefax`, `oxv_oxshops_de`.`oxurl`, `oxv_oxshops_de`.`oxdefcat`, `oxv_oxshops_de`.`oxhrbnr`, `oxv_oxshops_de`.`oxcourt`, `oxv_oxshops_de`.`oxadbutlerid`, `oxv_oxshops_de`.`oxaffilinetid`, `oxv_oxshops_de`.`oxsuperclicksid`, `oxv_oxshops_de`.`oxaffiliweltid`, `oxv_oxshops_de`.`oxaffili24id`, `oxv_oxshops_de`.`oxedition`, `oxv_oxshops_de`.`oxversion`, `oxv_oxshops_de`.`oxseoactive`, `oxv_oxshops_de`.`oxtimestamp`, `oxv_oxshops_de`.`oxserial` from oxv_oxshops_de where 1  and oxv_oxshops_de.oxid = '1'':\n\nSQLSTATE[42S22]: Column not found: 1054 Unknown column 'oxv_oxshops_de.oxserial' in 'field list' at /var/www/html/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php:71, Doctrine\\DBAL\\Driver\\PDOException(code: 42S22): SQLSTATE[42S22]: Column not found: 1054 Unknown column 'oxv_oxshops_de.oxserial' in 'field list' at /var/www/html/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:106, PDOException(code: 42S22): SQLSTATE[42S22]: Column not found: 1054 Unknown column 'oxv_oxshops_de.oxserial' in 'field list' at /var/www/html/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:104)\n[stacktrace]\n#0 /var/www/html/vendor/oxid-esales/oxideshop-ce/source/Core/Database/Adapter/Doctrine/Database.php(621): OxidEsales\\EshopCommunity\\Core\\Database\\Adapter\\Doctrine\\Database->convertException(Object(Doctrine\\DBAL\\Exception\\InvalidFieldNameException))\n#1 /var/www/html/vendor/oxid-esales/oxideshop-ce/source/Core/Model/BaseModel.php(736): OxidEsales\\EshopCommunity\\Core\\Database\\Adapter\\Doctrine\\Database->select('select `oxv_oxs...')\n#2 /var/www/html/vendor/oxid-esales/oxideshop-ce/source/Core/Model/BaseModel.php(717): OxidEsales\\EshopCommunity\\Core\\Model\\BaseModel->getRecordByQuery('select `oxv_oxs...')\n#3 /var/www/html/vendor/oxid-esales/oxideshop-ce/source/Core/Model/BaseModel.php(669): OxidEsales\\EshopCommunity\\Core\\Model\\BaseModel->assignRecord('select `oxv_oxs...')\n#4 /var/www/html/vendor/oxid-esales/oxideshop-ce/source/Application/Controller/Admin/LoginController.php(82): OxidEsales\\EshopCommunity\\Core\\Model\\BaseModel->load(1)\n#5 /var/www/html/vendor/oxid-esales/oxideshop-ce/source/Application/Controller/Admin/LoginController.php(50): OxidEsales\\EshopCommunity\\Application\\Controller\\Admin\\LoginController->setShopConfigParameters()\n#6 /var/www/html/vendor/oxid-esales/oxideshop-ce/source/Core/ShopControl.php(453): OxidEsales\\EshopCommunity\\Application\\Controller\\Admin\\LoginController->render()\n#7 /var/www/html/vendor/oxid-esales/oxideshop-ce/source/Core/ShopControl.php(344): OxidEsales\\EshopCommunity\\Core\\ShopControl->_render(Object(OxidEsales\\Eshop\\Application\\Controller\\Admin\\LoginController))\n#8 /var/www/html/vendor/oxid-esales/oxideshop-ce/source/Core/ShopControl.php(276): OxidEsales\\EshopCommunity\\Core\\ShopControl->formOutput(Object(OxidEsales\\Eshop\\Application\\Controller\\Admin\\LoginController))\n#9 /var/www/html/vendor/oxid-esales/oxideshop-ce/source/Core/ShopControl.php(137): OxidEsales\\EshopCommunity\\Core\\ShopControl->_process('OxidEsales\\\\Esho...', NULL, NULL, NULL)\n#10 /var/www/html/vendor/oxid-esales/oxideshop-ce/source/Core/Oxid.php(26): OxidEsales\\EshopCommunity\\Core\\ShopControl->start()\n#11 /var/www/html/source/index.php(15): OxidEsales\\EshopCommunity\\Core\\Oxid::run()\n#12 /var/www/html/source/admin/index.php(11): require_once('/var/www/html/s...')\n#13 {main}\n"] []
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7012 [OXID eShop (all versions)] 4.06. Language and translations minor always 2019-07-20 11:54 2019-07-22 11:28
Reporter: marco_steinhaeuser Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: general lang.php shall be overwritable with a cust_lang.php file
Description: The general translation file for the frontend https://github.com/OXID-eSales/oxideshop_ce/tree/master/source/Application/translations/en/lang.php shall be overloadable with a cust_lang.php in the same folder. Unfortunately, it isn't: cust_lang.php doesn't work this was as any other naming like xy_lang.php seems to work perfectly.
Tags:
Steps To Reproduce: * generate a cust_lang.php in https://github.com/OXID-eSales/oxideshop_ce/tree/master/source/Application/translations/en/ and try to overload the regular lang.php
* generate a xy_lang.php in https://github.com/OXID-eSales/oxideshop_ce/tree/master/source/Application/translations/en and overload the regular lang.php.
Additional Information: Found by @mkoltan during #oxhackathon19 in Fryborough
Attached Files:
Notes
(0012946)
QA   
2019-07-22 11:28   
- es -


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7010 [OXID eShop (all versions)] 1.03. Basket, checkout process major always 2019-07-10 13:24 2019-07-10 14:01
Reporter: bissie Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: acknowledged Product Version: 6.1.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 6.2.0-beta.1  
Theme: Wave
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: B2B edition do not work completely using Wave Theme
Description: Using B2B Edition together with wave theme will disable some functionality, f.e approval handling.
b2b_approval_procedure_overview.tpl has a switch to decide which css classes are used for buttons. When theme is not Flow, than the old azure style classes are used and the js can not find data url and text to display. But Wave uses same classes as flow. To fix it i easily changed method OxidEsales\B2BModule\Services\Core\ViewConfig::isActiveThemeBasedOnFlow() to
``` return (bool) ('flow' == $this->getActiveTheme()) || ('flow' == $this->getParentThemeId() || 'wave' == $this->getActiveTheme()) || ('wave' == $this->getParentThemeId()); ```
Tags: B2B Edition
Steps To Reproduce: Install shop with b2b modules active.
Create Chiefbuyer and a subbuyer , let the subbuyer use approval.
Create an basket as sub and to send to approval, aprove this basket as chief, check the approved as sub and try to put this into basket to finish order.
An overlay is over the whole screen and at lower left side an emty popup is shown, see screenshot
Additional Information:
Attached Files: Bildschirmfoto 2019-07-10 um 13.16.40.png (238,225 bytes) 2019-07-10 13:24
https://bugs.oxid-esales.com/file_download.php?file_id=1746&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7004 [OXID eShop (all versions)] 1.03. Basket, checkout process minor always 2019-07-02 12:46 2019-07-02 12:59
Reporter: QA Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: go back by clicking browser's back button, instead shop step 2 "Address" is not working
Description: if you go back with clicking browser's back button, instead shop step 2 "Address", you get the message "Document expired. This document is no longer available."
Thats because there is called source/index.php? without the parametet cl=user.

-es-
Tags:
Steps To Reproduce: 1. Add article to basket
2. Continue to next step
3. Now you aren in Step 3 "Payment select" (source/index.php?cl=payment)
4. If you click Step 2 "Adress" source/index.php?cl=user is called and everything works fine.
    If you click browser back button source/index.php? is called and you get the error message, because of the missing parameter cl=user.

Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6998 [OXID eShop (all versions)] 2.6. Administer orders minor always 2019-06-19 16:33 2019-06-21 14:36
Reporter: Alpha-Sys Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Ship Now email can only be sent in admin languages
Description: If you have more languages than german and english (maybe french), it is not possible to send an "order send" email in the different language. CMS snippets are translated but the language vars are in german and not in french.
Tags:
Steps To Reproduce: Add a third language in your shop (for example french). Change to french in frontend und take an order. Go to the admin to the order_overview and click on "Ship now". The language vars in the "Ship Now" Email are now in german and not in french.
Additional Information: The problem is the function setTplLanguage. If you are in admin mode there is a check if the language is in the AdminTplLanguageArray.
Attached Files:
Notes
(0012920)
QA   
2019-06-21 14:36   
-MK


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6996 [OXID eShop (all versions)] 1.05. Users feature always 2019-06-19 11:31 2019-06-19 11:44
Reporter: tomaz.puhar Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: New 3-D Secure standard data
Description: As part of the new 3-D Secure standard that is coming into force in Europe, there are a number of new parameters that should be sent to credit card acquirers. More details under -> https://doc.wirecard.com/CreditCard.html#CreditCard_3DS2

Missing data from the user:
    - authentication timestamp (When the user logged in)
    - account update date (When was the account updated)
    - account password change date (When was the password changed)
    - suspicious activity (Settable value in the back end from the shop owner if an conusmer is "suspicious" (true/false) value)
    - street2 (missing from the shipping and billing address)
    - street3 (missing from the shipping and billing address)
    - work phone (Work phone number)

Missing for shipping methods:
    - info delivery timeframe (value in time when is the delivery to be expected)
  
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6985 [OXID eShop (all versions)] 2.4. Administer products minor always 2019-05-23 16:07 2019-06-10 16:24
Reporter: alfredbez Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.1.3  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.2.0-beta.1  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: 7.1
Database Version: 5.7
Summary: unable to remove last item in category sort-popup (SQL error)
Description: You will get a SQL-error if you try to remove the last item on the right side in the AJAX-popup (Category Sorting).
Tags:
Steps To Reproduce: See this short gif: https://i.imgur.com/zOpCEBL.gif

1. open shop backend
2. go to 'Artikel verwalten' > 'Kategorien'
3. Choose a category with some articles
4. Open 4th tab 'Sorterung'
5. Click on 'Artikel sortieren' to open the popup
6. Drag an item to the right side
7. Drag the only item from the right side to the left side
=> The item remains on the right side and you see this error in the log:
<code>[2019-05-23 16:00:33] OXID Logger.ERROR: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' atline 1 ["[object] (OxidEsales\\Eshop\\Core\\Exception\\DatabaseErrorException(code: 1064): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 1 at /var/www/oxideshop/vendor/oxid-esales/oxideshop-ce/source/Core/Database/Adapter/Doctrine/Database.php:938, Doctrine\\DBAL\\Exception\\SyntaxErrorException(code: 0): An exception occurred while executing 'select 1 from oxv_oxarticles_de left join oxobject2category on oxv_oxarticles_de.oxid=oxobject2category.oxobjectid where oxobject2category.oxcatnid = '0f4f08358666c54b4fde3d83d2b7ef04' and oxv_oxarticles_de.oxparentid = '' and oxv_oxarticles_de.oxid not in ( ) ':\n\nSQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 1 at /var/www/oxideshop/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php:90, Doctrine\\DBAL\\Driver\\PDOException(code: 42000): SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 1 at /var/www/oxideshop/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:106, PDOException(code: 42000): SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 1 at /var/www/oxideshop/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:104)\n[stacktrace]\n#0 /var/www/oxideshop/vendor/oxid-esales/oxideshop-ce/source/Core/Database/Adapter/Doctrine/Database.php(304): OxidEsales\\EshopCommunity\\Core\\Database\\Adapter\\Doctrine\\Database->convertException(Object(Doctrine\\DBAL\\Exception\\SyntaxErrorException))\n#1 /var/www/oxideshop/vendor/oxid-esales/oxideshop-ce/source/Application/Controller/Admin/CategoryOrderAjax.php(125): OxidEsales\\EshopCommunity\\Core\\Database\\Adapter\\Doctrine\\Database->getOne('select 1 from o...')\n#2 /var/www/oxideshop/vendor/oxid-esales/oxideshop-ce/source/Application/Controller/Admin/ListComponentAjax.php(144): OxidEsales\\EshopCommunity\\Application\\Controller\\Admin\\CategoryOrderAjax->removeCatOrderArticle()\n#3 /var/www/oxideshop/source/admin/oxajax.php(61): OxidEsales\\EshopCommunity\\Application\\Controller\\Admin\\ListComponentAjax->processRequest('removecatordera...')\n#4 {main}\n"] []</code>
Additional Information:
Attached Files: OXID-Bug-category-sort.gif (458,490 bytes) 2019-05-23 16:07
https://bugs.oxid-esales.com/file_download.php?file_id=1720&type=bug
Notes
(0012898)
alfredbez   
2019-05-23 16:14   
PR: https://github.com/OXID-eSales/oxideshop_ce/pull/707


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6004 [OXID eShop (all versions)] 1.01. Products (product, categories, manufacturer, promotions etc.) major always 2014-12-18 09:58 2019-06-04 16:02
Reporter: wiedeking Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: acknowledged Product Version: 4.8.7 / 5.1.7  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Azure
Browser: All
PHP Version: Not defined
Database Version: Not defined
Summary: Alternative Template is not used with variants
Description: Hi, This is a reopen of 0005403

the alterative Template is only used for the father article but not for the variants!
Tags:
Steps To Reproduce: This is how you can reproduce it:
1.) create a alternative product template.
2.) create a father article and assign alternative template
3.) create variants

If you now go in the show and view the father article, the alternative template will be used.
But if you select an variant, than the original template is used.
This is very confusing for the customer.

It can be seen here: http://www.abendtuete.de/Unsere-Tueten/FAMILIENTUETEN/vegetarische-Familientuete.html
Additional Information:
Attached Files:
Notes
(0010540)
wiedeking   
2014-12-18 10:01   
Please see here: http://www.abendtuete.de/Unsere-Tueten/GESCHENKETUeTEN/Gutschein-Verschenke-das-pure-Kochvergnuegen.html
(0010557)
wiedeking   
2014-12-18 14:44   
I think this is not a duplicate of 0005504 because alternative templates work very well in my shop. it is only, that they do not work with variants!
this is a different bug, i think!

thanx
peter
(0012906)
leofonic   
2019-06-04 16:02   
Possible solution from forums, in Application/views/flow/tpl/widget/product/details.tpl:

[{assign var="oDetailsProduct" value=$oView->getProduct()}]
[{assign var="template" value=$oDetailsProduct->oxarticles__oxtemplate->value}]

[{if $template==''}]
    [{include file="page/details/details.tpl" blWorkaroundInclude=true}]
[{else}]
    [{include file=$template blWorkaroundInclude=true}]
[{/if}]

[{insert name="oxid_tracker" title="PRODUCT_DETAILS"|oxmultilangassign product=$oDetailsProduct cpath=$oView->getCatTreePath() }]
[{oxscript widget=$oView->getClassName()}]


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6990 [OXID eShop (all versions)] 4.02. Session handling tweak always 2019-05-31 11:21 2019-05-31 11:59
Reporter: kilian.koller@eleven2.de Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Flow
Browser: Firefox
PHP Version: 7.1
Database Version: Not defined
Summary: On ever page, I get an error "Warning: ini_set(): A session is active. You cannot change the session module's ini settings at.."
Description: ( ! ) Warning: ini_set(): A session is active. You cannot change the session module's ini settings at this time in /var/www/oxideshop/source/bootstrap.php on line 204
Call Stack
# Time Memory Function Location
1 0.0013 362328 {main}( ) .../index.php:0
2 0.0027 363096 require_once( '/var/www/oxideshop/source/bootstrap.php' ) .../index.php:7
3 0.2124 1404600 ini_set ( ) .../bootstrap.php:204
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012902)
QA   
2019-05-31 11:59   
Hi,

I couldn't reproduce this case. But I guess, a modification of a file is the reason for this message.
On a original bootstrap file of the latest version the line 204 is empty: https://github.com/OXID-eSales/oxideshop_ce/blob/master/source/bootstrap.php#L204
Furthermore, the shop will start the session by calling the Method OxidEsales\EshopCommunity\Core\Oxid::run(); which is called after including the bootstrap file.
So something will start the session before executing the file bootstrap, which causes this error message.

It is also possible, that the PHP ini file was adapted and the session is started on the very beginning of the request: https://github.com/php/php-src/blob/master/php.ini-production#L1345
This should also off.

Else I need further information how to reproduce the case on a default system.

-MK


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6986 [OXID eShop (all versions)] 2.4. Administer products tweak always 2019-05-28 16:22 2019-05-28 16:56
Reporter: dait Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: SEO-URL of Subshops not editable - OXID EE all Versions
Description: SEO-URLs are not editable within subshops when article is inherited by supershop.
Neither input for SEO-URL is possible in subshop (deactivated) nor a change of SEO-URL in supershop is passed to subshop.

By this it is not possible to have an URL different from the standard scheme for an article in a subshop.
Tags:
Steps To Reproduce: Set shop A as supershop and shop B as multishop with inheritance of articles of shop A to shop B.
Add new article in shop A.
Change SEO-URL of article in shop A.
Check SEO-URL of article in shop B.
Additional Information: This should be considered as bug because there are good reasons for the possibility to change the SEO-URL for an article. It is possible in PE, CE and supershop. It also should be possible in a subshop eventually by making SEO-URL editable within the subshop. Right now input is deactivated.
Attached Files:
Notes
(0012899)
simon.runer   
2019-05-28 16:50   
I would say, this is not a "kleinerer Fehler" but a huge problem in a multishop environment. We just discovered the same problem today.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6982 [OXID eShop (all versions)] 4.01. Database handling feature always 2019-05-21 08:33 2019-05-21 09:31
Reporter: mgmtp Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: acknowledged Product Version: 6.1.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: 7.1
Database Version: Not defined
Summary: Primary key for galera cluster
Description: We try for our customer project to scale the database of an OXID enterprise shop (version 6.1.3) via a mariadb galera cluster.

Galera requires a primary key in each table. But we have found some problems with different tables. These table have no primary key set:

* oxadminlog
* oxarticles2shop
* oxattribute2shop
* oxcategories2shop
* oxdelivery2shop
* oxdeliveryset2shop
* oxdiscount2shop
* oxinvitations
* oxlinks2shop
* oxmanufacturers2shop
* oxnews2shop
* oxselectlist2shop
* oxvendor2shop
* oxvoucherseries2shop
* oxwrapping2shop

Is a primary key planned foor these tables and will this be included in future releases?

Are the following steps an option:
* set the unique key of alle 2shop tables also as primary key
* create a auto increment primary key for oxadminlog and oxinvitations

Thanks for your help.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012893)
QA   
2019-05-21 09:31   
(Last edited: 2019-05-21 09:31)
Info from Dev: There is already a feature request for Maria Db and MySQL 8 support.
Active implementation is not yet available.

- es -



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6965 [OXID eShop (all versions)] 1.03. Basket, checkout process major always 2019-03-20 13:32 2019-05-10 11:11
Reporter: Chr1s999 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.0.4  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.2.0-beta.1  
    Target Version:  
Theme: Flow
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Maintenance mode when changing e-mail address as a guest
Description: [20 Mar 08:45:55.318494 2019] [exception] [type OxidEsales\Eshop\Core\Exception\DatabaseErrorException] [code 1062] [file vendor/oxid-esales/oxideshop-ce/source/Core/Database/Adapter/Doctrine/Database.php] [line 938] [message Duplicate entry 'foo@bar.de-1' for key 'OXUSERNAME']
[20 Mar 08:45:55.318494 2019] [exception] [type OxidEsales\Eshop\Core\Exception\DatabaseErrorException] [code 1062] [file vendor/oxid-esales/oxideshop-ce/source/Core/Database/Adapter/Doctrine/Database.php] [line 938] [message Duplicate entry 'foo@bar.de-1' for key 'OXUSERNAME']
[20 Mar 08:45:55.318494 2019] [exception] [stacktrace] #0 vendor/oxid-esales/oxideshop-ce/source/Core/Database/Adapter/Doctrine/Database.php(779): OxidEsales\EshopCommunity\Core\Database\Adapter\Doctrine\Database->convertException(Object(Doctrine\DBAL\Exception\UniqueConstraintViolationException))
[20 Mar 08:45:55.318494 2019] [exception] [stacktrace] #1 vendor/oxid-esales/oxideshop-ce/source/Core/Database/Adapter/Doctrine/Database.php(576): OxidEsales\EshopCommunity\Core\Database\Adapter\Doctrine\Database->executeUpdate('update oxuser s...', Array)
[20 Mar 08:45:55.318494 2019] [exception] [stacktrace] #2 vendor/oxid-esales/oxideshop-ce/source/Core/Model/BaseModel.php(1414): OxidEsales\EshopCommunity\Core\Database\Adapter\Doctrine\Database->execute('update oxuser s...')
[20 Mar 08:45:55.318494 2019] [exception] [stacktrace] #3 vendor/oxid-esales/oxideshop-ce/source/Core/Model/BaseModel.php(1398): OxidEsales\EshopCommunity\Core\Model\BaseModel->executeDatabaseQuery('update oxuser s...')
[20 Mar 08:45:55.318494 2019] [exception] [stacktrace] #4 vendor/oxid-esales/oxideshop-ee/Core/Model/BaseModel.php(550): OxidEsales\EshopCommunity\Core\Model\BaseModel->_update()
[20 Mar 08:45:55.318494 2019] [exception] [stacktrace] #5 vendor/oxid-esales/oxideshop-ce/source/Application/Model/User.php(1620): OxidEsales\EshopEnterprise\Core\Model\BaseModel->_update()
[20 Mar 08:45:55.318494 2019] [exception] [stacktrace] #6 vendor/oxid-esales/oxideshop-ce/source/Core/Model/BaseModel.php(846): OxidEsales\EshopCommunity\Application\Model\User->_update()
[20 Mar 08:45:55.318494 2019] [exception] [stacktrace] #7 vendor/oxid-esales/oxideshop-ce/source/Application/Model/User.php(517): OxidEsales\EshopCommunity\Core\Model\BaseModel->save()
[20 Mar 08:45:55.318494 2019] [exception] [stacktrace] #8 vendor/oxid-esales/oxideshop-ce/source/Application/Model/User.php(1153): OxidEsales\EshopCommunity\Application\Model\User->save()
[20 Mar 08:45:55.318494 2019] [exception] [stacktrace] #9 source/modules/nfc/nfc_groupdiscount/Model/UserExtension.php(60): OxidEsales\EshopCommunity\Application\Model\User->changeUserData('foo@bar.de', '', '', Array, Array)
[20 Mar 08:45:55.318494 2019] [exception] [stacktrace] #10 vendor/oxid-esales/oxideshop-ce/source/Application/Component/UserComponent.php(686): nfc\GroupDiscount\Model\UserExtension->changeUserData('foo@bar.de', '', '', Array, Array)
[20 Mar 08:45:55.318494 2019] [exception] [stacktrace] 0000011 vendor/oxid-esales/oxideshop-ce/source/Application/Component/UserComponent.php(644): OxidEsales\EshopCommunity\Application\Component\UserComponent->changeUserWithoutRedirect()
[20 Mar 08:45:55.318494 2019] [exception] [stacktrace] 0000012 vendor/oxid-esales/oxideshop-ce/source/Application/Component/UserComponent.php(357): OxidEsales\EshopCommunity\Application\Component\UserComponent->_changeUser_noRedirect()
[20 Mar 08:45:55.318494 2019] [exception] [stacktrace] 0000013 vendor/oxid-esales/oxideshop-ce/source/Core/Controller/BaseController.php(523): OxidEsales\EshopCommunity\Application\Component\UserComponent->changeUser()
[20 Mar 08:45:55.318494 2019] [exception] [stacktrace] 0000014 vendor/oxid-esales/oxideshop-ee/Core/Controller/BaseController.php(62): OxidEsales\EshopCommunity\Core\Controller\BaseController->executeFunction('changeuser')
[20 Mar 08:45:55.318494 2019] [exception] [stacktrace] 0000015 vendor/oxid-esales/oxideshop-ce/source/Application/Controller/FrontendController.php(541): OxidEsales\EshopEnterprise\Core\Controller\BaseController->executeFunction('changeuser')
[20 Mar 08:45:55.318494 2019] [exception] [stacktrace] 0000016 vendor/oxid-esales/oxideshop-ce/source/Core/ShopControl.php(382): OxidEsales\EshopCommunity\Application\Controller\FrontendController->init()
[20 Mar 08:45:55.318494 2019] [exception] [stacktrace] 0000017 vendor/oxid-esales/oxideshop-ce/source/Core/ShopControl.php(272): OxidEsales\EshopCommunity\Core\ShopControl->_initializeViewObject('OxidEsales\\Esho...', 'changeuser', NULL, NULL)
[20 Mar 08:45:55.318494 2019] [exception] [stacktrace] 0000018 vendor/oxid-esales/oxideshop-ce/source/Core/ShopControl.php(137): OxidEsales\EshopCommunity\Core\ShopControl->_process('OxidEsales\\Esho...', 'changeuser', NULL, NULL)
[20 Mar 08:45:55.318494 2019] [exception] [stacktrace] 0000019 vendor/oxid-esales/oxideshop-ce/source/Core/Oxid.php(26): OxidEsales\EshopCommunity\Core\ShopControl->start()
[20 Mar 08:45:55.318494 2019] [exception] [stacktrace] 0000020 source/index.php(15): OxidEsales\EshopCommunity\Core\Oxid::run()
[20 Mar 08:45:55.318494 2019] [exception] [stacktrace] 0000021 {main}
Tags:
Steps To Reproduce: 1. Make a guest order with an e-mail address which is not in the database already (e.g. foo@bar.de)
2. Remove cookies (not necessary though)
3. Start another guest order with a different e-mail address (e.g. foo2@bar.de) until you reach the final step before finalizing the order
4. Click the edit button for the invoice address
5. Now you're taken back to step 2
6. Click the edit button (Billing address) on this page
7. Change your email from foo2@bar.de to foo@bar.de and submit the form
8. This results in the exception above
Additional Information:
Attached Files:
Notes
(0012819)
Chr1s999   
2019-03-20 13:35   
This is reproducible in a local OXID EE 6.0.4 version with the flow theme as well as on https://demoshop.oxid-esales.com/professional-edition/
(0012824)
Chr1s999   
2019-03-25 11:23   
Any news on this?
Happens around twice a day, is very annoying for the customers and makes them lose money.
(0012859)
Chr1s999   
2019-04-17 10:54   
@OXID Hello?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6939 [OXID eShop (all versions)] 1.03. Basket, checkout process minor always 2019-01-14 14:12 2019-05-07 11:23
Reporter: QA Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.1.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.1.4  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Payment method Direct debit no complete check of BIC. A blank character is sufficient here to recognize the form data as valid.
Description: If the direct debit payment method (direct debit) is selected, BIC's details are not fully checked.
The entry of a blank character is sufficient here to recognize the form data as valid.

In vendor/oxid-esales/oxideshop-ce/source/Core/InputValidator::_validateDebitNote() spaces are removed in the _cleanDebitInformation() method.
Then the cleaned $aDebitInformation['lsblz'] is passed.
$sBankCode = $aDebitInformation['lsblz'];

Thus, when a space is entered in the BIC, the field is filled as follows:
$sBankCode = """

The following is then checked:
        if (empty($sBankCode) || $oSepaValidator->isValidBIC($sBankCode)) {
            $mxValidationResult = true;
Thus, when a space is entered in the BIC, it is recognized as valid.

Tags:
Steps To Reproduce: 1. Add article to basket
2. Go to step 2 Direct Debit
3. Insert a blank for BIC and korrect IBAN

-> blank character is sufficient here to recognize the form data as valid
Additional Information:
Attached Files: iban.JPG (96,351 bytes) 2019-01-14 14:14
https://bugs.oxid-esales.com/file_download.php?file_id=1672&type=bug
Notes
(0012759)
QA   
2019-01-14 14:13   
However, the template payment_oxiddebitnote.tpl shows that oxide treats both IBAN (BANK_ACCOUNT_NUMBER) and BIC (BANK_CODE) as mandatory (class="req", <input required="required">).
Therefore the behavior at the BIC as input of a space is to be regarded as valid a bug.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6827 [OXID eShop (all versions)] 6. ------ Setup ------- critical always 2018-05-04 12:23 2019-05-07 11:22
Reporter: mikkelfilla Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: resolved Product Version: 6.0.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.1.4  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Upgrade CE/PE to EE leads to empty article list in backend
Description: After upgrade from CE/PE to EE the article list in backend is empty. The reason is an empty oxarticles2shop table.
Tags:
Steps To Reproduce: executing following commands in the directory of a CE/PE:

composer config repositories.oxid-esales composer https://enterprise-edition.packages.oxid-esales.com
composer require oxid-esales/oxideshop-metapackage-ee
vendor/bin/oe-eshop-db_migrate migrations:migrate
vendor/bin/oe-eshop-db_views_generate

Additional Information:
Attached Files:
Notes
(0012474)
michael_keiluweit   
2018-05-04 14:45   
(Last edited: 2018-12-05 12:52)
Database state after the migration.
mysql> select count(oxid) from oxarticles;
+-----------------+
| count(oxid) |
+-----------------+
|             217 |
+-----------------+
1 row in set (0,01 sec)

mysql> select count(oxshopid) from oxarticles2shop;
+-----------------+
| count(oxshopid) |
+-----------------+
|               0 |
+-----------------+
1 row in set (0,00 sec)

mysql>


edit: framed the code into pre tags for a better formatting. -MK



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3609 [OXID eShop (all versions)] 2.4. Administer products minor always 2012-02-20 09:33 2019-05-07 11:20
Reporter: ray Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: resolved Product Version: 4.5.7 revision 41909  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.2.0-beta.1  
    Target Version:  
Theme: Not defined
Browser: All
PHP Version: Not defined
Database Version: Not defined
Summary: no possibility to sort accessoires of articles in backend
Description: Unfortunately there is no possibility to configure the order of accessoires for an article in backend - even if there is a field "oxsort" in "oxaccessoire2article" in the database and a function to sort in oxarticlelist.php line 362.

.$oBaseObject->getSqlActiveSnippet();
        //sorting articles
        $sSelect .= " order by oxaccessoire2article.oxsort";

You can not set the appearance-order in the popup in backend´, only by inserting some values directly in the database-
Tags: Accessoires, Products, Solution Provided, Sorting
Steps To Reproduce:
Additional Information: http://www.oxid-esales.com/forum/showthread.php?p=82135#top
Attached Files: 0001-new-Function-saveAccessoiresPosition-and-usage-in-ar.zip (2,209 bytes) 2017-07-06 15:30
https://bugs.oxid-esales.com/file_download.php?file_id=1532&type=bug
Notes
(0012179)
jh.revier   
2017-07-06 15:26   
see attached patch.

\source\Application\Controller\Admin\ArticleAccessoriesAjax.php:
++ function saveAccessoiresPosition()

source\Application\views\admin\tpl\popups\article_accessories.tpl:
++ gets an option to edit the value for oxsort


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6978 [OXID eShop (all versions)] 4.07. Source code, Test tweak unable to reproduce 2019-05-06 03:06 2019-05-06 11:15
Reporter: BeckerEnterprises Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: acknowledged Product Version: 6.1.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: 7.1
Database Version: Not defined
Summary: system requirements test of ini_set is not the correct way to do it and therefore might be result in a wrong result
Description: Setting the session name with ini_set will return false when the session is already established.
Also it is not the correct way to check if setting ini values is allowed or not, you can get access info on specified ini values with ini_get_all.

Here is an example of \OxidEsales\EshopCommunity\Core\SystemRequirements::checkIniSet which will check if changing session.name is allowed (replaced plain integer values with constants):

public function checkIniSet()
{
    $session_config = ini_get_all('session');

    if($session_config['session.name']['access'] & INI_USER)
        return static::MODULE_STATUS_OK;
    else
        return static::MODULE_STATUS_BLOCKS_SETUP;
}
Tags: SystemRequirements ini_set
Steps To Reproduce: Maybe older PHP Versions might return a positive false result depending on their latest patch date.
Reproducible on Debian 8.11 with Plesk 17.8.11 and PHP 7.1 (7.1.27-debian.8.190311.0956).
Additional Information:
Attached Files:
Notes
(0012882)
QA   
2019-05-06 11:14   
(Last edited: 2019-05-06 11:15)
Hello and thanks for your report. Unfortunately I'm unable to reproduce the issue you mention. Even if the session is established before, setting the session name with ini_set returns true. Since this is the case, I set the priority to low, but acknowledged your report, because your provided solution is truly a good - maybe a better - alternative way to test the ini_set will work properly.

[sp]



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6976 [OXID eShop (all versions)] 4.01. Database handling minor always 2019-05-02 17:24 2019-05-03 13:43
Reporter: leofonic Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Database methods like "getAll" do not work sometimes
Description: In class database there is a wrapper for methods getOne and getAll. There is a check whether the statement is a select query that has an output or an action which has no output. This check, method "doesStatementProduceOutput", looks for the first word in the statement. If the statement is a union statement that begins with a bracket, the first word is recognized as "(SELECT", which is not in the list of known words, therefore the return of "getAll" is an empty array.
Tags:
Steps To Reproduce: Use "getAll" in a module with a select statement with "union" and starting with a bracket.
Additional Information:
Attached Files:
Notes
(0012878)
QA   
2019-05-03 13:43   
$db = \OxidEsales\Eshop\Core\DatabaseProvider::getDb();
$result = $db->getAll('(select oxtitle from oxarticles limit 2) union (select oxtitle from oxcategories limit 2)');
var_dump($result);

Results in:
/var/www/html/source/index.php:13:
array (size=0)
  empty


Expected an array with values like this:
MySQL [oxid]> (select oxtitle from oxarticles limit 2) union (select oxtitle from oxcategories limit 2);
+---------------------+
| oxtitle             |
+---------------------+
|                     |
| Trapez ION MADTRIXX |
| Bindungen           |
| Trapeze             |
+---------------------+
4 rows in set (0.00 sec)

MySQL [oxid]>


-MK


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6925 [OXID eShop (all versions)] 6. ------ Setup ------- minor always 2018-11-29 13:22 2019-04-18 14:54
Reporter: michael_keiluweit Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.1.4  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: EE only. Two user groups have the same RR id.
Description: When installing the demodata, a new user group "shop_admin" is introduced and it gets a new entry in oxgroups. But by doing this an already taken id for the field oxrrid is used.

+----------------------------+--------------------+--------+
| oxid                       | oxtitle            | oxrrid |
+----------------------------+--------------------+--------+
| 36944b76defac5622.13882269 | admin_demo         |     15 |
| oxidnotyetordered          | Noch nicht gekauft |     15 |
+----------------------------+--------------------+--------+


This causes a behavior in an AJAX window for handling shop roles. By fetching one of those two groups and dropping it into the target field, both groups are assigned or unassigned.
Tags: Demo Data, EE
Steps To Reproduce: 1. install an Enterprise Edition with demodata
2. goto admin
3. Administer Users -> Shop Roles
4. Create a new role
5. Click on the tab "Users" -> Assign User Groups
6. move the group "admin_demo" to the right field. You will see that the group "Noch nicht gekauf / Not yet purchased" was also moved.
7. Move one of the two back, the other one will also disappear.
Additional Information: The cause of the behaviour is located in /vendor/oxid-esales/oxideshop-demodata-ee/src/demodata.sql:

INSERT INTO `oxgroups` (`OXID`, `OXACTIVE`, `OXTITLE`, `OXTITLE_1`, `OXTITLE_2`, `OXTITLE_3`, `OXRRID`, `OXTIMESTAMP`) VALUES 
('36944b76defac5622.13882269',1,'admin_demo','admin_demo','','',15,'2016-07-19 14:38:26'),
[...],
('oxidnotyetordered',1,'Noch nicht gekauft','Not Yet Purchased','','',15,'2016-07-19 14:38:14'),


Because of the same OXRRID (15) the Ajax window react to both objects.

Solution: Change on of the OXRRID to 16.
Attached Files:
Notes
(0012709)
michael_keiluweit   
2018-11-29 13:23   
(Last edited: 2018-12-03 14:52)
I made a PR for it, but it was misplaced as this is an issue of the demodata, not the EE code: https://github.com/OXID-eSales/oxideshop_ee/pull/22

(0012862)
anton.fedurtsya   
2019-04-18 14:54   
This one will be fixed in new demodata version, so in any release which will use the new one - v6.0.2 and up.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6793 [OXID eShop (all versions)] 6. ------ Setup ------- minor always 2018-02-20 17:32 2019-04-18 12:11
Reporter: usenff Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: resolved Product Version: 6.0.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.1.4  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Setup folder is copied on every "composer update" although Setup was already executed
Description: If you run "composer update" and answer the question "Do you want to overwrite existing OXID eShop files? (y/N) " with "y" the folder "Setup" will always be copied to "source" even if the Setup was already executed before.
Tags: Solution Provided
Steps To Reproduce: - Setup an oxid-shop via composer
- execute the setup
- confirm that the "Setup"-folder was removed from "source"
- run "composer update"
- answer "Do you want to overwrite existing OXID eShop files? (y/N)" with "y"
Additional Information: There are two mechanisms that should prevent that the "Setup"-folder is copied every time "composer update" is run.

1. don't copy Setup files @ OxidEsales\ComposerPlugin\Installer\Package\ShopPackageInstaller::copySetupFiles if "config.inc.php" is configured
- I can confirm, that this check works as designed

2. never copy Setup files @ OxidEsales\ComposerPlugin\Installer\Package\ShopPackageInstaller::copyShopSourceFromPackageToTarget
- The files should be excluded via filter "self::SETUP_FILES_FILTER"
- The filter currently used is "Setup**/*" which doesn't work because of a missing "/"
- In my opinion the filter should be "Setup/**/*"
Attached Files:
Notes
(0012393)
QA   
2018-02-21 14:18   
The described filter self::SETUP_FILES_FILTER is built with self::SHOP_SOURCE_SETUP_DIRECTORY and AbstractPackageInstaller::BLACKLIST_ALL_FILES. The second one is implemented in the following way:

/** Glob expression to filter all files, might be used to filter whole directory. */
    const BLACKLIST_ALL_FILES = '**/*';

First comment phrase is correct. 'All files' will be filtered, but not the directories. So /Setup is always copied together within /Setup/Controller etc.
As mentioned from usenff, the glob expression '/**/*' would filter everything in /Setup including the directory itself (succesfully tested).
(0012784)
anton.fedurtsya   
2019-02-18 16:17   
Hello, PR-13 fixes the problem. Merged to master.
(0012785)
anton.fedurtsya   
2019-02-18 16:37   
Will be ported to b-2.x as well, so will be available in next 6.1 patch.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6971 [OXID eShop (all versions)] 2.7. Customer info major always 2019-04-10 12:49 2019-04-12 17:36
Reporter: KIRATIKdevs Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Google Chrome
PHP Version: 7.1
Database Version: Not defined
Summary: Cannot use promotions in VisualCms widget action
Description: We found problem with promotions - type Action (type 0 in db) with oxid starts with "ox". The Promotions are visible in every shop (cannot be delete), but we can use them only in shop with ID: 1 - cannot be loaded to widget Action in VisualCMS module.
Tested with only active modules: WYSIWYG Editor + Mediathek and Visual CMS.

Shop ID 1 - root shop
Shop ID 2 - multi shop
Tags: EE, Promotion
Steps To Reproduce: 1. Go to Shop with ID 1
2. Go to Visual CMS
3. Add widget Action
4. Try to load action e.g. "Angebote der Woche" - action will be found

5. Go to shop with ID 2
Repeat steps 2 to 5 - action will not be found
Additional Information:
Attached Files: promotions.png (19,186 bytes) 2019-04-10 12:49
https://bugs.oxid-esales.com/file_download.php?file_id=1700&type=bug
promotions_shp_1.png (15,348 bytes) 2019-04-10 12:49
https://bugs.oxid-esales.com/file_download.php?file_id=1701&type=bug
promotions_shp_2.png (16,454 bytes) 2019-04-10 12:49
https://bugs.oxid-esales.com/file_download.php?file_id=1702&type=bug
vcms_action_shp_1.png (33,623 bytes) 2019-04-10 12:49
https://bugs.oxid-esales.com/file_download.php?file_id=1703&type=bug
vcms_action_shp_2.png (38,373 bytes) 2019-04-10 12:49
https://bugs.oxid-esales.com/file_download.php?file_id=1704&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6970 [OXID eShop (all versions)] 4. ------ eShop Core ------- minor always 2019-04-08 14:50 2019-04-12 09:37
Reporter: m4r73n Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Article->hasAmountPrice() returns the wrong result
Description: Article->hasAmountPrice() returns if there is *any* article in the shop that has an amount price defined.
It should return if *this article* has an amount price defined.

The reason is that there's a WHERE missing in the SQL query: $sQ = "SELECT 1 FROM `oxprice2article` LIMIT 1";
It should be: $sQ = "SELECT 1 FROM `oxprice2article` WHERE `oxartid` = '" . $this->getId() . "'LIMIT 1";
Tags: Article, Solution Provided
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6968 [OXID eShop (all versions)] 2.4. Administer products minor always 2019-04-04 14:20 2019-04-09 11:52
Reporter: Daniel Grimm Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.1.3  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: In der ManufacturerMainAjax.php ist der Aufruf des 'blVariantsSelection' config params falshc
Description: $config->getRequestParameter('blVariantsSelection')

anstatt

$config->getConfigParam('blVariantsSelection')
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012835)
QA   
2019-04-05 15:14   
What makes you say that?
The parameter is read from the config and not from the URL. Therefore it should read as follows:

$config->getConfigParam('blVariantsSelection')
instead of
$config->getRequestParameter('blVariantsSelection')


- es -
(0012836)
Daniel Grimm   
2019-04-08 06:16   
protected function _getQuery()
    {
        $config = \OxidEsales\Eshop\Core\Registry::getConfig();
        // looking for table/view
        $articlesViewName = $this->_getViewName('oxarticles');
        $objectToCategoryViewName = $this->_getViewName('oxobject2category');
        $database = \OxidEsales\Eshop\Core\DatabaseProvider::getDb();
        $manufacturerId = $config->getRequestParameter('oxid');
        $syncedManufacturerId = $config->getRequestParameter('synchoxid');
        // Manufacturer selected or not ?
        if (!$manufacturerId) {
            // performance
            $query = ' from ' . $articlesViewName . ' where ' . $articlesViewName . '.oxshopid="' . $config->getShopId() . '" and 1 ';
            $query .= $config->getRequestParameter('blVariantsSelection') ? '' : " and $articlesViewName.oxparentid = '' and $articlesViewName.oxmanufacturerid != " . $database->quote($syncedManufacturerId);
        } elseif ($syncedManufacturerId && $syncedManufacturerId != $manufacturerId) {
            // selected category ?
            $query = " from $objectToCategoryViewName left join $articlesViewName on ";
            $query .= $config->getRequestParameter('blVariantsSelection') ? " ( $articlesViewName.oxid = $objectToCategoryViewName.oxobjectid or $articlesViewName.oxparentid = $objectToCategoryViewName.oxobjectid )" : " $articlesViewName.oxid = $objectToCategoryViewName.oxobjectid ";
            $query .= 'where ' . $articlesViewName . '.oxshopid="' . $config->getShopId() . '" and ' . $objectToCategoryViewName . '.oxcatnid = ' . $database->quote($manufacturerId) . ' and ' . $articlesViewName . '.oxmanufacturerid != ' . $database->quote($syncedManufacturerId);
            $query .= $config->getRequestParameter('blVariantsSelection') ? '' : " and $articlesViewName.oxparentid = '' ";
        } else {
            $query = " from $articlesViewName where $articlesViewName.oxmanufacturerid = " . $database->quote($manufacturerId);
            $query .= $config->getRequestParameter('blVariantsSelection') ? '' : " and $articlesViewName.oxparentid = '' ";
        }
        return $query;
    }

sorry for the missunderstanding ...

its exactly liku u say, but above is the code from ManufacturerMainAjax.php

and its read from request instead of config :)
(0012838)
michael_keiluweit   
2019-04-09 11:52   
Hi DanielGrimm,

thanks for reporting the issue.
I already created a Pull Request to fix it. The affected lines are listed here: https://github.com/OXID-eSales/oxideshop_ce/pull/698/files

Kind regards
Michael Keiluweit


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6967 [OXID eShop (all versions)] 4.06. Language and translations minor always 2019-03-30 08:32 2019-04-01 16:00
Reporter: ivoba Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: When blSkipViewUsage = true saving of Article description in English doesnt work
Description: When in config.inc.php:
$this->blSkipViewUsage = true;
its not possible to save Article description in 2nd language f.e. English.
Tags: I18N
Steps To Reproduce: - In config.inc.php set:
  $this->blSkipViewUsage = true;
  
  - go to any Article
  - switch language to English
  - enter a description and save Article
  
  English Article description will be shown still in German.
  
  When setting $this->blSkipViewUsage = false; all works.
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6468 [OXID eShop (all versions)] 4.03. 3rd party libraries minor always 2016-08-08 17:36 2019-03-26 15:47
Reporter: vanilla thunder Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 4.9.9 / 5.2.9  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.2.0-beta.1  
    Target Version:  
Theme: All
Browser: Not defined
PHP Version: All
Database Version: Not defined
Summary: PHPMailer 5.2.14 + Microsoft Exchange = corrupt email body
Description: There is a problem with this particular version of PHPMailer.
Mails sent to Exchange Server without base64 encoding will arrive broken.

This affects every client connecting to exchange server:
outlook, android gmail client, android exchange app, iphone, OWA, firebird

PHP Version does not matter here, we have two 4.9 Shops (PE and CE) with different php versions hosted on profihost server, and we can always reproduce this bug in both shops.

Link to PHPMailer bug 0000751
https://github.com/PHPMailer/PHPMailer/issues/751
Tags:
Steps To Reproduce: 1) find someone with an exchange server
2) create an account with email address hosted on this exchange server
3) place order
4) if it "works", you will see random visible html tags in your email and broken layout
Additional Information: the easiest solution would be adding base64 encoding to the constructor:
$this->set('Encoding','base64');

I have created a module for our shops to fix that:
https://github.com/vanilla-thunder/fix-phpmailer

On 30th July I already had a short conversation with Keywan Ghadami about this bug, but back then we thought this bug would affect only outlook clients and not the exchange server itself.
Attached Files: outlook.PNG (45,933 bytes) 2016-08-08 17:36
https://bugs.oxid-esales.com/file_download.php?file_id=1452&type=bug
Screenshot_20160808-171101.png (100,705 bytes) 2016-08-08 17:38
https://bugs.oxid-esales.com/file_download.php?file_id=1453&type=bug
Notes
(0011874)
fcos   
2016-11-23 10:43   
Hi,

had the same problem and found another solution and maybe the actual problem.
The problem is also known in the sendmailer issue tracker:
https://github.com/PHPMailer/PHPMailer/issues/606

It seems to be the "setWordWrap" method.
If if have an alt body the wordwrap isnt executed on the html body and the method "hasLineLongerThanMax" returns true and enables the quoted-printable encoding.

I think the combination is having an alt body and an html body with lines that exceeds the maximum of 1000chars is the problem.

I moved the html body wrapping out of the switch, so that the alt and html body get an wrapping and cant reproduce it anymore, but im not sure if thats the ideal fix or more like an workaround.

I could fix it with the changing the method or simply change the text in the cms, that it dosnt exceed 1000chars per line.
(0012825)
anton.fedurtsya   
2019-03-26 15:46   
Should be fixed with https://github.com/OXID-eSales/oxideshop_ce/pull/697, please double check.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6959 [OXID eShop (all versions)] 1. ----- eShop frontend ----- feature always 2019-02-28 10:55 2019-03-12 09:30
Reporter: Helmut L. Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: User components not accessible in Smarty
Description: In the aUserComponentNames array you must provide the class name with the complete namespace. When the components are then assigned to smarty the class name with the namespace is used as the name of the variable in the template. This leads to a variable name that is inaccessible in smarty because it contains backslashes.
Tags: Components, Namespaces, Smarty
Steps To Reproduce: add a namespaced class to aUserComponentNames
$this->aUserComponentNames['\tc\test'] = 1;

This class would now be available in smarty under the name $\tc\test, which will immediately cause a template error due to the backslashes in the name.
Additional Information:
Attached Files:
Notes
(0012804)
michael_keiluweit   
2019-03-01 08:43   
(Last edited: 2019-03-01 08:50)
edit: deleted my first answer as I missed an information.

(0012805)
QA   
2019-03-01 10:37   
(Last edited: 2019-03-01 10:39)
As of now using class names with namespaces aren't working as key names when registering them for own components. Currently you still have to use the class names without the namespaces. For example the shop does it too:
\OxidEsales\EshopCommunity\Application\Component\Widget\ArticleDetails:
protected $_aComponentNames = ['oxcmp_cur' => 1, 'oxcmp_shop' => 1, 'oxcmp_basket' => 1, 'oxcmp_user' => 1];


Because the namespaces are the prefered way to got, but we still have the backwards compatibility layer, this requirement is a feature for now.

-MK

(0012816)
HR   
2019-03-12 09:30   
There's a workaround for adding own namepaced components.

Example:

<?php
namespace HkReuter\OxSampleModule\Application\Component;

/**
 * Register own component in config.inc.php:
 *
 * class_exists(\HkReuter\OxSampleModule\Application\Component\OxSample::class);
 * $this->aUserComponentNames = ['oxcmp_oxsample' => 1];
 */
class OxSample extends \OxidEsales\Eshop\Application\Controller\FrontendController
{
  ....
}

/**
 * Class alias is needed to make this work in templates.
 */
class_alias(\HkReuter\OxSampleModule\Application\Component\OxSample::class, 'oxcmp_oxsample');


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4401 [OXID eShop (all versions)] 2.4. Administer products feature always 2012-08-16 13:04 2019-03-07 14:40
Reporter: saulius.stasiukaitis Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 4.6.3 revision 47975  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: All
PHP Version: Not defined
Database Version: Not defined
Summary: There is no possibility to add stock message for article when amount gets low (yellow).
Description: There is no possibility to add stock message for article when amount gets low (yellow). That's wrong as there is possibilities to add custom stock messages when there is enough article stock(green) or no stock at all(red).
Also there is no possibility to chose to use or not to, default stock messages.
Tags: Products, Stock
Steps To Reproduce: 1. Open admin -> Administer products -> Products -> Article -> stock
There is inputs "In Stock Message" and "Out Of Stock Message" should also be "Low Stock Message".
2. Open admin-> Core settings -> Settings : Stock
There is checkbox "Use default "in-stock" Message" and checkbox "Use default "out-of-stock" Message" also should be checkbox "Use default low-stock Message".
Additional Information:
Attached Files:
Notes
(0012756)
jdl   
2019-01-11 12:08   
Hey i created a module for oxid version 6.0 or higer that should cover that. Currently only works in german but i am working on supporting more languages.
You can take a look at it here: https://packagist.org/packages/jdl/stock-low-module
(0012758)
jdl   
2019-01-12 11:31   
Allright there we go, now supports english aswell.
(0012809)
marco_steinhaeuser   
2019-03-07 14:40   
Thank you very much for the fix via module, @jdl. In the mean time it became more efficient to fix such bugs via pull requests on GitHub. Do you know how to do that? Otherwise I could lend you a helping hand with it. Pls. get in touch with me via forum PM ;)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6957 [OXID eShop (all versions)] 2.6. Administer orders minor always 2019-02-25 08:53 2019-02-28 15:35
Reporter: KIRATIKdevs Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.2  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Flow
Browser: Google Chrome
PHP Version: 7.1
Database Version: Not defined
Summary: Problem with shipping method presentation in order view in admin panel
Description: Soo... problem is with view in admin panel:
Administer Orders > Orders > {CHOOSE ORDER} > Main > Shipping Information

See our attachments.

We made order on OXID fron page like simple customer. We had choosen german language in front page of shop.
Order was made without any problems.
When admin want to send mail about shiping information from admin panel, then something is wrong there.
On start OXID admin panel shows "Standard - DE", when we send mail, then after refresh iframe oxid will change language to "Standard - EN" in dropdown field ("Shipping with:").

Probably it is not what you wanted to do and now we have a question... Which language should be loaded in case from our screen shoot? orderlanguage? editlanguage? baselanguage?
Tags: Admin, Languages, Pull Request, Solution Provided
Steps To Reproduce: 1. Prepare lang prefix in shipping method for each country, like ENG, DE to see results
2. Make a order
3. Go to admin panel: "Administer Orders > Orders > {CHOOSE ORDER} > Main > Shipping Information"
4. Check language in DROPDOWN field
5. ... now send mail with "Shipping info"
6. Check language in DROPDOWN field again
Additional Information:
Attached Files: OXID-bug-deliveryset.png (99,438 bytes) 2019-02-25 08:53
https://bugs.oxid-esales.com/file_download.php?file_id=1686&type=bug
OXID-bug-deliveryset-de.png (32,062 bytes) 2019-02-25 08:53
https://bugs.oxid-esales.com/file_download.php?file_id=1687&type=bug
OXID-bug-deliveryset-en.png (32,717 bytes) 2019-02-25 08:53
https://bugs.oxid-esales.com/file_download.php?file_id=1688&type=bug
error-sql.png (72,381 bytes) 2019-02-26 12:30
https://bugs.oxid-esales.com/file_download.php?file_id=1690&type=bug
Notes
(0012793)
KIRATIKdevs   
2019-02-25 08:58   
This is first part of problem... because we think that this is small part of bigger problem but please first watch on this.
(0012798)
QA   
2019-02-25 14:59   
I think here is a misconception of two mechanics.

1. active language in administration area.
2. active language while making the order of the customer.

While browsing the administration area the admin can choose the language to display the texts with. If you select the English language, but the shop was installed with the German language then all objects are displayed in English which were translated; the rest will stay German. The rest will shown with German translations.

-> When you saved the delivery set "Standard" in German to "Standard DE" (oxid: oxidstandard) and in English "Standard EN" (oxid stays: oxidstandard) then it's just a display behaviour you have triggered.

The mail is sent with the selected language of the customer. When the language English was active while making the order, the shop will send the mail also in English. Independent of the active language in the administration area.

When you have a look into the table oxdeliveryset for the delivery "oxidstandard" you will a record like:

oxid: oxidstandard
oxtitle: Standard DE
oxtitle_1: Standard EN

The order object has the information of the used language while doing the order:

\OxidEsales\EshopCommunity\Core\Email::sendSendedNowMail

$orderLang = (int) (isset($order->oxorder__oxlang->value) ? $order->oxorder__oxlang->value : 0);

it then calls the method: \OxidEsales\EshopCommunity\Core\Email::_getShop($orderLang)
which sets the language for the mail:

protected function _getShop($langId = null, $shopId = null)
$shop->setLanguage($langId);


All in all: The selected item of the dropdown box is chosen by the active language of the administration but it does not have an effect of the language used for the e-mail text.
(0012800)
KIRATIKdevs   
2019-02-26 12:29   
(Last edited: 2019-02-26 12:37)
Thanks for you reply! Really!

I have last question :)

Could you watch on video?
https://drive.google.com/file/d/1__m8aNF-ZfA0RGjcGJYytVvSVAsNas2i/view?usp=sharing

1. You want to say that this "automatic language switching proccess" in dropdown field after send mail with shipping info is correct? Yes/No

2. When i talked about deeper problem i meant view error.
I know that code under maybe have wrong architecture problem (model into model) but i made it only for an experimental approach:

{CODE-START}
class Order extends Order_parent {

    public function replaceOriginalTrackingUrl($oDelSet) {

        if ($oDelSet->oxdeliveryset__kiratrackingurl->value === '') {
            throw new WrongCarrierTrackingUrlException('Carrier tracking url is an empty string');
        }

        if (strpos($oDelSet->oxdeliveryset__kiratrackingurl->value, "###ID###") === false) {
            throw new WrongCarrierTrackingUrlException('Missing ###ID### element in your carrier tracking url');
        }

        $sReplace = str_replace("###ID###", $this->getTrackCode(), $oDelSet->oxdeliveryset__kiratrackingurl->value);

        return $sReplace;
    }

    public function getShipmentTrackingUrl()
    {
        $this->_sShipTrackUrl = parent::getShipmentTrackingUrl();

        try {
            $this->_sShipTrackUrl = $this->replaceOriginalTrackingUrl($this->getDelSet());
        } catch(WrongCarrierTrackingUrlException $oException) {
            $oLogger = Registry::getLogger();
            $oLogger->alert($oException->getMessage(), [$oException]);
        }

        return $this->_sShipTrackUrl;
    }

}
{CODE-END}

When i tried to access to "$this->getDelSet()" or even create new instance of DeliverySet and load it by "oxdeliveryset.oxid" in "Order" model - OXID throws me an error like on the screen.

If you will analyze it, you can see that OXID made a mistake. It took "oxv_oxdeliveryset_1_en" and "oxv_oxdeliveryset_1_de" in one sql query.
When i will switch admin language to Deutsch, everything is ok.

(0012802)
michael_keiluweit   
2019-02-28 15:26   
(Last edited: 2019-02-28 15:34)
Hi there,

1. There is no really process behind that. It is just a loop and compares the given order shipment id and all shipment ids:

[{foreach from=$oShipSet key=sShipSetId item=oShipSet}]
    <option value="[{$sShipSetId}]" [{if $edit->oxorder__oxdeltype->value == $sShipSetId}]SELECTED[{/if}]>[{$oShipSet->oxdeliveryset__oxtitle->value}]</option>
[{/foreach}]


2. After some debugging I found the cause for the language abbreviation mix in the query generating:

\OxidEsales\EshopCommunity\Core\Email::sendSendedNowMail

search:
$oldTplLang = $lang->getTplLanguage();
$oldBaseLang = $lang->getTplLanguage();

replace with:https://github.com/OXID-eSales/oxideshop_ce/pull/692
$oldTplLang = $lang->getTplLanguage();
$oldBaseLang = $lang->getBaseLanguage();


The reason is quite simple:
Assumed the base language of the shop is German (Id 0) and the used language for the administration area is English (Id 1), then we will get a mix of ids when the TplLanguage is used for the BaseLanguage afterwards.

Before executing the method (in the administration area context):
TplLanguage = 1
BaseLanguage = 0.

After building the mail:
TplLanguage = 1
BaseLanguage = 1


Summary:
If you have the constellation that the order is made with the German language and you mark the order as shipped while the English language is active in the administration area but you do not send the mail, then nothing bad happens. If you check the selectbox to send the mail also, then the SQL error appears in the log.

edit: https://github.com/OXID-eSales/oxideshop_ce/pull/692



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6951 [OXID eShop (all versions)] 1.03. Basket, checkout process minor always 2019-02-12 09:52 2019-02-12 14:48
Reporter: Esy0n Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Google Chrome
PHP Version: 5.6
Database Version: Not defined
Summary: Checkout error message no longer disappears
Description: If you try to order an item that is in the shopping cart but has been deactivated in the meantime, an error message will appear. This error message appears on different pages and does not disappear.
Tags:
Steps To Reproduce: 1. Add active item to the shopping cart
2. Deactivate the article in the backend
3. Complete checkout
Additional Information: EE 5.3.0
Attached Files: OXID_v6_1_2.JPG (183,786 bytes) 2019-02-12 14:03
https://bugs.oxid-esales.com/file_download.php?file_id=1683&type=bug
OXID_v6_1_2_a.JPG (152,695 bytes) 2019-02-12 14:48
https://bugs.oxid-esales.com/file_download.php?file_id=1684&type=bug
OXID_v6_1_2_b.JPG (106,411 bytes) 2019-02-12 14:48
https://bugs.oxid-esales.com/file_download.php?file_id=1685&type=bug
Notes
(0012782)
QA   
2019-02-12 14:03   
In an OXID eShop V6.2.1 post-implemented:
1. add active item to the shopping cart
2. deactivate the article in the backend
3rd Complete checkout

After completion of the order the following message is displayed in the frontend: "The article "XXXX" is unfortunately no longer available".
(see screenshot)
(0012783)
QA   
2019-02-12 14:45   
(Last edited: 2019-02-12 14:47)
The behavior that the message "The article "XXX" is unfortunately no longer available" after going through the checkout no longer disappears is in the shop version 5.x and version 6.x existent (see screenshots) on all pages.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6905 [OXID eShop (all versions)] 4.01. Database handling minor always 2018-09-21 13:47 2019-02-11 14:37
Reporter: michael_keiluweit Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: The view table oxarticle does contain the price of the parent shop, not the price of oxfield2shop.
Description: If a sub shop has a different price for an inherited article, then the price will be stored in oxfield2shop. So if you call the object you will get the individual price.
But if you use the view mechanic by itself, then you will get the price of the parent shop as the view tables contains the price of the parent shop.
Since our training course part 3 states that it is safe to use the view functionality for getting sub shop specific information the framework should store the own price in the view table of the sub shop, not the original one.


Tags: Validation
Steps To Reproduce: 1. Goto admin
2. Create a new shop
3. Let the new shop inherit everything from a parent shop
4. change to the new shop
5. activate it
6. change one price of an article
7. call the details page of the article, see the new price.
8. have a look into the database. The view table oxv_oxarticle_2 will have the value of the original price.
Additional Information: From our training course:

- Bei Datenbankabfragen innerhalb von eigenen Erweiterungen mu?ssen wir uns nicht explizit um die Shop-Zugeho?rigkeit der Datensa?tze ku?mmern.
- Es ist lediglich darauf zu achten, dass die korrekte View angesprochen wird.
- Zu diesem Zweck gibt es eine Funktion, die in oxfunctions de niert wird: getViewName([Tabellenname])
—> Liefert den Namen der entsprechenden View zuru?ck


Translation:
- It's not necessary to make sure to which shop the data belongs.
- You only have to check that you call the correct view.
- So use the function getViewName($tableName)
-> it returns the name of the view table

Attached Files:
Notes
(0012628)
michael_keiluweit   
2018-09-21 14:15   
(Last edited: 2018-09-21 14:19)
Test script. Adapt the path to the bootstrap file. Also be sure that there is an article with the used oxid. I used the demodata to reproduce it.
<?php

require_once '../bootstrap.php';


// view price
$sql = 'select oxprice from ' . getViewName('oxarticles') . ' where oxartnum = 1402';
$db = \OxidEsales\EshopCommunity\Core\DatabaseProvider::getDb();
$viewPrice = $db->getOne($sql);


// object price
$oxid = '05848170643ab0deb9914566391c0c63';
$article = oxNew(\OxidEsales\Eshop\Application\Model\Article::class);
$article->load($oxid);
$objectPrice = $article->getPrice()->getBruttoPrice();


// debug output
echo 'Shop id: ' . \OxidEsales\Eshop\Core\Registry::getConfig()->getShopId();
echo '';
echo 'Price from view table: ' . $viewPrice;
echo '';
echo 'Price from article object: ' . $objectPrice;



Call the script with the parameter "shp=1" and "shp=2" to see the different.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4539 [OXID eShop (all versions)] 1.01. Products (product, categories, manufacturer, promotions etc.) minor always 2012-09-21 09:44 2019-02-04 14:22
Reporter: leofonic Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 4.6.0 revision 44406  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: All
PHP Version: Not defined
Database Version: Not defined
Summary: Sorting of Variant Selections depends on stock status
Description: If a Variant is not available, sorting of variant selection is sometimes wrong.
Tags: Products, Stock, Variants
Steps To Reproduce: - In demoshop, go to jeans "Anna" in frontend and backend.
- change stock status to "if out of stock offline" on all available variants
- set stock to zero for the variant "W 30/L 30 | Blue"
- In Frontend, "blue" is now the last entry in dropdown, should be the first
Additional Information:
Attached Files:
Notes
(0009687)
leofonic   
2014-03-28 09:09   
As this was recently updated, some more info: The problem is not really in stock status, the problem is that it is impossible to properly sort two or more dimensions with one number. If all possible variants exist, it's ok, but for example if one size does not exist in one color, sorting will be wrong. Sorting could be stored multidimensional like variantnames maybe:
variant "W 30/L 30 | Blue"
sorting "3|5"


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6948 [OXID eShop (all versions)] 4.09. SEO, SEO URL minor always 2019-02-01 17:41 2019-02-01 18:01
Reporter: leofonic Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: SEO Url is not removed when article category changes
Description: When a category is unassigned from an article, the SEO Url of the article in this category is marked expired. In fact it is not expired but invalid, it shoud be redirected to the main url of the article.
Tags:
Steps To Reproduce: 1. View an article in frontend
2. Unassign its current category and assign a different category to the article
3. Hit F5 to reload article in frontend
-> SEO url still works despite the article is not in this category anymore
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6946 [OXID eShop (all versions)] 1.01. Products (product, categories, manufacturer, promotions etc.) major always 2019-01-31 12:26 2019-01-31 17:19
Reporter: KIRATIKdevs Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: 7.1
Database Version: Not defined
Summary: Redirect to white page after press logout button
Description: Redirect to white page after press logout button. I don't know is it important but I have also installed OXID b2b modules.
Tags:
Steps To Reproduce: 1. Set config.in.php:
$this->sShopURL = "https://...";
$this->sSSLShopURL = "https://...";
$this->sAdminSSLURL= "https://...";
$this->blForceSessionStart = false;

2. Create user "John Doe" and assign him to user groups "Handler" (customer)
3. Create example product "Test product" and set rights like on image: "white-page-logout-1.png"
4. Log-in through main page as customer and open "Test product" view
5. Log-out like in image - "white-page-logout-2.png"
Additional Information: When i set config.inc to this:
$this->sShopURL = "https://...";
$this->sSSLShopURL = null;
$this->sAdminSSLURL= null;
$this->blForceSessionStart = false;
Problem dissapear.
Attached Files: white-page-logout-1.png (95,474 bytes) 2019-01-31 12:26
https://bugs.oxid-esales.com/file_download.php?file_id=1677&type=bug
white-page-logout-2.png (26,796 bytes) 2019-01-31 12:26
https://bugs.oxid-esales.com/file_download.php?file_id=1678&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6362 [OXID eShop (all versions)] 1.01. Products (product, categories, manufacturer, promotions etc.) minor always 2016-04-05 11:09 2019-01-25 17:56
Reporter: eike_spriess Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: acknowledged Product Version: 4.9.7 / 5.2.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: If article is set to inactive and seo will be called you get 302 FOUND and redirect=1
Description: if article in backend is set to inactive and seo url is called (e.g indexed by Google) you get a redirect=1 with Status 200 Ok.


Tags: SEO
Steps To Reproduce: Go to demoshop
1. http://demoshop.oxid-esales.com/EnEd/
2. In frontend you see in "Frisch eingetroffen" the article
   "Trapez ION SOL KITE 2011"
3. Set this article in backend to inactive and open the article details
http://demoshop.oxid-esales.com/EnEd/Kiteboarding/Trapeze/Trapez-ION-SOL-KITE-2011.html
4. You get a status 302 Found with redirected=1 Status 200 Ok.
Additional Information: Indexed seo url's will be complained by Google.
Attached Files:
Notes
(0011511)
florian.auer   
2016-04-05 11:24   
What is the expected result?
(0011512)
eike_spriess   
2016-04-05 11:51   
maybe Status 404 Not Found, but never redirected=1 with status 200 Ok.
(0011513)
florian.auer   
2016-04-05 13:11   
The initial status is 302 (moved temporarily), which forwards to the home page. So the status 200 results from the redirect.

I've had different input regarding this and the expected result from others:

1) Do not show inactive products in overview, but keep the product's detail page reachable via deep link (and probably show a message/hint that it is inactive).

2) Use status code 303. According to RFC 7231, which obsoletes RFC 2616, "A 303 response to a GET request indicates that the origin server does not have a representation of the target resource that can be transferred by the server over HTTP. However, the Location field value refers to a resource that is descriptive of the target resource, such that making a retrieval request on that other resource might result in a representation that is useful to recipients without implying that it represents the original target resource." (See https://en.wikipedia.org/wiki/HTTP_303)

3) Use 404 (Not found). This however would result in the detail page being removed from the search engine's index, and it might take more effort to bring it back there again.

So I assume that the definition of the expected result depends on the SEO consultant you ask.


From my point of view it should be up to the shop owner do decide whether to allow deep links for inactive products, or to use status 303, or to use status 404.

Thus, the solution is a new feature.
(0011514)
florian.auer   
2016-04-05 13:24   
See also https://moz.com/learn/seo/http-status-codes
(0011515)
florian.auer   
2016-04-05 13:27   
Marking as feature request, as status code 302 is sent in this context. which is correct. See https://en.wikipedia.org/wiki/HTTP_302
(0011523)
matths   
2016-04-07 14:21   
Hi Florian, how are you? ;)

Well, technically 302 Temporary moved might be a correct status code, but from a Google perspective as well as from a user perspective, it's not.

Google webmaster tools calls 302 redirects to the homepage a "Soft 404" and penalizes the website for these things. Google suggests to use a 404 Not found or 410 Gone. https://support.google.com/webmasters/answer/2409443?ctx=MCE&ctx=S4

From a user perspective it doesn't make a difference whether he want's to reach a non existing page or a formerly existing page of a now inactive article. It's something, that is not found. From a user perspective going to the homepage without any message why he ends up there, doesn't make sense.
A much more user-friendly solution (with a much higher conversion, maybe) would be to redirect to some relevant content (e.g. the products category page) and a flash message which inform about the no longer visible article.

Best regards,
Matthias
(0012122)
marco_steinhaeuser   
2017-06-15 23:51   
(Last edited: 2017-06-15 23:53)
@matts is definitely right: in a matter of fact, the option "If out of stock, offline: The product is not displayed if it is sold out." means that this product will not hit the market any more, you will never ever sell it again. Google, please don't come along again for this URI and remove it from your index. This should be documented, at least in the help_lang files.

In this case, a custom 404 or even better, a custom 410 page shall come up providing several options like <go to the home page>, <search for another product> or <show up similar products>.

Displaying a HTTP header 302 (temporarily redirected), redirecting to the home page is completely wrong and will end up as a so called "soft 404" for SEOs <-- bad! And this is not only bad for one out of five SEO experts, but also for those who are into _real_ projects.

FYI:
* 302 would mean that the _content_ on your web page temporarily moved to another URI. This is not the case when redirecting from a product detail page to the home page of a shop. Also, it seems that there's no code (yet) to generate a 302 HTTP header and redirect to the home page of a shop. Certainly, it looks like it _automatically_ happens, at least on Apache web servers.
* Even if you changed it to 301 (moved permanently), it would be incorrect as the content of the (former) product details page would always be different to the content of the home page, isn't it? ^^

Please talk to me before changing anything.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6941 [OXID eShop (all versions)] 1.05. Users minor always 2019-01-18 17:03 2019-01-23 16:09
Reporter: bYemma Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: acknowledged Product Version: 6.1.1  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: First entry in account breadcrumb not propperly linked
Description: When you are on a account page other than dashboard, the breadcrumb link to "My Account" ist just a hash key. This should be filled with a propper link.
Tags: Account, breadcrumb, CE, Link, PE, Shop, User
Steps To Reproduce: Go to a account page other than dashboard, for example cl=account_order.
Additional Information:
Attached Files: breadcrumb-link-anchor.jpg (245,283 bytes) 2019-01-21 08:35
https://bugs.oxid-esales.com/file_download.php?file_id=1673&type=bug
Notes
(0012769)
QA   
2019-01-18 18:22   
Not reproducible in 6.1.1. The breadcrumb link to "My Account" is a proper link.

DE:
https://domain/mein-konto/

EN:
https://domain/en/my-account/

It seems that your oxseo table is incomplete.

-MF
(0012770)
bYemma   
2019-01-18 19:07   
Sorry for reopening. I verified this also in the demo shop!

Did you look at this link from a account page which is NOT the dashboard?

If I am for example on the page index.php?cl=account_wishlist, the breadcrumb link for My Account is "#".
(0012772)
QA   
2019-01-22 11:02   
Reproducible in CE and PE but not in EE.

-MF
(0012773)
QA   
2019-01-23 16:09   
The reason is, that the OXOBJECTID field of the oxseo table have wrong checksums. Because of that, the shop can‘t find the SEO URLs which results in a wrong filled data array for the breadcrumbs.

As a workaround you can overwrite the oxseo data with those from the inital data:
source/Setup/Sql/initial_data.sql

To overwrite the data, use the INSERT INTO `oxseo` sql statement and remove the comma from the last line at the end of the line and add the following line:
ON DUPLICATE KEY UPDATE `OXOBJECTID` = VALUES(`OXOBJECTID`), `OXIDENT` = VALUES(`OXIDENT`), `OXSHOPID` = VALUES(`OXSHOPID`), `OXLANG` = VALUES(`OXLANG`), `OXSTDURL` = VALUES(`OXSTDURL`), `OXSEOURL` = VALUES(`OXSEOURL`), `OXTYPE` = VALUES(`OXTYPE`), `OXFIXED` = VALUES(`OXFIXED`), `OXEXPIRED` = VALUES(`OXEXPIRED`), `OXPARAMS` = VALUES(`OXPARAMS`), `OXTIMESTAMP` = VALUES(`OXTIMESTAMP`);

-MF


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6582 [OXID eShop (all versions)] 1.03. Basket, checkout process minor always 2017-02-03 18:13 2019-01-17 18:47
Reporter: avalue Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 4.10.3 / 5.3.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Flow
Browser: Google Chrome
PHP Version: Not defined
Database Version: Not defined
Summary: item discounts no longer working
Description: Free product no longer appears in basket if a discount type "itm" is configured in the backend.
Tags:
Steps To Reproduce: 1. Logon into OXID Demoshop Prof. Edition
2. Configure a discount type "itm" which is always active without any limitations
3. Add a product to basket
4. Surprise: There is no additional product (discount item) in your basket.

For more details see the screencast below:
https://we.tl/5xdnon3x2R
Screencast is available until 10th February

Additional Information:
Attached Files:
Notes
(0012142)
avalue   
2017-06-26 16:51   
Any progress on this?
(0012766)
alfredbez   
2019-01-17 18:04   
(Last edited: 2019-01-17 18:47)
I was able to reproduce the problem. It works after I assigned the discount to an article/category (Artikel > "Kategorien zuordnen" / "Artikel zuordnen").

However, I think, that this is wrong and it should work without assigning any articles or categories:

> Ohne Zuordnung von Categories und/oder Artikel gilt der Rabatt global für den gesamten Warenkatalog.

Source: https://docs.oxid-esales.com/eshop/de/5.3/betrieb/rabatte/registerkarte-artikel.html

----

Look also at this: OxidEsales\Eshop\Application\Model\Discount@isForBundleItem (https://github.com/OXID-eSales/oxideshop_ce/blob/a8f47b3db4e812944a82ad4440a8821f28a65989/source/Application/Model/Discount.php#L323-L331)



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5267 [OXID eShop (all versions)] 2.4. Administer products major always 2013-07-01 12:28 2019-01-14 15:26
Reporter: torsten.dix Platform:  
Assigned To: OS:  
Priority: urgent OS Version:  
Status: resolved Product Version: 4.7.6 / 5.0.6  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 4.7.7 / 5.0.7  
    Target Version:  
Theme: Both
Browser: All
PHP Version: any
Database Version: any
Summary: Bug in Article SEO-Tab
Description: The SEO-URL for Articles can not be edited for any Category, which is not the main category of this article
Tags: SEO
Steps To Reproduce: Choose an article, which is assigned to more than one category.
Go to the SEO-tab of this article.
Change the active category of this article.
The SEO-url of the article won't change!
Also, you can't edit the SEO-url of the article in this category.
Additional Information: The bug is located in method _getCategory of oxSeoEncoderArticle.
In earlier versions, the category was identified by using getActCategory(). This was changed to getActiveCategory() which is not available in the controller Article_Seo.
So I locally fixed the problem by adding three lines to this method, which additionally checks, if the controller is Article_Seo, and than identifies the category by using getActCatId():

Here is the code of the modified method, where the elseif-part is new:

    protected function _getCategory( $oArticle, $iLang )
    {
        $oCat = null;
        $oView = $this->getConfig()->getActiveView();
        if ( $oView instanceof oxUBase ) {
            $oCat = $oView->getActiveCategory();
        } elseif ( $oView instanceof Article_Seo ) {
            $oCat = oxnew('oxcategory');
            $oCat->load($oView->getActCatId());
        }
        return $oCat;
    }
Attached Files:
Notes
(0008861)
mark   
2013-07-01 12:32   
+1
(0008875)
Linas Kukulskis   
2013-07-04 10:28   
added additinal check for admin


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6878 [OXID eShop (all versions)] 4.01. Database handling feature always 2018-08-08 12:18 2019-01-10 16:42
Reporter: thorsten.schneider Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.0.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: All
Browser: Not defined
PHP Version: All
Database Version: All
Summary: \OxidEsales\Eshop\Core\Database\Adapter\Doctrine\Database cannot be overriden
Description: I wanted to add a connection option in addDriverOptions() in \OxidEsales\Eshop\Core\Database\Adapter\Doctrine\Database.
It seems that this (and overwriting other Methods in this class) is not possible as the object is generated in \OxidEsales\EshopCommunity\Core\DatabaseProvider::createDatabase() (Line 196) with "new" instead of "oxNew".
Tags: Database
Steps To Reproduce: Create a module that extends the class:

        \OxidEsales\Eshop\Core\Database\Adapter\Doctrine\Database::class => Vendor\Module\Core\Database\Adapter\Doctrine\Database::class,

Overwrite a function, e.g.:

    protected function addDriverOptions(array &$existingParameters)
    {
        die("Actually we do something");
    }

This will never be called, although the database connection is set up correctly. Means our addition is not added to the chain (although you can see the addition in backend's loaded modules)
Additional Information: In some cases it is essential to extend functions here. In my case i need to set a special Option for the database connection:
PDO::MYSQL_ATTR_LOCAL_INFILE => true

This is not possible in this implementation. I would guess that it is not very often the case, but if it is you are stuck with a database connection that is not configurable with special PDO Options.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5714 [OXID eShop (all versions)] 4.07. Source code, Test tweak always 2014-03-28 16:33 2018-12-23 10:42
Reporter: flowcontrol Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 4.8.4 / 5.1.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: All
Browser: All
PHP Version: Not defined
Database Version: Not defined
Summary: cust_config.inc.php gets included after database connection was made
Description: cust_config.inc.php gets only included after database connection was established successfully, therefore it is not possible to configure the database connection in cust_config.inc.php
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012747)
tabsl   
2018-12-23 10:42   
any updates here?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6906 [OXID eShop (all versions)] 2.3. Extensions (modules, themes) feature always 2018-09-25 11:01 2018-12-13 12:21
Reporter: kaluzki Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: publish oxid-esales/paypalplus-module to https://packagist.org
Description: currently we provide this module as private composer package,
but is there any reason not to make it public?
Tags: Composer, Paypal Plus
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012708)
naehwelt   
2018-11-29 11:24   
Actually it is not possible to make a PR on github.
I've moved this module to a public scope,
based on the last release: https://exchange.oxid-esales.com/de/Bestellprozess-und-Versand/Bezahlung/PayPal-PLUS-3-0-3-Stable-CE-4-10-x-6-0-x.html

https://github.com/oxidio/module-paypalplus
https://packagist.org/packages/oxidio/module-paypalplus


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6851 [OXID eShop (all versions)] 2.5. Administer users critical always 2018-07-02 13:03 2018-12-04 15:25
Reporter: QA Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.0.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.0.4  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: shop roles readonly has no effect at some admin sections
Description: In shop-admin you can define an admin role for a user which grants him only reading rights for specific admin sections. For any reasons in some sections e.g.

- Master Settings -> Core Settings (but not the other sub-settings like Countries etc.)
- Extensions
- Users
- ... (did not test all sections)

it's possible to change the values. There are also other sections e.g.

- Master Settings -> Distributors
- Shop Settings -> Gift Wrapping

that allow to change the values for existing objects, but they won't be saved after clicking the save-button.

Last but not least it looks like it's always possible to create new objects, e.g. new user, new wrapping, new product even if you have only read rights. I'm not sure if this is intended to be the case.

In short: admin roles readonly rights doesn't appear to work properly across the whole shop admin.

[sp]
Tags: Admin, Rights & Roles
Steps To Reproduce: - Create a new user
- Make the user a subshop admin
- Create an admin role
- Configurate the admin role with readonly rights for Master Settings
- Login with subshop admin user
- Access Master Settings -> Core Settings and change e.g. the Company Name.
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5734 [OXID eShop (all versions)] 2.6. Administer orders major always 2014-04-10 13:13 2018-12-03 11:11
Reporter: euroxid Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: acknowledged Product Version: 4.7.7 / 5.0.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Azure
Browser: All
PHP Version: Not defined
Database Version: Not defined
Summary: Cancelling one orderitem updates prices of all other
Description: When calcelling (pause-button) one item of an order, the prices of all other items get updated to reflect price changes occured after the order.
Tags: Calculations, Price Calculation, Products
Steps To Reproduce: 1) Issue a multi-item order, e.g. Item A for 10€ and B for 20€
2) Change price of article A to 15€.
3) Log in to backend, select the order, go to articles-tab and cancel B.

Now the remaining sum shall be 10€, but is 15€.
Additional Information:
Attached Files:
Notes
(0009826)
euroxid   
2014-04-10 13:16   
Possibly related to 0004624. (No duplicate - the problem is not a *wrong* recalculation, but the fact that the items get recalculated at all)
(0012713)
tabsl   
2018-12-03 11:11   
what about thist icket?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6583 [OXID eShop (all versions)] 2.6. Administer orders major always 2017-02-03 18:47 2018-12-03 11:10
Reporter: kex Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 4.10.3 / 5.3.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Azure, Flow
Browser: Firefox, Internet Explorer, Google Chrome
PHP Version: Not defined
Database Version: Not defined
Summary: (re-)calculation error for orders containing articles with price surcharge/discounts via selection lists
Description: If an order contains articles with price surcharge/discount via selection lists the invoice/prices generated during checkout is correct (performance setting "Support Price Modifications by Selection Lists" turned on). However as soon as you edit the order (modifing article count, marking as "payed", ...) the order gets recalculated without the price surcharge/discount. This seems to be a major bug, since any modification, canceling or even simple changes to the shipping/payment method ruins the calculation, the invoice generated via the backend and everything afterwards (tax accounting etc.).
Tags: Admin, Calculations, Order, Order Recalculation, Selection List
Steps To Reproduce: 1. (BE) create a selection list containing a price surcharge/discount
2. (BE) apply selection list to article
3. (FE) order the article with price surcharge/discount (works fine)
4. (BE) change the article count
5. (BE) recalculation ignores the surcharge/discount => totally wrong numbers
Additional Information: Reproducible in OXID CE/PE 4.6.8, 4.10.3
Attached Files: selectlist-bug-1-backend-3-incorrect.jpg (250,885 bytes) 2017-02-03 18:47
https://bugs.oxid-esales.com/file_download.php?file_id=1494&type=bug
selectlist-bug-1-backend-1-correct.jpg (288,984 bytes) 2017-02-03 18:47
https://bugs.oxid-esales.com/file_download.php?file_id=1495&type=bug
selectlist-bug-1-backend-2-correct.jpg (251,320 bytes) 2017-02-03 18:48
https://bugs.oxid-esales.com/file_download.php?file_id=1496&type=bug
selectlist-bug-2-frontend-1-correct.jpg (253,905 bytes) 2017-02-03 18:49
https://bugs.oxid-esales.com/file_download.php?file_id=1497&type=bug
selectlist-bug-2-backend-1-correct.jpg (291,928 bytes) 2017-02-03 18:49
https://bugs.oxid-esales.com/file_download.php?file_id=1498&type=bug
selectlist-bug-2-backend-2-incorrect.jpg (297,416 bytes) 2017-02-03 18:49
https://bugs.oxid-esales.com/file_download.php?file_id=1499&type=bug
invoice-after-modification-incorrect.pdf (502,239 bytes) 2017-02-03 18:50
https://bugs.oxid-esales.com/file_download.php?file_id=1500&type=bug
screencast.gif (3,586,936 bytes) 2017-02-06 14:49
https://bugs.oxid-esales.com/file_download.php?file_id=1501&type=bug
Notes
(0011956)
QA   
2017-02-06 11:32   
The issue is not reproducible in a standard OXID eshop. Kindly verify the behaviour in our demoshop - https://demoshop.oxid-esales.com/professional-edition/
(0011958)
leofonic   
2017-02-06 13:52   
It is reproducable in current demoshop, since recalculation is no longer triggered by setting paydate, you can go to products/refresh and surcharge is lost. (you do not have to change the article count)
(0011959)
kex   
2017-02-06 14:49   
The issue is reproducible in your demoshop (attached "screencast.gif"). As soon as the order gets recalculated, the numbers are wrong (changing article count, cancelling another article, changing payment/shipping method, ...).
(0011960)
QA   
2017-02-06 15:05   
Thank you for the feedback.
(0012035)
dev_ht   
2017-04-10 09:46   
Seems as a critical bug to me, it makes the entire edit-Order panels useless whenever products with surcharges are involved.
(0012036)
FibreFoX   
2017-04-10 11:07   
Maybe related to this: https://bugs.oxid-esales.com/view.php?id=5737
(0012189)
kex   
2017-07-25 11:01   
Are there any updates or plans on fixing this issue? I think this isn't "another minor bug" ...
(0012666)
kex   
2018-11-02 08:56   
... are there any updates? This is a real issue for some users ...
(0012712)
tabsl   
2018-12-03 11:10   
what about this ticket?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6886 [OXID eShop (all versions)] 6. ------ Setup ------- feature always 2018-08-14 11:46 2018-11-29 09:00
Reporter: kaluzki Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: exclude tests from dist-packages
Description: @see https://madewithlove.be/gitattributes/
Tags: Composer, Git
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012583)
QA   
2018-08-16 09:59   
(Last edited: 2018-08-16 10:00)
The testing library is included for development purpose but can be excluded during installation with the paramater --no-dev, which is recommended for a production installation.
It is described in our docs: https://docs.oxid-esales.com/developer/en/6.1/getting_started/installation/eshop_installation.html

I would consider this as a sufficient option.

[sp]

(0012584)
kaluzki   
2018-08-16 11:07   
Its not about the testing library, but about the test files, which are included in almost every composer package:

vendor/oxid-esales/oxideshop-ce/tests
vendor/oxid-esales/oxideshop-doctrine-migration-wrapper/tests
vendor/oxid-esales/oxideshop-facts/tests
vendor/oxid-esales/paypal-module/Tests
etc.

With the option "--prefer-dist" you can let composer to analyse .gitattributes file for "export-ignore" occurences and to shrink the package.
For more details see https://madewithlove.be/gitattributes/

Its a wide-spread approach anyway:

* https://github.com/zendframework/zend-http/blob/master/.gitattributes
* https://github.com/laravel/framework/blob/master/.gitattributes
* https://github.com/composer/composer/blob/master/.gitattributes
(0012707)
naehwelt   
2018-11-29 09:00   
see PL https://github.com/OXID-eSales/oxideshop_ce/pull/673


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6923 [OXID eShop (all versions)] 4.07. Source code, Test minor always 2018-11-22 13:14 2018-11-26 07:58
Reporter: mario_lorenz Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Backend PopUp Ajax Controller in Camelcase
Description: i cant call Backend PopUp Ajax Controller in CamelCase-Spelling. They need the old spelling (lowercase with underline).
Tags: Admin, AJAX, Module
Steps To Reproduce: * create a module with a Backend PopUp Ajax Controller
* gave the Controller-Call the exact name from the class and Filename e.g.:
'MyControllerAjax' => \ MyVendor \ Application \ Controller \ Admin \ MyControllerAjax :: class
* try to call the PopUp
* The PopUp has no Data inside.
Additional Information: I write my own OXID6-Moduls strict in CamelCase-Notation. I use this Camelcase-Controller-Calls allthough in my templates. I have no problems so far.
Now I wanted to create a Backend PopUp Ajax Controller. For example, my controller is called "MyControllerAjax" and the file name is also "MyControllerAjax.php". I was wondering why the two pop-up windows did not fill up with the data. According to Errorlog, OXID tried to call the controller like this: "MyController_ajax" instead of "MyControllerAjax".

The cause lies in In [OXID6.1.1] \ source \ admin \ oxajax.php line 45. Attempting to append the appropriate controller by appending "_ajax" here.

Now I've looked at an original OXID6 controller, for example. "ActionArticleAjax". Unfortunately, the controller in the ...
\ Vendor \ oxide esales \ oxides shop-ce \ source \ Core \ Routing \ ShopControllerMapProvider.php
so routed:
'actions_article_ajax' => \ OxideEsales \ Eshop \ Application \ Controller \ Admin \ ActionsArticleAjax :: class
instead of writing here in Camelcase. I thing there is an extra mapper, there can do this in the old version:
\ Vendor \ oxide esales \ oxides shop-ce \ source \ Core \ Autoload \ BackwardsCompatibilityClassMap.php
which would allow both spellings ...

In my templates I use Camelcase everywhere and only in one place, in my controller configuration in the metadata.php I write now:

'MyController_ajax' => \ MyVendor \ Application \ Controller \ Admin \ MyControllerAjax :: class

This is a mistake.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4209 [OXID eShop (all versions)] 3.1. Design, GUI, UX feature always 2012-06-29 08:53 2018-11-19 15:08
Reporter: saulius.stasiukaitis Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Azure
Browser: All
PHP Version: Not defined
Database Version: Not defined
Summary: Recommendation list (listmania) do not handle new list creation user friendly.
Description: When one add new article to recommendation list and there is no created one found himself in page with sentence "There is no Listmania lists at the moment. To create new, click here."
It is wery uncomfortable to find links in this sentence as it has link only on word "here" and this word is not marked anyhow different from other text. And question is, why do wee need this question at all, would not be better to just move to creation page?

In next steps when one create first Listmania list it is hard to get back to article page. And article is not even in new list.
Tags: CSS
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3318 [OXID eShop (all versions)] 4.11. Image handling feature always 2011-10-17 15:59 2018-11-19 10:07
Reporter: tjungcl Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 4.5.3 revision 39087  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: All
PHP Version: Not defined
Database Version: Not defined
Summary: png scaling: resize used instead of resample
Description: manufacturer logos are often of a very delicate structure, with fine lines and strong contrasts.

when such a logo is resized, the result is often very ugly.

php's gd lib has also methods to resample images, which brings much better results.
Tags: Image Conversion
Steps To Reproduce:
Additional Information: attached see the different results of resizing and resampling
Attached Files: resized_logo.png (1,414 bytes) 2011-10-17 15:59
https://bugs.oxid-esales.com/file_download.php?file_id=608&type=bug
resampled_logo.png (2,076 bytes) 2011-10-17 15:59
https://bugs.oxid-esales.com/file_download.php?file_id=609&type=bug
Notes
(0005327)
tjungcl   
2011-10-17 16:01   
I forgot to mention:

i am of course talking of master manufacturer logos that are resized from the oxid shop into the shops logo-size.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3730 [OXID eShop (all versions)] 4.09. SEO, SEO URL minor always 2012-03-16 12:45 2018-11-13 08:28
Reporter: dainius.bigelis Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 4.5.2 revision 38481  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: All
PHP Version: Not defined
Database Version: Not defined
Summary: Need more universal solution for handling / in the URL for subdomains
Description: When SEO url is stored in the DB and when it's decoded, it forms different URL - in one case it has / in front, in other case - has no /. This leads to not working SEO urls for specific dirs on server, like /admin.
Basically this is up to server configuration in apache, but maybe we can find more general solution for handling all the cases (with / and without).
Tags: SEO
Steps To Reproduce:
Additional Information: Check those as a solution, might work:
Function: processSeoCall()
$sRequest = ltrim($sRequest,'/');
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3642 [OXID eShop (all versions)] 4.11. Image handling major always 2012-02-28 16:02 2018-11-12 14:27
Reporter: tjungcl Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 4.5.8 revision 42471  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: All
PHP Version: Not defined
Database Version: Not defined
Summary: bug in php causes imagecopyresampled to produce artifacts in images
Description: there is a php bug https://bugs.php.net/bug.php?id=41820
that is not fixed for nearly five years now.

it occures not on every machine (on ours it does, of course...) but if you have it, its most annoying:

--> pictures with white backgrounds (as most shops use) have no longer a white background, but one that is striped in #FFFFFF and #FEFEFE.

My own eye-sight wasnt sharp enough to notice this, but several of our designes and photographs did, so it cant be argumented away...

I did not find a workaround for this with gd2, but i tried imagicks resizing function thumbnailImage() and that solved the problem. (I define resizeJpeg() in my functions.php).

=> its solved for me now, but you should consider to check for the lib imagick and use it if present.

Tags: Image Conversion
Steps To Reproduce:
Additional Information:
Attached Files: stripes.jpg (4,721 bytes) 2012-02-28 16:55
https://bugs.oxid-esales.com/file_download.php?file_id=674&type=bug
stripes_vis.jpg (9,996 bytes) 2012-02-28 16:55
https://bugs.oxid-esales.com/file_download.php?file_id=675&type=bug
imagick.jpg (2,533 bytes) 2012-03-02 09:47
https://bugs.oxid-esales.com/file_download.php?file_id=681&type=bug
imagick_vis.jpg (3,597 bytes) 2012-03-02 09:47
https://bugs.oxid-esales.com/file_download.php?file_id=682&type=bug
Notes
(0005827)
tjungcl   
2012-02-28 16:57   
I added a example image, where you see the effect.
This image is copied from the webshop as result of imagecopyresampled().

In the second image the contrast is raised and the brightness reduced to visualize it better.
(0005863)
tjungcl   
2012-03-02 09:49   
added the same image, this time scaled down with imagemagick instead.
Quality setting in imagemagick is 90% (in gd2 95%), because base quality in imagick is generally better.
(0005865)
dainius.bigelis   
2012-03-02 10:22   
@Developers: please check if we can use this imagick lib.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6675 [OXID eShop (all versions)] 2.3. Extensions (modules, themes) major always 2017-08-02 13:52 2018-11-09 10:29
Reporter: AlexN Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 4.10.2 / 5.3.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Flow
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: article details - product image slider/carousel is not fully working
Description: I stumbled on a weird behaviour which seems not to be related to a physical mobile device nor a mobile view port (like 0px to 991px)

The carousel is not working on mobile device(s) and or specific request mode. A javascript error occur in the console.
Tags:
Steps To Reproduce: 1. Open eShop BE and an activated Flow Theme.
2. Browse to any article in eShop BE
3. Add 7 images
4. Browse to that article in eShop FE
5. slider/carousel works
6. open the dev console
7. toggle the device toolbar so it's enabled
8. open the console tab
9. load the detail page again
10. You will see a message like "Uncaught ReferenceError: Carousel is not defined"
Additional Information: I reproduced it with following:
- CE 4.10.2 & 6 BETA
- mobile device ZTE Axon 7
-- firefox & google chrome
- google chrome dev toolbar (v59.0)

I could not reproduce it with:
- firefox dev toolbar (v54.0.1 (32-Bit))
Attached Files: flow-theme-carousel-detail-page.png (483,183 bytes) 2017-08-02 13:52
https://bugs.oxid-esales.com/file_download.php?file_id=1539&type=bug
Notes
(0012201)
QA   
2017-08-03 10:43   
(Last edited: 2017-08-03 14:37)
Reproducible in:
EE 5.3.5
PE 4.10.5
Flow Theme
using Chrome 60 dev-toolbar and device mode
using Firefox dev-toolbar and "Responsive Design Mode" > Agent: mobil

For testing:
Problem exists in all article detail pages, also with only one picture.

In picture lightbox its because of that error not possible to switch between pictures anymore.

No problems when using iPad mode in Chrome.

Also problematic:
When the article is having more than 4 pictures, the thumbnails below the picture are disabled although enough space left. In combination with the mentioned error, on mobile device only one product picture could been seen.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2046 [OXID eShop (all versions)] 1.01. Products (product, categories, manufacturer, promotions etc.) feature always 2010-08-16 14:41 2018-11-08 11:02
Reporter: sarunas_valaskevicius Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.2.0-beta.1  
    Target Version:  
Theme: Not defined
Browser: All
PHP Version: Not defined
Database Version: Not defined
Summary: inconvenient filtering by attributes
Description: if there is only one attribute, filtering the list is inconvenient: if user selects one attribute value, it filters the other options from the list of attributes. To select another attribute user should first click on 'bitte waehlen' option and only then (after page reload) all other attributes are visible.

If there is more than one attribute for the category, then the current solution is ok, though there still could be some 'reset' button.
Tags: Attributes, Category, Products
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0009715)
svetlana   
2014-03-28 10:01   
waiting for the PO decision.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6917 [OXID eShop (all versions)] 1.03. Basket, checkout process minor always 2018-11-07 10:29 2018-11-07 10:57
Reporter: d3 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Explanation marks for downloadable products are not used
Description: If you buy downloadable products, a checkbox with information on the right of withdrawal is shown. This information is marked with 2 asterisks. However, no article has these 2 asterisks in the flow theme.

In the Azure theme this seems to be correct:
[{if $ oArticle-> hasDownloadableAgreement ()}] <sup> #noteForDownloadableArticles </ sup > [{/ if}]
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6784 [OXID eShop (all versions)] 6. ------ Setup ------- minor always 2018-02-05 17:01 2018-11-07 08:29
Reporter: juergen_busch Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.0.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Firefox
PHP Version: Not defined
Database Version: Not defined
Summary: Language changes in step 6/7 "Installation succeeded" of the setup
Description: The language of a German setup changes to English in the last step
* browser used: Firefox 58.0.1 (64-Bit)
* setup of Community and Enterprise Edition 6.0.1
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012668)
QA   
2018-11-05 15:51   
(Last edited: 2018-11-07 08:25)
It's also the other way round. English setup ends with german successfull-page. (tested in PE 6.1.1)

[sp]

(0012669)
QA   
2018-11-07 08:29   
Looks more complicated than i thought. I installed the shop five times more and I've always got the german successfull-page, no matter which language I choosed at the beginning. I can't figure out why this is happening.

[sp]


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4385 [OXID eShop (all versions)] 4.07. Source code, Test minor always 2012-08-14 15:42 2018-11-05 11:16
Reporter: leofonic Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 4.6.3 revision 47975  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: All
PHP Version: Not defined
Database Version: Not defined
Summary: oxDeliveryList::getDeliveryList is not usable in modules
Description: I wanted to use oxDeliveryList::getDeliveryList in a module, but it's not possible, because:
1. $this->_aDeliveries is not resetted, so if you call the method multiple times, _aDeliveries add up. As it is only used in this method, i think it is not neccesary to use a property here.
2. Session Var 'sShipSet' is set inside the method, so it is not possible to call the method with different parameters than current selection, as this will mess up selected shipset.
Tags: Delivery
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0008251)
aurimas.gladutis   
2013-01-14 08:26   
(Last edited: 2013-01-14 08:26)
Hi, one option would be to set the setCollectFittingDeliveriesSets to true. This would give all fitting deliveries, not just first one found, but would also not add up to currently added ones and would not change session.

(0010042)
leofonic   
2014-07-29 13:42   
If setCollectFittingDeliveriesSets is set to true, the method does not return fitting deliveries but only fitting deliverysets.
(0010194)
avalue   
2014-09-29 10:37   
I was working on a module to split orders and got stuck with this issue, too. Fixed it with writing a simple module that sets

$this->_aDeliveries = array();

and calls the parent method. Thanks.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5764 [OXID eShop (all versions)] 7. --- Other tools -------------- tweak always 2014-05-16 11:31 2018-10-30 10:43
Reporter: d3 Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: resolved Product Version: 4.8.5 / 5.1.5  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.1.2  
    Target Version:  
Theme: Azure
Browser: All
PHP Version: Not defined
Database Version: Not defined
Summary: Error: fread(): Length parameter must be greater than 0 ... tools_list.php
Description: Admin --> Service --> Tools --> SQL File

This message will display:
"Warning: fread(): Length parameter must be greater than 0 in /.../application/controllers/admin/tools_list.php on line 167"

when that file has no content (0 bytes).

Tags:
Steps To Reproduce:
Additional Information: A php error message should not appear.
Attached Files:
Notes
(0009922)
jurate.baseviciene   
2014-05-26 08:35   
Reminder sent to: d3
Hi,

Thank you for submitting this case, but we can't reproduce this behavior. Could you please give us more additional information how need to reproduce it. Maybe could you send to us SQL file?

Best regards,
Jurate
(0009924)
d3   
2014-05-26 09:11   
It's simple: create a empty sql-file: "install.sql" and upload it.

Depend on the settings for log_errors/error_reporting you can't see that message.

PHP Warning: fread(): Length parameter must be greater than 0 in /oxikxptm/bonuspunkte.oxiddemo.com/test/485/application/controllers/admin/tools_list.php on line 167


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6539 [OXID eShop (all versions)] 1.01. Products (product, categories, manufacturer, promotions etc.) minor always 2016-11-10 12:05 2018-10-29 15:05
Reporter: alfredbez Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.1.2  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Wrong behaviour from getOrderArticleSelectList when values from selectionlists and variantselections are selected
Description: You can't get the selected value from a selectlist for an orderarticle, if that orderaricle has a selection from a selectlist and also selected variants.
Tags:
Steps To Reproduce: 1. Create article with variants
2. Create and assign a selectlist to that article
3. select variant and a value from the selectlist and buy that article
4. \OxidEsales\Eshop\Application\Model\OrderArticle@getOrderArticleSelectList will not work properly for this article
Additional Information: - https://github.com/OXID-eSales/oxideshop_ce/blob/55fc3fcc7c34fa41e42a490ffc70cfe555168c6f/source/Application/Model/OrderArticle.php#L449
- $sOrderArtSelValue will be something like this: 'selectlistname : selectlistvalue varselectvalue1 | varselectvalue2'
Attached Files:
Notes
(0011863)
alfredbez   
2016-11-10 12:25   
Merge Request (with failing unit test as a patch in first comment): https://github.com/OXID-eSales/oxideshop_ce/pull/507
(0012661)
anton.fedurtsya   
2018-10-24 16:18   
Pull request tested and merged


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6915 [OXID eShop (all versions)] 2.6. Administer orders minor always 2018-10-26 15:57 2018-10-26 17:35
Reporter: berkmueller Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.0.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: All
Browser: All
PHP Version: All
Database Version: All
Summary: Inconsistency when multiple modules extend templates but don't use explicit sort order
Description: Due to a missing default sort order some inconsistencies (e.g. in admin's order list view) can happen where column headers do not match the values in the data rows because of a displacement.

The reason for this is that the default sort order for template blocks (see `\OxidEsales\EshopCommunity\Core\Module\ModuleTemplateBlockRepository::getBlocks()`) is
`order by oxpos asc, oxtheme asc, oxid asc` (https://github.com/OXID-eSales/oxideshop_ce/blob/36c63bae25751ae0fc1962aace2fafc88675c25b/source/Core/Module/ModuleTemplateBlockRepository.php#L60).
That means when two modules extend the same block but have the default oxpos (0), it depends on the generated OXID. Due to the fact that newly generated OXIDs are not lexicographically ordered,
it could be the case that for example module A comes first for extending a tables header in admin but module B is first for extending the data row template. This can lead to inconsistencies as
can also seen in the screenshots provided.

As a simple fix, just change
```
order by oxpos asc, oxtheme asc, oxid asc";
```
to
```
order by oxpos asc, oxtheme asc, oxmodule asc, oxid asc";
```
and the problem is solved.
Tags: Admin, Admin Template, Module, Template Blocks
Steps To Reproduce: 1.) Given the admin enables the modules fcPayOne and oePayPal (which both extend admin templates in the order list view (header and row templates))
2.) When an order was placed
3.) And a backend user goes to the admin order page
4.) Then the header and rows of the columns "payone ref.nr.", "payment type" and "shop payment status" do not match.
Additional Information:
Attached Files: order-list-with-bug.png (14,198 bytes) 2018-10-26 15:57
https://bugs.oxid-esales.com/file_download.php?file_id=1659&type=bug
order-list-fixed.png (14,326 bytes) 2018-10-26 15:57
https://bugs.oxid-esales.com/file_download.php?file_id=1660&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3197 [OXID eShop (all versions)] 4.07. Source code, Test minor always 2011-08-29 11:21 2018-10-24 10:53
Reporter: tjungcl Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 4.5.1 revision 38045  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: All
PHP Version: Not defined
Database Version: Not defined
Summary: searchkeys obsolete
Description: the field oxsearchkeys currently has two effects:
- its content is added to the meta-keywords html tag
- if the fields "tags" is empty, the searchkeys are copied into it on save

To set the metakeyswords of an article, there is the meta-keywords input in the seo-tab. To set tags, there is the input field "tags".

=> I missing to see the point in the searchkeys field at all.
Tags: Products, SEO, Tags
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3531 [OXID eShop (all versions)] 1.03. Basket, checkout process minor always 2012-01-30 15:52 2018-10-22 11:35
Reporter: michael_keiluweit Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 4.5.6 revision 40808  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Flow
Browser: All
PHP Version: Not defined
Database Version: Not defined
Summary: changes of delivery address are not saved during choosing another delivery address at the same time in order step 2
Description: first, your account needs two delivery addresses.

-login and put something in the basket.
-goto step 2.
-change something at billing address and choose another delivery address.
-click on the button "change".

now you can see, that only the shipping address has changed as you want. your changes of billing address are not taken.
Tags: Address, Basket
Steps To Reproduce:
Additional Information: bug exists also in version 4.5.2. so maybe the bug is in older version, too.


not checked for basic theme.
Attached Files:
Notes
(0005822)
dainius.bigelis   
2012-02-27 20:52   
Actually - the changed values in the Billing address form remains, but after you change the delivery address and the page reloads - you see only previously saved data, but not the latest changes in Billing address. Latest changes you can see only if you press "Change" and values are written in the input fields of form.
When going to next step values are saved - then those are shown also in readme mode.
This should be fixed, because If user changes Billing address details and then just selects another from two Shipping addresses - then changes in Billing address are hidden (previous info is shown), but when going to next step changes are saved and will be seen only in the Last order step.
(0012653)
QA   
2018-10-22 11:35   
"When going to next step values are saved" -> set priority to minor as the changes are saved, just not only directly shown in step 2 when not pressing enter after changing values of the billing address.

- MK


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6657 [OXID eShop (all versions)] 1.02. Price calculations (discounts, coupons, additional costs etc.) minor always 2017-06-28 11:35 2018-10-22 08:41
Reporter: vanilla thunder Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 4.10.2 / 5.3.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Product and category coupon's value calculated from article's basket price instead of actual basketitem price
Description: category and product coupons take product's original price for calculating discount value instead of getting the actual basketitem price, which could be alredy reduced.
You get the biggest side effect when combining discounts and coupons at same time, e.g. you offer 33% discount for a product "buy 3, pay 2" and also 10% for particular products or categories. When bots discount and coupon are valid for the product in your basket, both discount and coupon values are calculated with the original undiscounted price.
Tags:
Steps To Reproduce: 1) product X costs 300€
2) crate 100 € discount for product X
3) crate 10% coupon test666
4) add X to basket
5) you see: product X - 200€ ([del]300€[/del])
6) enter coupon code test666
7) coupon value is calculated based on 200€ price -> 20€
8) assign product xor its category to the coupon series
9) recalculate basket
10) coupon discoutn value is calculated based on product's original price 300€ -> 30€
Additional Information: compare functions:
oxVoucher::_getGenericDiscoutValue
oxVoucher::_getCategoryDiscoutValue
oxVoucher::_getProductDiscoutValue

_getGenericDiscoutValue uses passed $dPrice from oxBasketitem for discount values calcultion

_getCategoryDiscoutValue and _getProductDiscoutValue get array of basket items from function _getSessionBasketItems (inside _getBasketItems), but it contains prices from $oArticle->getBasketPrice(...), which are undiscounted.
Using $oBasketItem->getUnitPrice()->getPrice() instead, would give the current price of the basket item


here is my fix approach:

$aItems[$iCount] = array(
    'oxid' => $oArticle->getId(),
    //'price' => $oArticle->getBasketPrice($oBasketItem->getAmount(), $oBasketItem->getSelList(), $oBasket)->getPrice(),
    'price' => $oBasketItem->getUnitPrice()->getPrice(),
    //'discount' => $oDiscount->getAbsValue($oArticle->getBasketPrice($oBasketItem->getAmount(), $oBasketItem->getSelList(), $oBasket)->getPrice()),
    'discount' => $oDiscount->getAbsValue($oBasketItem->getUnitPrice()->getPrice()),
    'amount' => $oBasketItem->getAmount(),
);
Attached Files: 01.PNG (95,247 bytes) 2017-06-28 16:02
https://bugs.oxid-esales.com/file_download.php?file_id=1529&type=bug
02.PNG (96,718 bytes) 2017-06-28 16:03
https://bugs.oxid-esales.com/file_download.php?file_id=1530&type=bug
demoshop.PNG (100,299 bytes) 2017-06-28 16:14
https://bugs.oxid-esales.com/file_download.php?file_id=1531&type=bug
discount.JPG (105,470 bytes) 2018-10-22 08:40
https://bugs.oxid-esales.com/file_download.php?file_id=1657&type=bug
Notes
(0012164)
QA   
2017-06-28 16:02   
i tried to reproduce on https://demoshop.oxid-esales.com/professional-edition/
but the coupon discount value is calculated not on the product's original price 300€ -> 30€, but on the discounted price 200€ -> 20€.

see Screenshot
(0012165)
vanilla thunder   
2017-06-28 16:13   
(Last edited: 2017-06-28 16:14)
i guess, you forgot to assign trapez ion or it's category to the coupon series (step 8).
i configured right now everything as described, not sure how often demoshop resets.
(i added demoshop.PNG screenshot)

(0012647)
technik@jabommi.de   
2018-10-19 12:38   
Haben den gleichen Fehler bei einer CE 4.9.5:

Produkt hat Preis von 53,95€

In Oxid ist ein Rabatt eingestellt von 5% , Einkaufsmenge 1-99999, Artikelzuordnung zu diesem Produkt

Der Gutschein hat einen Rabatt von 10% und der Gutschein ist diesem Produkt zugeordnet.

Der Warenkorb stellt nun die Position korrekt mit 51,25€ dar. Füge ich nun den Gutschein hinzu werden nicht 5,13€ angezogen sondern 5,40€ also 10% vom ursprünglichen Artikelpreis.

Lässt man nun beim Gutschein die Artikelzuordnung weg, dann wird korrekterweise 5,13€ für den Gutschein abgezogen.
(0012650)
FibreFoX   
2018-10-19 19:59   
@technik@jabommi.de you should rewrite that in english, as the whole bug-tracker is english, otherwise you risk you comment getting ignored.
(0012651)
QA   
2018-10-22 08:40   
(Last edited: 2018-10-22 08:41)
Reproduced and translated what technik@jabommi.de wrote in PE / EE 6.1.0:

Have the same error with a CE 4.9.5:
Product has price of 53,95€
In Oxid a discount of 5% is set, purchase quantity 1-99999, article assignment to this product.
The voucher has a discount of 10% and the voucher is assigned to this product.
The shopping cart now shows the position correctly with 51,25€. If I now add the voucher are not attracted 5.13€ but 5.40€ so 10% of the original article price.
If you omit the article allocation now with the voucher, then correctly 5.13€ is deducted for the voucher.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6911 [OXID eShop (all versions)] 2.2. Shop settings minor always 2018-10-18 16:03 2018-10-19 14:43
Reporter: pbenke Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: acknowledged Product Version: 6.1.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Flow
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Configuration error in shop
Description: There are a lot of settings, if flow theme (ore another theme) is used.
But there are some parameters already stored in table oxconfig by installing the shop, which are also settings in flow theme:

- sThumbnailsize
- sCatThumbnailsize
- sIconsize
- sZoomImageSize
- aDetailImageSizes

Defined in file: oxidshop-ce => source/Setup/Sql/initial_data.sql

INSERT INTO `oxconfig` (`OXID`, `OXSHOPID`, `OXMODULE`, `OXVARNAME`, `OXVARTYPE`, `OXVARVALUE`) VALUES
('8563fba1baec57c19.08644217', 1, '', 'sThumbnailsize', 'str', 0x07c4b144c7b838),
('8563fba1baec599d5.89404456', 1, '', 'sCatThumbnailsize', 'str', 0x5d43334072bf3f),
('6ec4235c2aaa45d77.87437919', 1, '', 'sIconsize', 'str', 0x5d09ae6470),
('62642dfaa1d88b1b2.94593071', 1, '', 'sZoomImageSize', 'str', 0xfb42b1443b3e38),
('62642dfaa1d87d064.50653921', 1, '', 'aDetailImageSizes', 'aarr', ...

Maybe these rows could be deleted, just depends on the theme.

Thanks
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6164 [OXID eShop (all versions)] 4.01. Database handling feature N/A 2015-06-11 14:20 2018-10-19 12:25
Reporter: bjoerk Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: resolved Product Version: 4.9.3 / 5.2.3  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.0.2  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: All
Database Version: Not defined
Summary: max size of BLOB for oxconfig.oxvarvalue can be exceeded
Description: Having a highly modifyed EE with a huge amount of extensions the maximum size 64KB for the datatype BLOB auf oxconfig.oxvarvalue can be exceeded.
This leads into a complete breakdown of the OXID module system and the shop goes offline because there is no check if the max size of oxvarvalue will be exceeded when adding new entries.
Reaching the maximum of 64KB the data of oxvarvalue is truncated at the maximum byte which leads into an incomplete serealized array and the shop will stop working.
Changing to MEDIUMBLOB and reinstalling all modules solves the problem.
At least for Enterprise Edition this should be default and all editions should get a check to avoid running into this problem.
Tags:
Steps To Reproduce:
Additional Information: 0005948 was closed without changes and the note that this case is unusual.
Assuming that most EE will be highly modified this should be deemed as a usual use case.
Attached Files:
Notes
(0011028)
QA   
2015-06-11 14:57   
While possible, there is no known impact of this issue until now.

Though, it would make sense to extend said BLOB field to MEDIUMBLOB in future releases to play it safe.

IMHO this is a (valid) feature request.
(0011330)
d3   
2015-11-26 14:27   
We have got the same problem...

IMHO it's a bug. There are no communicated module limitations. In our case (ca. 80 modules) this "feature request" crashes the shop.

DS
(0011333)
FibreFoX   
2015-11-26 15:31   
This is a bug, clearly, because the shop just does not validate length of the content its going to put into the database. Same "just a feature"-feeling like when hitting https://bugs.oxid-esales.com/view.php?id=5549

nothing documented, but working (maybe not as wished) -> feature or bug
nothing documented, and breaking the shop -> bug
(0011596)
keywan.ghadami   
2016-05-20 14:51   
having the same problem using MEDIUMBLOB helped
(0012404)
d3   
2018-02-28 17:18   
same problem again, pull request for current shop version: https://github.com/OXID-eSales/oxideshop_ce/pull/633
(0012405)
FibreFoX   
2018-03-01 12:34   
Maybe instead of pushing the limit this should result in some technical redesign. In the meantime there should be limitation-checks which get reported into the logfiles, or even not being able to activate such modules.
(0012406)
anton.fedurtsya   
2018-03-01 16:08   
Thanks, the Pull request 633 was merged to 6.x and master.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6885 [OXID eShop (all versions)] 4.09. SEO, SEO URL minor always 2018-08-13 15:28 2018-10-18 16:43
Reporter: kaluzki Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: \OxidEsales\EshopCommunity\Application\Model\SeoEncoderArticle::_getCategory (same "if" and "elseif" branches)
Description: same "if" and "elseif" branches

probably should be:

        if ($oView instanceof \OxidEsales\Eshop\Application\Controller\FrontendController) {
            $oCat = $oView->getActiveCategory();
        } elseif ($oView instanceof \OxidEsales\Eshop\Core\Controller\BaseController) {
            $oCat = $oView->getActCategory();
        }

@see
Commit: 1c91a9fc511e69dca19980a7c79ac802ba4c0e2d
ESDEV-4086 Replace oxclasses in instanceof


Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6146 [OXID eShop (all versions)] 1.03. Basket, checkout process feature always 2015-05-19 10:36 2018-10-18 07:49
Reporter: simon_stark Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: acknowledged Product Version: 4.9.4 / 5.2.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Azure
Browser: All
PHP Version: Not defined
Database Version: Not defined
Summary: Newsletter Checkbox in Checkout Progress doesn't show the actual Status of the newsletter subscription of guest users
Description: If you subscribe to the newsletter without opening an account, and then check out without opening an account while using the same Email-Adress than before, the newsletter registration checkbox during checkout isn't ticked, which will lead to unsubscription from the newsletter during checkout if left as is.

While the behavior is absolutely correct this way, it would be more convenient to verify somewhere in checkout whether the email adress was already used for newsletter subscription or not, and set the checkbox mentioned above accordingly.
Tags:
Steps To Reproduce: 1) subscribe to newsletter
2) make an order as a guest using the same email adress. Note the fact described above.
3) you're unsubscribed after finishing the order.
Additional Information:
Attached Files:
Notes
(0010988)
henrik.steffen   
2015-05-22 10:40   
As discussion started in 0005040 I'd prefer this solution:

2) Switch behaviour from "unsubscribe" to "don't change anything", if checkbox is not checked (might have some legal issues)


I'm not a lawyer, but I'd believe that it's not even a legal issue.
Users don't expect that they get unsubscribed from a newsletter, which they already confirmed by double opt-in, simply by not checking the checkbox to subscribe again and again every time they place an order in the same shop.

This would also start the double opt-in procedure every time again and again.

I think there is no risk in keeping the subscription, because the shop owner can proof, that user has completed the double opt-in previously and from data protection point of view, we simply don't change anything about the newsletter subscription when user was already subscribed. If the user wants to unsubscribe, there are several ways to do so. So no concerns from my point of view.
(0012114)
Firefax   
2017-06-12 18:13   
(Last edited: 2017-06-12 18:18)
This bug is really really serious from the marketing point of view! I think we loose half of our newslettersubscribers due to this issue and we spend a lot money to get newslettersubscriptions.

I also think, that the solutin should be:
2) Switch behaviour from "unsubscribe" to "don't change anything", if checkbox is not checked

From the legal point of view, it just may not be prechecked. But nobody expects to recheck his newsletter EVERY time. You may Call the checkbox: "Add to newsletter".
If you accept the opinion of my lawer, i will ask him for a statement to you. (But i think you trust only you own one;) ).

Servity should be: critical !
Priority should be: high !

(0012214)
Moehlis   
2017-08-29 00:01   
it'd be nice if this annoying non-feature finally gets fixed. afaik the change is trivial:

oxcmp_user.php:536 (createUser(), CE 4.8.6)
current: if ( $blOptin && $iSubscriptionStatus == 1 ) {
fixed: if ( $iSubscriptionStatus == 1 ) {


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2777 [OXID eShop (all versions)] 1.05. Users minor always 2011-04-21 10:20 2018-10-18 07:49
Reporter: Bergfreunde Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: 4.10.4 / 5.3.4  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: All
Browser: All
PHP Version: Not defined
Database Version: Not defined
Summary: Newsletter - Users already subscribed for newsletter shouldn't be set to oxdboptin = 2 when they subscribe again
Description: When there is double-optin and a user subscribes for newsletter and confirms the following email the value oxnewssubscribed.oxdboptin is "1"

When user subscribes again oxdboptin will be reset to value "2". I think that shouldn't happen - value should stay "1" and user maybe should get a message that he is already subscribed.

Else I could unsubsribe several users of other shops by tiping e-mail adresses into newsletter-subscription field until they confirm the double-opt-in mail again.
Tags:
Steps To Reproduce: http://demoshop.oxid-esales.com/enterprise-edition/newsletter/

- enter mailadress
- confirm double-opt-in mail
- check newsletter-flag in shopadmin (it is set now)
- reenter mailadress in frontend
- check newsletter-flag in shopadmin (it is gone)
Additional Information:
Attached Files:
Notes
(0012113)
marco_steinhaeuser   
2017-06-12 11:06   
(Last edited: 2017-06-12 11:06)
In this forum thread @Firefax complains that the issue wasn't resolved and can be reproduced in 4.10.4: http://forum.oxid-esales.com/showthread.php?t=41145

In reply, @foxido.de provides a possible resolution: http://forum.oxid-esales.com/showthread.php?t=41145#post187853

Please re-check. Thanks!

(0012115)
Firefax   
2017-06-12 18:25   
Hi, i think this ticket has the same reason as / is relatet to https://bugs.oxid-esales.com/view.php?id=6146

If you already have a sucessful double opt in registration, just don't change anything, when you register again.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4624 [OXID eShop (all versions)] 2.6. Administer orders major always 2012-10-12 16:50 2018-10-17 14:13
Reporter: Linas Kukulskis Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Azure
Browser: All
PHP Version: Not defined
Database Version: Not defined
Summary: Order recalculation does not use discounts/taxes which were valid when order was made, but current ones
Description: in admin, on order recalculation must be used order article data and old discount rules (or other tax calculations), but not the real time prices. example order was made with discount and now this discount is over: on recalculations all article price will be without discount - its not correct

what can effect order:
1. new discounts
2. new shipping, payment rules
3. price storing mode in db
4. etc.

 
Tags: Order, Order Recalculation
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0007955)
ray   
2012-11-22 20:16   
https://bugs.oxid-esales.com/view.php?id=4275
(0008127)
timrandy   
2012-12-14 08:21   
Hello,
I have the same problem and have no idear how to solve it?!
(0008224)
ray   
2013-01-07 09:23   
related: http://forum.oxid-esales.com/showthread.php?p=14221

(when generating PDF-invoice it always takes actual date)
(0008320)
ray   
2013-01-24 07:47   
related: https://bugs.oxid-esales.com/view.php?id=4868

(recalculating VAT if delivery country changes or VAT-ID is provided afterwards)
(0008333)
ray   
2013-01-27 18:59   
related https://bugs.oxid-esales.com/view.php?id=4875

(save created pdf-invoice, do not recreate everytime)
(0008403)
mart   
2013-02-12 22:19   
Hi,

what is the current state of this issue? Almost 4 months are passed and still not solved?

Is there any product manager reading those comments? This is definitely not a major issue. I had again the situation that after adding manually an article to the order the prices were reset.

Currently I have the feeling that Oxid is really fragile and you should not do any other things with it...

What is the current test coverage? Are you creating regression tests before fixing bugs?

Sorry, but I am really frustrated...
(0008699)
WBL_BjoernLange   
2013-05-14 09:10   
I got this bug too. And for example, Ticket 0004677 is still not closed in the latest 4.7 version.
(0008700)
ray   
2013-05-14 09:34   
here is a hack (not yet fully workable, but everyone can add more functionality)

https://github.com/jasonkx/Backend-Order-OXID
(0009086)
EggSupport   
2013-09-16 11:13   
you will find a recalc fix attached this bug note
--> https://bugs.oxid-esales.com/view.php?id=5254
(0009342)
ray   
2013-12-06 17:51   
there is a new module available working as well with CE 4.8 which prevents recalculating

http://forum.oxid-esales.com/showthread.php?p=136297#post136297
(0009344)
leofonic   
2013-12-06 22:03   
imho it is better to actually prevent recalculation than to fix it. I wrote a module that fixates an order if an invoice exists, and allows changes to paydate and billnr without recalculation:
https://github.com/leofonic/No_Recalc
(0009433)
ray   
2014-01-21 07:48   
main thread to collect all issues (and possible fixes) in forums:
http://forum.oxid-esales.com/showthread.php?t=21886
(0011806)
alfredbez   
2016-09-27 11:07   
Recalculation is also wrong, when iMallPriceAddition is set. (Version EE 5.2)
(0012256)
FibreFoX   
2017-11-03 11:31   
This issue is open for over 5 years now, is there any plan for working on this topic? (Maybe a complete rewrite of the whole calculation-logic...) This should be "blocker" instead of just "major".
(0012375)
henrik.steffen   
2018-02-05 15:50   
I'd also vote for fixing this issue sooner or later (but not too late please)
(0012538)
szdirk   
2018-07-17 14:16   
Is there any chance that this very old bug will be fixed at any time?
If there is no interest to fix this bug @OXID please close this bug or at least leave a comment here.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6522 [OXID eShop (all versions)] 1.10. RSS minor always 2016-10-11 15:09 2018-10-10 12:52
Reporter: dfu Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: resolved Product Version: 4.10.1 / 5.3.1  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version: 6.1.1  
    Target Version:  
Theme: Azure, Flow
Browser: Not defined, Firefox, Internet Explorer, Google Chrome, Apple Safari
PHP Version: All
Database Version: All
Summary: Wrong price-calculation for variants in RSS-feed
Description: If you set an parent article price (so with variants) to 0.00, the price-calculation fails and throws something like "jeans ab 0,00".
Instead of taking varMinPrice, the price is taken.

The price of the parent article (specially if not buyable) shouldn't be considered as a price.
Tags: Solution Provided
Steps To Reproduce: - Navigate to the demoshop / install a new shop
- Install demo-data
- Set price of the Anna-Jeans article to 0,00
- Watch "newest articles" rss feed

The price of the unbuyable parent article is display instead of the min price of the variants
Additional Information:
Attached Files:
Notes
(0011832)
dfu   
2016-10-11 15:51   
https://github.com/OXID-eSales/oxideshop_ce/pull/498
(0011833)
QA   
2016-10-12 10:28   
if in shop admin -> master settings -> core settings -> system -> Parent" Products can be purchased is checked and the price of the parent article is set to 0 EUR the varMinPrice is set to 0 EUR.

If option is not checked the varMinPrice is set to the lowest variant price.

So everything works fine. Nothing has to be changed.
Bug will be closed.
(0011835)
marco_steinhaeuser   
2016-10-12 11:16   
It turned out that the issue was misunderstood, that's why this bug will be re-opened again.

> "If option is not checked the varMinPrice is set to the lowest variant price."

This is not true. In RSS feed getPrice is used instead of getVarMinPrice. So the issue is clearly about the RSS feed, not the regular page view.
(0012636)
anton.fedurtsya   
2018-10-10 12:52   
Fixed with mentioned pull request.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6902 [OXID eShop (all versions)] 1.02. Price calculations (discounts, coupons, additional costs etc.) critical always 2018-09-13 11:52 2018-09-17 12:49
Reporter: JCT Platform:  
Assigned To: OS:  
Priority: urgent OS Version:  
Status: resolved Product Version: 6.1.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.1.1  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Product detail page logged in user – wrong return value FrontendController.isVatIncluded()
Description: If an registered user is logged in without UStID, the FrontendController returns the wrong value for VAT included.
This is due to a type mismatch in PHP.
The if statement has a explicit type comparison to null, the given value from the database is an empty string ''. (Line: 2952 | Application/Controller/FrontendController.php)
Tags:
Steps To Reproduce: 1. Register a new user with account and leave the UStID fields empty.
2. Login as the new registered user
3. Open a product detail page
Additional Information:
Attached Files:
Notes
(0012625)
JCT   
2018-09-13 13:52   
PR: https://github.com/OXID-eSales/oxideshop_ce/pull/666
(0012626)
QA   
2018-09-13 15:30   
With a new created user the prices have no * mark anymore after login.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6901 [OXID eShop (all versions)] 1.03. Basket, checkout process minor always 2018-09-11 13:40 2018-09-12 07:28
Reporter: michael_keiluweit Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: If an error occurs during the registration of a new user then the basket will be purged.
Description: see steps to reproduce
Tags: Basket, User Creation
Steps To Reproduce: 1. register a user, remember his mail address.
2. log out and make sure your session will be lost.
3. put one product into the basket
4. click on "my account"
5. click on "open account"
6. fill the form, use the mail address from step 1

After that the shop will print out a message that it couldn't register you and your basket is gone. That's because \OxidEsales\EshopCommunity\Application\Component\UserComponent::registerUser leads to \OxidEsales\EshopCommunity\Application\Component\UserComponent::logout which leads to \OxidEsales\EshopCommunity\Application\Component\UserComponent::_afterLogout which calls finally \OxidEsales\Eshop\Core\Registry::getSession()->delBasket();.
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6879 [OXID eShop (all versions)] 1.01. Products (product, categories, manufacturer, promotions etc.) major always 2018-08-10 10:16 2018-09-11 10:29
Reporter: d3 Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: acknowledged Product Version: 4.10.7 / 5.3.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: inactive manufacturer + vendor doesn't redirect to start page
Description: 1. inactive manufacturer
Reproduction:
Go to admin -> manufacturer -> set "Cabrinha" (for example) to inactive
go to seo tab -> copy seo url -> paste in frontend with shopurl (www.domain.de/en/By-Manufacturer/Cabrinha/)
an empty page will displayed. -> it have to be a redirect to startpage (302/307)

2. inactive vendor
Reproduction:
Go to admin -> manufacturer -> set "www-lonasport-com" (for example) to inactive
go to seo tab -> copy seo url -> paste in frontend with shopurl (www.domain.de/en/By-distributor/www-lonasport-com/)
an full page with articles will displayed! -> it have to be a redirect to startpage (302/307)

Tags: Manufacturer, SEO, Vendor
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012568)
d3   
2018-08-10 10:18   
reproducable in 4.10.x/5.3.x and in 6.1.0 too
KH


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6774 [OXID eShop (all versions)] 2.6. Administer orders minor always 2018-01-19 09:44 2018-09-10 16:26
Reporter: QA Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: resolved Product Version: 6.0.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: In backend, orderlist column 'PAYMENT METHOD' stays empty
Description: In backend -> 'Bestellungen', the PayPal module adds columns 'PAYMENT METHOD' and 'SHOP PAYMENT STATUS' to the top orderlist. In v6, the column 'PAYMENT METHOD' stays empty.

Further question: Does it make sense to show the additional columns only if PayPal module is active?
Tags: Admin Template, Order List, PayPal
Steps To Reproduce: - activate PayPal module
- order something
- look up the orderlist
Additional Information: /modules/oe/oepaypal/views/blocks/oepaypalorder_list_items_actions.tpl normally writes the value to the list: [{$listitem->oxorder__paymentname->value}]

Problem: '$listitem' doesn't contain a 'paymentname' in v6.
Attached Files:
Notes
(0012587)
tte   
2018-08-20 14:14   
I've submitted a pull request on GH which should take care of this problem:

https://github.com/tobiaseichert/paypal/commit/967b39d80b5681faddb76d98de993f4a5414977f
(0012592)
anton.fedurtsya   
2018-08-28 10:58   
The bug fix is merged to current PayPal module master and will be released 5.2.3


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6847 [OXID eShop (all versions)] 1.10. RSS minor always 2018-06-22 12:57 2018-09-04 16:49
Reporter: fthielen Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.0.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: 7.0
Database Version: 5.5
Summary: Exception gets thrown if the RSS Feeds are not enabled
Description: If the RSS Feeds are disabled, and you try to access the RSS Feed,
the Shop tries to call the 404 Handler, but throws an Exception:
[message ERROR_MESSAGE_SYSTEMCOMPONENT_FUNCTIONNOTFOUND catarts]

https://forum.oxid-esales.com/t/exception-wenn-die-rss-feeds-nicht-aktiviert-sind/93703?u=fthielen
Tags: 302, Exception, RSS
Steps To Reproduce: 1. Disable the RSS Feeds
2. Try to access the Feed: http://shop-url/source/?cl=rss&fnc=catarts
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6894 [OXID eShop (all versions)] 4.08. Cache minor always 2018-08-29 10:27 2018-09-03 11:56
Reporter: dx_bhesse Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Caching in CategoryList does not reflect filters applied in _getSelectString()
Description: In an Oxid EE (current git-version - as of writing commit-id: 7a024c192f91c31136be0b341d7d06a189a378da):
getCacheKey() includes the shop-id and the language, but does not include any filters applied in _getSelectString() like the "current category" in _getDepthSqlUnion() or the load-level in _getDepthSqlSnippet()

getCacheKey(): https://github.com/OXID-eSales/oxideshop_ee/blob/master/Application/Model/CategoryList.php#L130
_getSelectString(): https://github.com/OXID-eSales/oxideshop_ce/blob/master/source/Application/Model/CategoryList.php#L179

Depended on the order the "oxcategorytree_X_Y.cache"-file is generated, it contains incomplete/wrong data for another CategoryList-instance with other filters applied
Tags:
Steps To Reproduce: 1) Clear cache
2) Init CategoryList with setLoadFull(false), and buildTree() with any category
3) Cache file will be generated by load() called in buildTree()
4) Init CategoryList with setLoadFull(true) and buildTree() with another category as argument
5) Cached data will be reused by load(), but the cached data from previous load from step 1 might not contain all wanted data for step 4 (depending on the categories used as arguments for buildTree())
Additional Information: Instead of completely disabling the cache, a quick workaround might be to include a hash of _getSelectString() in getCacheKey()

Probably related: https://bugs.oxid-esales.com/view.php?id=6410
Attached Files: cc_run1.php (3,400 bytes) 2018-08-30 13:37
https://bugs.oxid-esales.com/file_download.php?file_id=1642&type=bug
cc_run1_output.zip (752 bytes) 2018-08-30 13:39
https://bugs.oxid-esales.com/file_download.php?file_id=1643&type=bug
Notes
(0012594)
QA   
2018-08-30 09:12   
(Last edited: 2018-09-03 11:55)
It's correct, that the filters don't get stored in the cache files. Though this isn't a bug, because it is not supposed to be like you requested. So this part is actually a feature request.

Nevertheless it looks like you also want to describe another behavior resulting from the issue mentioned right before. Unfortunately I can not get the point of your description. The cache file stores the category independently from the filters. You can create the cache file with and without filters and diff the files - they are the same.

In summary, what I currently get from your issue description is a feature request for adding the filters to the category caching system. If that is not what you wanted to tell, please provide some more (detailed) information about your concern.

[sp]

(0012596)
dx_bhesse   
2018-08-30 13:37   
>It's correct, that the filters don't get stored in the cache files.
The filtered data gets stored - Thats the issue.
>You can create the cache file with and without filters and diff the files - they are the same
Only if the cache was not cleared between two different calls - and the data stored in the cache is then wrong for the second call.

cc_run1.php is a sample script:
1) From line 11: Cache is cleared and CategoryList->buildTree() for category-id '0f4fb00809cec9aa0910aa9c8fe36751' (Kites) is called with setLoadFull(true) and setLoadLevel(1) before calling buildTree
2) From line 27: Cache is cleared and CategoryList->buildTree() for category-id 'fad569d6659caca39bc93e98d13dd58b' (Sportswear) is called with setLoadFull(false) before calling buildTree
3) From line 45: step 1 is repeated without clearing the cache first - now the output differs from the output of step 1

cc_run1_out.html is the output of the script.
The output of step 1 + 3 should be the same, with and without having the cache enabled.
(0012598)
dx_bhesse   
2018-08-30 13:39   
Here the missing cc_run1_output.html
(0012599)
QA   
2018-08-30 15:18   
(Last edited: 2018-09-03 11:56)
Thank you for your script and the further explanation. While you were working with a script, I have tested the issue only with the shop itself. In this case, the _blForceFull parameter is always set to true, so filtering isn't important for the caching mechanism. Like I mentioned before, cache file is generated without including the filters. Anyway, now I understand your concern and will acknowledge the issue as a bug. Since the option _blForceFull is always set to true and there isn't any execution of CategoryList::setLoadFull(false) in the shop itself (except one old test), priority is lowered.

[sp]

(0012600)
dx_bhesse   
2018-08-30 15:36   
As a small added note:
We actually noticed the problem in a shop where the "digidesk evomenu"-module is used.
When the Oxid-EE Cache was enabled, the menu had missing subcategories and we tracked down the problem to the CategoryList class.
Probably the evomenu calls buildTree() without setLoadFull(true) before any oxid-code does.
The currently used workaround is to extend getCacheKey() and force a setLoadFull(true) there

(low priority is ok - we just wanted the problem to be known...)
(0012601)
QA   
2018-08-30 15:46   
(Last edited: 2018-09-03 11:56)
Since it's acknowledged, our product management will decide about the next steps. Thanks for the further information.

[sp]



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6877 [OXID eShop (all versions)] 4. ------ eShop Core ------- text always 2018-08-08 09:50 2018-08-30 10:30
Reporter: michael_keiluweit Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.1.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
Database Version: Not defined
Summary: Monolog: Documentation != Source Code information mismatch
Description: Our documentation states that the logger writes into a file starting from log level 'warning'.
All messages of log level warning or higher will be written to :file:`source/log/oxideshop.log`.

Source: https://github.com/OXID-eSales/developer_documentation/blob/b-6.1/system_architecture/logging.rst#configuration-and-extension

However the file config.inc.php initialise the log level with 'error'. So will the Handler be initiated. The result: warnings will not be logged into a file and disappear into to the oblivion (since no handler is registered for the level 'warning').
Source: https://github.com/OXID-eSales/oxideshop_ce/blob/master/source/config.inc.php.dist#L190

Either we change the log level in config.inc.php to "warning" or we adapt the documentation.
Tags: Exception, Monolog
Steps To Reproduce: Put the following code into the file index.php and call the shop. Check the log file in log/oxideshop.log

$logger = \OxidEsales\Eshop\Core\Registry::getLogger();
$logger->warning('warning message');
$logger->error('error message');


Expected:
[2018-08-08 09:52:37] OXID Logger.WARNING: warning message [] []
[2018-08-08 09:52:37] OXID Logger.ERROR: error message [] []


Got:
[2018-08-08 09:52:37] OXID Logger.ERROR: error message [] []
Additional Information:
Attached Files:
Notes
(0012593)
robert blank   
2018-08-29 12:06   
As we already log some stuff to the "warning" level in the shop shop code, "warning" should IMHO also be set as default level in config.inc.php.dist.
Sadly people with existing v6.1 installations would have to adapt their config.inc.php manually.
(0012595)
michael_keiluweit   
2018-08-30 10:30   
maybe this line must also be changed: https://github.com/OXID-eSales/oxideshop_ce/blob/master/source/Internal/Logger/Configuration/MonologConfiguration.php#L35 (MonologConfiguration::$defaultLogLevel)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6889 [OXID eShop (all versions)] 4.09. SEO, SEO URL minor always 2018-08-20 12:51 2018-08-28 09:55
Reporter: sse Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: