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 2019-12-02 13:25
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: Patch for 6.1  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
MySQL 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:
6708 [OXID eShop (all versions)] 2.7. Customer info feature always 2017-10-11 16:38 2019-11-29 13:15
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
MySQL 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 2019-11-29 10:00
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
MySQL 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:
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
MySQL 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:
5524 [OXID eShop (all versions)] 6. ------ Setup ------- minor always 2013-11-21 16:16 2019-11-22 14:58
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: Patch for 6.1  
    Target Version: Patch for 6.1  
Theme: Not defined
Browser: All
PHP Version: Not defined
MySQL 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:
7051 [OXID eShop (all versions)] 1.01. Products (product, categories, manufacturer, promotions etc.) minor always 2019-11-11 08:50 2019-11-20 10:17
Reporter: ivoba 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
MySQL 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:
7052 [OXID eShop (all versions)] 4.01. Database handling minor always 2019-11-19 00:39 2019-11-19 22:44
Reporter: timwetter Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new 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
MySQL 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:
Additional Information:
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


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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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:
7030 [OXID eShop (all versions)] 1.02. Price calculations (discounts, coupons, additional costs etc.) minor always 2019-09-09 11:19 2019-10-14 08:59
Reporter: QA 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
MySQL Version: Not defined
Summary: Different coupon / discount calculations when item or category is assigned
Description: In case of unassigned items, the discount will be applied to the shopping cart.
3 x 9,95 = 29,85 minus 32,99% discount 9,85 = 20 EUR
If a category or article has been assigned to the discount, the discounted price is first applied to the article, rounded and then multiplied by the number.
9,95 less 32,99% discount = 6,67 EUR x 3 = 20,01 EUR
Here, the individual article should not be rounded, but rather the multiplication of the discounted price by the number of articles.

- es -
Tags:
Steps To Reproduce: 1. Create discount with and without article assigned (see attachment).
2. Put 3 articles in basket

-> Different discount calculations when item or category is assigned
Additional Information:
Attached Files: discount.JPG (78,935 bytes) 2019-09-09 11:19
https://bugs.oxid-esales.com/file_download.php?file_id=1761&type=bug
Discount_without_articles_assigned.JPG (131,706 bytes) 2019-09-09 11:19
https://bugs.oxid-esales.com/file_download.php?file_id=1762&type=bug
Discount_with_articles_assigned.JPG (126,670 bytes) 2019-09-09 11:19
https://bugs.oxid-esales.com/file_download.php?file_id=1763&type=bug
Notes
(0013017)
mgmtp   
2019-10-14 08:59   
Are there any possible fixes for this problem? Thx


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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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:
6138 [OXID eShop (all versions)] 4.12. Subshop handling minor always 2015-04-29 15:01 2019-09-13 14:27
Reporter: hendrikfreytag 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
MySQL 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?


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
MySQL 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:
6992 [OXID eShop (all versions)] 1. ----- eShop frontend ----- minor always 2019-06-06 13:18 2019-09-11 13:54
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
MySQL 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.


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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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:
7017 [OXID eShop (all versions)] 2.8. Service minor always 2019-08-08 12:56 2019-08-08 12:56
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
MySQL 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:
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
MySQL 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
MySQL 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:
7014 [OXID eShop (all versions)] 4.09. SEO, SEO URL major always 2019-07-30 12:31 2019-08-01 12:31
Reporter: s.sadowski 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: Other
Browser: Not defined
PHP Version: Not defined
MySQL 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:
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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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:
6888 [OXID eShop (all versions)] 4.01. Database handling minor always 2018-08-17 12:03 2019-06-07 16: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
MySQL 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]


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 2019-06-07 16:15
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
MySQL 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;


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 2019-06-07 16:10
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
MySQL 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.


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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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:
6822 [OXID eShop (all versions)] 2.3. Extensions (modules, themes) minor always 2018-04-27 16:18 2019-05-06 11:32
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
MySQL 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.


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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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
MySQL 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:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
MySQL Version: Not defined
Summary: Redirected to startpage when changing language on fake oxmore category
Description: If you are on the fake oxmore category page (index.php?cl=alist&cnid=oxmore) and you want to change the language, you will be redirected to the startpage.
You should stay on the oxmore page instead.
Tags: Category, oxmore, Redirect, SEO
Steps To Reproduce: - go to https://YOURDOMAIN.com/index.php?cl=alist&cnid=oxmore
- change the language
- you will be redirected to startpage, which is wrong
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6887 [OXID eShop (all versions)] 1.02. Price calculations (discounts, coupons, additional costs etc.) major always 2018-08-15 10:11 2018-08-15 14:47
Reporter: Marc Fuesslein Platform:  
Assigned To: OS:  
Priority: low 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
MySQL Version: Not defined
Summary: Deletion of an account by the user can make discount apply to all articles
Description: If you allow users to delete their accounts and have a discount that is only valid for one user, the discount will apply to all articles of the shop once that user deletes his account.

The obvious workaround for this is to never assign discounts to users directly and rather use user groups for that.

I don't have a good solution to fix the problem. Maybe disable the discount if there are no assigned users left after a user account is deleted?
Tags:
Steps To Reproduce: 1. Register a new account
2. Create a new discount with any discount value, assign the discount to the registered user
3. Allow users to delete their account in the shop settings
4. Login with the new user and delete the account
5. The discount is global now
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6818 [OXID eShop (all versions)] 4.04. Security critical always 2018-04-19 13:02 2018-08-14 11:07
Reporter: ambulong Platform:  
Assigned To: OS:  
Priority: urgent OS Version:  
Status: resolved Product Version: 6.0.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 4.10.8 / 5.3.8  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
MySQL Version: Not defined
Summary: It is possible to take over an access to user account
Description: It is possible to take over access of a user account by entering an e-mail address similar to an already existing e-mail address in the database when using the password reset function
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012444)
keywan.ghadami   
2018-04-19 13:07   
please see info on
https://oxidforge.org/en/security
and write a email directly to security@oxid-esales.com.
(0012445)
ambulong   
2018-04-19 13:20   
Got it, thanks


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6880 [OXID eShop (all versions)] 1.01. Products (product, categories, manufacturer, promotions etc.) major always 2018-08-10 10:45 2018-08-13 07:32
Reporter: d3 Platform:  
Assigned To: OS:  
Priority: urgent OS Version:  
Status: acknowledged Product Version: 4.10.8 / 5.3.8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
MySQL Version: Not defined
Summary: oxseo and oxseohistory entries will not deleted by deletetion of oxvendor and oxmanufacturer
Description: Reproduction:
1. manufacturer
go to admin/manufacturer -> select "Cabrinha" f.e. -> copy seo url from seo tab "en/By-Manufacturer/Cabrinha/"
delete manufacturer "Cabrinha"
Enter shopurl with seo url: domain.de/en/By-Manufacturer/Cabrinha/
an empty page will be displayed -> have to be an 404 error

open database an execute query:
SELECT * FROM `oxseo` WHERE oxseourl = 'en/By-Manufacturer/Cabrinha/';
an existing entry will be displayed

if the manufacturer was renamed, the oxseohistory entries remains.

2. vendor
go to admin/vendor -> select "www-true-fashion-com" f.e. -> copy seo url from seo tab "en/By-distributor/www-true-fashion-com/"
delete vendor "www-true-fashion-com"
Enter shopurl with seo url: domain.de/en/By-distributor/www-true-fashion-com/
an exception occurs: "vendor/oxid-esales/oxideshop-ce/source/Application/Controller/VendorListController.php] [line 446] [message Call to a member function getId() on boolean]"
 -> have to be an 404 error

open database an execute query:
SELECT * FROM `oxseo` WHERE oxseourl = 'en/By-distributor/www-true-fashion-com/';
an existing entry will be displayed

if the vendor was renamed, the oxseohistory entries remains.


best regards
Kristian
Tags: Database, Exception, Manufacturer, SEO, Vendor
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012569)
d3   
2018-08-10 10:46   
the behaviour is reproducable in 4.10.x/5.3.x as well in 6.1.0

Kristian
(0012571)
michael_keiluweit   
2018-08-13 07:32   
@dev: when closing or marking this one as resolved, please consider to elaborate 0006304 also.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6304 [OXID eShop (all versions)] 4.09. SEO, SEO URL major always 2016-01-02 23:56 2018-08-13 07:29
Reporter: Adrian.Kirchner 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: Not defined
MySQL Version: Not defined
Summary: oxseohistory is left untouched when deleting entities like oxArticle, oxCategory, oxContent, oxManufacturer, oxVendor
Description: The deletion of the entities oxArticle, oxCategory, oxContent, oxManufacturer and oxVendor triggers a call to the corresponding onDelete* method in the associated oxSeoEncoder* class. For all listed entity types the related tuples in oxseo and oxobject2seodata are deleted but the oxseohistory table is left untouched.
Tags: Solution Provided
Steps To Reproduce: - https://github.com/OXID-eSales/oxideshop_ce/blob/5dfebddcb24ed4c444a735d48258bb381b7c4e0d/source/application/models/oxseoencoderarticle.php#L642
- https://github.com/OXID-eSales/oxideshop_ce/blob/5dfebddcb24ed4c444a735d48258bb381b7c4e0d/source/application/models/oxseoencodercategory.php#L239
- https://github.com/OXID-eSales/oxideshop_ce/blob/5dfebddcb24ed4c444a735d48258bb381b7c4e0d/source/application/models/oxseoencodercontent.php#L109
- https://github.com/OXID-eSales/oxideshop_ce/blob/5dfebddcb24ed4c444a735d48258bb381b7c4e0d/source/application/models/oxseoencodermanufacturer.php#L140
- https://github.com/OXID-eSales/oxideshop_ce/blob/5dfebddcb24ed4c444a735d48258bb381b7c4e0d/source/application/models/oxseoencodervendor.php#L140
Additional Information: Recommlists and tags may need further treatment.
A pull request will follow
Attached Files:
Notes
(0011400)
Adrian.Kirchner   
2016-01-02 23:57   
PR: https://github.com/OXID-eSales/oxideshop_ce/pull/310
(0012570)
Adrian.Kirchner   
2018-08-13 02:26   
It seems like the referenced pr got already merged so this bug can be closed


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5746 [OXID eShop (all versions)] 2.3. Extensions (modules, themes) minor always 2014-04-29 15:41 2018-08-08 10:30
Reporter: aurimas.gladutis Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 4.6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: All
Browser: All
PHP Version: Not defined
MySQL Version: Not defined
Summary: Timestamp is not added for css and js files included from module
Description: Currently when including js or css file from module, you usually do it like this:
[{oxstyle include=$oViewConf->getModuleUrl('module','path/to/file.css')}]

Now getModuleUrl creates full path to file (including host http://host.com/) and both oxstyle and oxscript plugins checks whether included file starts with http (which it does), and if so - does not add any filetime to the end.
This is done so that filetime would not be added to files from other server, but the check itself is incorrect.

This check should check if the domain is actually different, not only if the full path is specified.
Tags: Solution Provided
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0011827)
alfredbez   
2016-10-07 11:06   
Pull Request: https://github.com/OXID-eSales/oxideshop_ce/pull/493


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6876 [OXID eShop (all versions)] 6. ------ Setup ------- trivial always 2018-08-07 10:36 2018-08-07 10:36
Reporter: michael_keiluweit Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: assigned 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
MySQL Version: Not defined
Summary: README is still < 6.
Description: The README file in the root directory of the source folder describes how to install the shop via FTP and contains broken links.
Tags:
Steps To Reproduce:
Additional Information: https://github.com/OXID-eSales/oxideshop/pull/24/
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6875 [OXID eShop (all versions)] 4.01. Database handling feature always 2018-08-06 14:48 2018-08-06 15:25
Reporter: timwetter Platform:  
Assigned To: OS:  
Priority: low 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
MySQL Version: Other
Summary: Primary key 32 bit long as Char(32) latain_
Description: Why don't you use Binary(16) to store md5?
This is only 16bit long and together with other indizes in OXID DB you
will save more then a half of required space in ROM and RAM!!!
And this also will make OXID faster.

Any comments to this?

Kind Regards!
Tim
Tags:
Steps To Reproduce:
Additional Information: mysql 5.x or mysql 8.x
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6586 [OXID eShop (all versions)] 4.01. Database handling minor always 2017-02-09 16:08 2018-07-27 16:13
Reporter: Paulius.Kupetis 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: All
MySQL Version: All
Summary: \oxBase::_update always returns true
Description: \oxBase::_update always returns true.
transforming object to boolean always gives true.

ALSO in V6 shop this is partly fixed - execute returns number, so 0 can be transformed to false other numbers to true.

BUT what this function intends to return?

Maybe it would be better to return if sql was successful or not.
not just if sql affected queries..

This affects some modules like ERP.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012543)
anton.fedurtsya   
2018-07-27 16:13   
Hello, looks like issue is fixed on 2017-03-28, now its eather true on success or DatabaseException on sql error.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6869 [OXID eShop (all versions)] 4.01. Database handling feature always 2018-07-26 15:43 2018-07-27 14:36
Reporter: anton.fedurtsya 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
MySQL Version: Not defined
Summary: Add support for --dry-run and --write-sql options
Description: This issue is moved from Github issues.

vendor/bin/oe-eshop-doctrine_migration migrations:migrate --dry-run

does not work

vendor/bin/doctrine-migrations migrations:migrate --dry-run \
--configuration source/migration/project_migrations.yml \
--db-configuration vendor/oxid-esales/oxideshop-doctrine-migration-wrapper/src/migrations-db.php

works fine
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:
6868 [OXID eShop (all versions)] 6. ------ Setup ------- feature always 2018-07-26 13:47 2018-07-27 09:12
Reporter: edvinas.aleksejonokas Platform:  
Assigned To: OS:  
Priority: low 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
MySQL Version: Not defined
Summary: Extract VfsFileStructureOperator.php into component
Description: This issue is moved from Github issues.

Extracting VfsFileStructureOperator.php might be beneficial for other components which inside the tests are already using VfsStream.

Source for the class to be extracted: https://github.com/OXID-eSales/oxideshop_composer_plugin/blob/c6c82ce2d715e7024cf044d77dda2ab1c9734c0a/src/Utilities/VfsFileStructureOperator.php

Possible ways to extract:

* Make separate component
* Integrate with testing_library
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:
6865 [OXID eShop (all versions)] 5. ------ UpdateApp / Update ------ minor always 2018-07-26 10:56 2018-07-26 15:03
Reporter: benjamin.joerger 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
MySQL Version: Not defined
Summary: Setup directory is not completely empty after running composer update
Description: This issue is moved from Github issues

BenjaminJoerger commented on Feb 21
There exists a regexp which avoids that setup files are not copied again to the source folder when running composer update. Saldy the regexp does not work correct.

Files in Setup/* are not copied
Folders and their content in Setup/ ARE copied
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:
6866 [OXID eShop (all versions)] 6. ------ Setup ------- feature always 2018-07-26 11:00 2018-07-26 13:37
Reporter: anton.fedurtsya 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
MySQL Version: Not defined
Summary: Run shop in different folder than "source".
Description: The issue is moved from github issues

proggeramlug commented on Feb 14 •
It should be possible to specify a different name than "source" for SHOP_SOURCE_DIRECTORY.

If a shop should run in a subfolder the folder name will differ from "source".
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:
6867 [OXID eShop (all versions)] 4.03. 3rd party libraries feature always 2018-07-26 11:03 2018-07-26 13:36
Reporter: anton.fedurtsya 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
MySQL Version: Not defined
Summary: Force answer for development version to rewrite theme/module
Description: This issue was moved from github issues.

stasiukaitis-saulius commented on Nov 14, 2016
It's a bit disturbing to have a question if update module/theme on each composer update. It would be better to have possibility to force to override or not all modules/themes.
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:
6860 [OXID eShop (all versions)] 1.05. Users major always 2018-07-23 11:08 2018-07-24 09:48
Reporter: ddpkts Platform:  
Assigned To: OS:  
Priority: low 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: Not defined
PHP Version: Not defined
MySQL Version: Not defined
Summary: Duplicate entry 'email@gmail.com-1' for key 'OXUSERNAME'
Description: Exception is thrown when user tries to change his/her email that already exists as a guest user. Frontend and Admin.
Tags:
Steps To Reproduce: Try to change user email to email that already exists as a guest user email.
Additional Information:
Attached Files: Firefox_Screenshot_2018-07-05T08-31-48.495Z.png (186,518 bytes) 2018-07-23 11:08
https://bugs.oxid-esales.com/file_download.php?file_id=1637&type=bug
Screenshot 2018-07-23 12.10.25.png (54,233 bytes) 2018-07-23 11:10
https://bugs.oxid-esales.com/file_download.php?file_id=1638&type=bug
Notes
(0012539)
ddpkts   
2018-07-23 11:10   
changing email address in admin


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6855 [OXID eShop (all versions)] 1.05. Users minor always 2018-07-13 16:28 2018-07-16 09:08
Reporter: henrik.steffen 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
MySQL Version: Not defined
Summary: Updating your login to an e-mail-adress which already has an existing user account fails without notice
Description: If you go to the "my account" section as a logged in user and try to update your billing-address including the e-mail-address, this will fail, if there already exists a user-account with that e-mail-address.
However, no error message will be displayed.

First, when you go to the edit billing-address page again, two messages are shown, which don't fit properly either.

Tags:
Steps To Reproduce: Go to https://demoshop.oxid-esales.com/community-edition/
Go to my account section
Login as user admin
Click edit billing address
Change e-mail-address to info@oxid-esales.com
You get back to my account overview, you still see old e-mail-address
Click on edit billing address again
You'll see two error messages:

Not possible to register info@oxid-esales.com. Maybe you have already registered?
Please enter a valid e-mail address


The error messages don't fit, because it is a valid e-mail-address, and because we are not trying to register info@oxid-esales.com, we are trying to change our e-mail-address.

Additional Information:
Attached Files:
Notes
(0012535)
QA   
2018-07-13 17:33   
The text mentions that the mail address is already registered. However, it should be showed right after the save button is pressed, not only when open the edit page again.
(0012536)
henrik.steffen   
2018-07-16 08:25   
A better text message would be:
Couldn't update your e-mail address to info@oxid-esales.com, because an account with this e-mail address already exists.
The second message "Please enter a valid e-mail address" could be removed in my opinion.
And yes, it should be displayed right after the save button is pressed please.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6854 [OXID eShop (all versions)] 1.02. Price calculations (discounts, coupons, additional costs etc.) critical always 2018-07-13 14:03 2018-07-13 14:10
Reporter: QA 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
MySQL Version: Not defined
Summary: Wrong voucher calculation - discount sharing between user's baskets
Description: In case of vouchers with the same number, it's possible to create a sharing-like behavior of the total discounts, which could lead to wrong basket calculation - even negative basket sums are possible!

The problem is the storing of the total discount, calculated while using a voucher with a percentage discount. The calculated total sum is stored in oxvouchers table. For any reason, it's possible that an user can use the same voucher as another user. Then he gets the pre-calculated discount, which clearly refers to another basket.

[sp]
Tags: Calculations, Discount, Voucher
Steps To Reproduce: 1) Create a voucherseries
OXDISCOUNTTYPE = percent
OXALLOWSAMESERIES = 0
OXALLOWOTHERSERIES = 0
OXALLOWUSEANOTHER = 0
OXCALCULATEONCE = 0

2) Assign a category to the voucherseries.
3) Create one voucher from the series.
4) Open browser A and login to shop with user A.
5) Add an article from the assigned category to your basket.
6) Input the voucher code.
Discount should be calculated the right way.
7) Open browser B and login to shop with user B.
8) Add another article from the assigned category to your basket.
9) Login to you shop's database.
10) Update the value oxvouchers.OXRESERVED to a timestamp older than 3 hours (in standard).
Explanation: The reservation time of the used voucher has to be run out. With standard settings, a voucher is reserved for 3 hours. So you may wait that time, but it's easier to modify the oxvouchers.OXRESERVED value. Just change it to a value thats more than 3 hours back in past, so subtract a number > 10800.
11) Finish your order.
12) Go back to browser A.
13) Update your basket.
Now you should see the total discount from user B.
Additional Information: The scenario a little bit more technical:
1) User A inputs voucher number.
2) Voucher X gets reserved by inserting a timestamp to oxvouchers.OXRESERVED.
3) User A doesn't do anything and leaves his basket as it is for about 3 hours (in standard).
4) oxvouchers.OXRESERVED from voucher X is now more than 3 hours old, so voucher X isn't reserved anymore.
5) Now User B inputs the voucher number and since voucher X isn't reserved anymore, user B re-reserves voucher X for his basket.
6) User B finishes his order.
7) At this point the OXORDERID, OXUSERID and OXDISCOUNT were inserted into the oxvouchers table.
8) User A comes back and updates his basket.
9) Then the problem starts to begin: Even though voucher X isn't reserved anymore by user A, this voucher is used for calculation.
10) Unfortunately the calculation function read out OXDISCOUNT from the database and adds it to user A's basket.
Problem 1.1: Wrong total discount value is used for user A.
Problem 1.2: If basket sum from user A is less than discount from user B, which is stored in oxvouchers.OXDISCOUNT, basket sum could get under 0,00.
Problem 2: Same voucher X is used by two customers.
11) User A finishes his order.
12) OXORDERID and OXUSERID from voucher X is overwritten with the new values from user A.

(My guess is, that the oxvouchers.OXID from voucher X is stored in the session from user A.)
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6562 [OXID eShop (all versions)] 1.02. Price calculations (discounts, coupons, additional costs etc.) minor always 2016-12-08 15:18 2018-07-13 14:08
Reporter: mksschroeder Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 4.10.0 / 5.3.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: All
Browser: All
PHP Version: 5.6
MySQL Version: Not defined
Summary: Wrong Voucher Calculation - session basket mixing
Description: This bug has been already reported, but has been closed as not reproducable(https://bugs.oxid-esales.com/print_bug_page.php?bug_id=6213)

It only appears if the voucher calculation is set on percentual and categories or articles are assigned to it.

I could solve the problem by passing the basket object to the oxvoucher model before calculating the voucherdiscount.

I added a function setRealBasket($oBasket) in oxvoucher to set the basket.

In oxbasket::_calcVoucherDiscount() i set the basket before calling $oVoucher->getDiscountValue($dPrice)

In oxvoucher->_getSessionBasketItems() i use this basket for calculation.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: oxordervoucherexception.jpg (534,397 bytes) 2016-12-09 10:49
https://bugs.oxid-esales.com/file_download.php?file_id=1483&type=bug
voucherdebug.jpg (80,456 bytes) 2016-12-09 11:59
https://bugs.oxid-esales.com/file_download.php?file_id=1484&type=bug
Notes
(0011894)
mksschroeder   
2016-12-08 17:10   
(Last edited: 2016-12-08 18:32)
Update: Problem is not solved by passing the basket object to oxvoucher.
We still have orders with the applied discount of an previous order using the same voucher code.

Another series with percentage and assigned articles seems to be calculated correctly. (This series uses unique voucher codes)

(0011895)
QA   
2016-12-09 10:16   
Please provide Steps to Reproduce (hopefully with screenshots) to help us reproduce the issue and thereby analyse it.
(0011896)
mksschroeder   
2016-12-09 10:58   
(Last edited: 2016-12-09 11:00)
I uploaded a screenshots of the orders with the assigned voucher. The voucher was set to 5% for an assigned group of articles only. The voucher code is the same for the voucherseries. (no unique vouchercodes - this is important)

The red highlited parts are orders with the same voucherdiscount amount, but with wrong calculation for the newer one. - so it seems that the amount is taken by the older order/session ??

We stopped this promotion, because it caused too much trouble, so iam nnot able to produce the error in live situtation. we will try to reproduce this bug in dev and give feedback.

(0011897)
mksschroeder   
2016-12-09 12:00   
(Last edited: 2016-12-09 12:16)
I´ve been able to reproduce it in stage env.

1. Create voucherseries with percentage discount
(OXALLOWSAMESERIES=0, OXALLOWOTHERSERIES=0, OXMINIMUMVALUE=0, OXCALCULATEONCE=0)
2. assign a bunch of articles to it
3. Create vouchers with a single voucher code (e.g. "08154711")
4. open several sessions signin with mutltiple accounts
5. use voucher code to buy articles (assigned to voucherseries)

in my case i left some session with voucher and didn´t finish those orders

As you can see in provided screenshot (voucherdebug.jpg) it took 5 orders till the calculation was wrong.

(0011898)
QA   
2016-12-12 11:04   
The issue is not reproducable from our end. Kindly try to reproduce the issue in our Reference sytem : http://demoshop.oxid-esales.com/professional-edition/
(0011987)
d3   
2017-03-01 15:54   
(Last edited: 2017-03-01 16:05)
This part is the same:
1. Create voucherseries with percentage discount
(OXALLOWSAMESERIES=0, OXALLOWOTHERSERIES=0, OXMINIMUMVALUE=0, OXCALCULATEONCE=0)
2. assign a bunch of articles to it
3. Create vouchers with a single voucher code (e.g. "08154711")


The session.gc_maxlifetime should be higher than standard iVoucherTimeout (oxvoucher::_getVoucherTimeout() standard 3*3600 seconds)

2 customers are necessary:
1. customer A assign voucher to basket -> oxreserved will be set on 3*3600 seconds = 3 hours -> Timestamp #1
2. customer A keeps the session alive for 3 or more hours.
3. customer B assigns the same voucher code to the basket 3 hours after {Timestamp #1}.
   As a result the same oxvouchers__oxid will be assigned -> Timestamp #2
4. customer B finishes the order process (oxorderid, oxuserid and oxdiscount will set!)
5. customer A refreshes the basket after {Timestamp #2} (in step 1 ala cart :D ) and get the oxvouchers__oxdiscount from customer B's order.
5. customer A fineshes the order process and saves the discount value from the already used voucher

Hint #1: this is not reproducable in demoshop.oxid-esales.com because of the hourly reset
Hint #2: set the oxreserved field in oxvouchers at the oxvoucher from customer A to a lower value or wait 3 hours ;).

KH


edit:
possible solution in oxvoucher::checkBasketVoucherAvailability():
      if("0000-00-00" != $this->oxvouchers__oxdateused->value || false == empty($this->oxvouchers__oxorderid->oxvalue)) {
            $oEx = oxNew( 'oxVoucherException' );
            $oEx->setMessage('Do not use expired vouchers');
            $oEx->setVoucherNr($this->oxvouchers__oxvouchernr->value);
            throw $oEx;
        }



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 2018-06-21 10:56
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
MySQL 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


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6080 [OXID eShop (all versions)] 4.06. Language and translations major always 2015-03-11 11:23 2018-06-21 10:56
Reporter: hendrikfreytag Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 4.9.3 / 5.2.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: All
Browser: All
PHP Version: any
MySQL Version: any
Summary: Subshop language destroys language handling
Description: If you create a subshop before you add languages and then add language in subshop in different order than in supershop it destroys language handling.
Tags: EE, Languages, Subshops
Steps To Reproduce: - Create subshop inherit everything
- First add language french in subshop
- Then add language polish in supershop
- Then add language french in supershop
- update views
- go to an article in supershop
- copy description to polish and french
- try to change description of french or polish
- french description will not be saved and polish will be used
Additional Information:
Attached Files: Main_ULocales.ods.zip (41,950 bytes) 2015-04-14 12:34
https://bugs.oxid-esales.com/file_download.php?file_id=1365&type=bug
Notes
(0010776)
hendrikfreytag   
2015-03-11 11:26   
If you add polish after that in subshop, polish description will be saved as french and french description will be saved as polish.
(0010777)
QA   
2015-03-11 12:00   
Can reproduce.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6081 [OXID eShop (all versions)] 4.06. Language and translations major always 2015-03-11 11:28 2018-06-21 10:55
Reporter: simon_stark Platform:  
Assigned To: OS:  
Priority: urgent OS Version:  
Status: assigned Product Version: 4.7.13 / 5.0.13  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: All
Browser: All
PHP Version: any
MySQL Version: any
Summary: Views get broken when Language base IDs of specific Languages deviate in Subshops
Description: Example:

Parent Shop has the following Languages:

ID 0 - de - German
ID 1 - en - English
ID 2 - fr - French
ID 3 - af - Afrikaans

a Subshop has the following Languages:
ID 0 - de - German
ID 1 - en - English
ID 2 - af - Afrikaans


in Subshop, French text is shown instead of Afrikaans text.

This is because the views of the subshop is "overwritten" with the (lingually incorrect) view of the parent shop.


Tags:
Steps To Reproduce: 1. Start with a fresh OXID EE.
2. Create Languages as described above.
3. Create a Subshop that inherits everything from the Parent shop.
4. Modify the Languages of your Subshop as described above.
5. Write some mockup French Article descriptions, CMS pages, payment descriptions etc. in parent shop
6. regenerate Views via shop backend.
7. Navigate to subshop, change language to Afrikaans.
8. Enjoy your French text.
Additional Information:
Attached Files:
Notes
(0010778)
QA   
2015-03-11 12:03   
(Last edited: 2015-03-18 09:33)
Tricky to reproduce in current Version because of 0006080... Inserted the Version in which this was reported originally instead.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2423 [OXID eShop (all versions)] 4.05. Performance major always 2011-01-20 10:52 2018-06-14 15:21
Reporter: arvydas_vapsva Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 4.4.5 revision 31315  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Azure
Browser: All
PHP Version: Not defined
MySQL Version: Not defined
Summary: oxArticle::getStockCheckQuery() problem
Description: When blUseStock ON, blVariantParentBuyable OFF oxArticle::getStockCheckQuery() builds SQL subquery which slows down product search
Tags: MySQL, Performance, Products, SQL
Steps To Reproduce: Create shop with huge amount of product + variants (50k), and go to search
Additional Information:
Attached Files: screenshot01.png (122,413 bytes) 2017-01-24 12:49
https://bugs.oxid-esales.com/file_download.php?file_id=1490&type=bug
screenshot01-2.PNG (23,253 bytes) 2018-06-14 15:21
https://bugs.oxid-esales.com/file_download.php?file_id=1633&type=bug
Notes
(0003998)
arvydas_vapsva   
2011-01-20 11:06   
(Last edited: 2011-01-20 11:07)
Solution:
- eliminate subquery from oxArticle::getStockCheckQuery();
- change oxstockcount calculation:
  
    in case any variant has oxstockflag "1"/"4"/"3": oxstockcount = 9999;
    in case all variants has oxstockflag "2": oxstockcount count must be preciselly calculated and monitored;

(0008404)
mark   
2013-02-13 08:49   
Hi Arvydas,

will this be fixed in 5.0.4?

best regards, Mark
(0011944)
wmdk_jozuercher   
2017-01-24 12:40   
Hi Arvydas,

when will this Error be fixed? Is there some kind of schedule for this Issue?

Sincerly,
Jan-Ole Zürcher
(0011948)
wmdk_jozuercher   
2017-01-25 13:49   
Hi,

some Kind of Update for our customer?

Sincerly,
Jan-Ole Zürcher
(0011983)
wmdk_jozuercher   
2017-02-27 17:08   
Someone fixing this error? Locks like no one cares about this Fix.
(0012510)
wmdk_dkussin   
2018-06-14 15:21   
Leider musste ich soeben feststellen, dass der Bug auch in OXID PE 6.0.2 nicht behoben wurde, so dass weiterhin der Workaround von arvydas_vapsva eingesetzt werden muss/kann.

Hier ein Update für OXID 6:
In der /vendor/oxid-esales/oxideshop-ce/source/Application/Model/Article.php die Funktion getStockCheckQuery() suchen (ca. Zeile 599) und den Inhalt der Funktion gegen return ""; tauschen (vgl. Screenshot).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6842 [OXID eShop (all versions)] 1.02. Price calculations (discounts, coupons, additional costs etc.) major always 2018-06-11 10:55 2018-06-12 10:42
Reporter: leofonic Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: acknowledged Product Version: 6.0.2  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
MySQL Version: Not defined
Summary: Delivery Set is selectable although no article matches rule
Description: Logic for choosing selectable shipping set by weight takes total weight into account wheras logic for rule takes only single weight.
Tags:
Steps To Reproduce: Create shipping method and rule.

Settings for rule:
- weight from 10 to 999 kg
- surcharge 10 €
- each product or each different product

Put 2 different articles 5kg each in basket. New shipping method is selectable and surcharge is zero.
Additional Information:
Attached Files: Shipping Cost Rule.JPG (51,853 bytes) 2018-06-12 09:15
https://bugs.oxid-esales.com/file_download.php?file_id=1629&type=bug
Shipping Method.JPG (53,128 bytes) 2018-06-12 09:15
https://bugs.oxid-esales.com/file_download.php?file_id=1630&type=bug
Step3.JPG (93,662 bytes) 2018-06-12 09:15
https://bugs.oxid-esales.com/file_download.php?file_id=1631&type=bug
Step4.JPG (92,865 bytes) 2018-06-12 09:15
https://bugs.oxid-esales.com/file_download.php?file_id=1632&type=bug
Notes
(0012503)
QA   
2018-06-12 09:15   
The behavior could not be reproduced.
For two articles with a weight of 5kg each, the shipping method "Shipping from 10 KG surcharge 10 EUR" was also displayed and when selected, the surcharge was also calculated.

not reproducible (see attached files)
(0012504)
leofonic   
2018-06-12 09:19   
(Last edited: 2018-06-12 09:19)
In shipping cost rule select:
- each product or each different product

(0012506)
QA   
2018-06-12 09:43   
If you choose "each product or each different product" for the shipping cost rule, the rule cannot apply, as each article weighs 5kg and the rule applies to 10kg.
Usually set the weight in the rule down to 5kg, then also per article 10 EUR thus 20 EUR are calculated.
(0012508)
leofonic   
2018-06-12 09:54   
"If you choose "each product or each different product" for the shipping cost rule, the rule cannot apply"

Yes the rule cannot apply and thus the shipping method should not be selectable, but it is, and the customer can order for zero shipping costs if total weight reaches limit you have set for each article, regardless what the value is. If you have a shipping method with a single rule attached that has a surcharge set, surcharge should NEVER be zero in any case.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6839 [OXID eShop (all versions)] 6. ------ Setup ------- feature always 2018-06-07 15:12 2018-06-08 10:44
Reporter: Helmut L. Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.0.2  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
MySQL Version: Not defined
Summary: source-path parameter not fully working
Description: If you set a source-path in the composer.json file, the shop is installed into that folder instead of the "source" folder. This already works, but there are some files in the shop in which the folder name is explicitly set to "source" despite the shop being installed into another folder.
This results in a fatal error when you try to open the shop.
Tags:
Steps To Reproduce: 1. run composer in an empty directory to get a composer.json file:
composer create-project --no-dev --no-install --remove-vcs oxid-esales/oxideshop-project . dev-b-6.0-ee

2. set the source path:
composer config extra.oxideshop.source-path htdocs

3. install the shop:
composer install --no-dev

4. try to open the shop
Additional Information: So far I've found this hard coded folder name in two files:
oxid-esales/oxideshop-ce/source/bootstrap.php, line 11
oxideshop-facts/src/Config/ConfigFile.php, line 58
Attached Files:
Notes
(0012496)
QA   
2018-06-07 16:10   
The name of the source directory inside the shop directory is mandatory.
(0012497)
Helmut L.   
2018-06-07 17:28   
If the folder name must be "source" why was the source-path parameter added to change it?
(0012498)
QA   
2018-06-07 17:52   
Where did you get the parameter from?
(0012499)
Helmut L.   
2018-06-07 18:01   
In the abstract package installer are constants for the possible options that can be set through the composer.json file.

/vendor/oxid-esales/oxideshop-composer-plugin/src/Installer/Package/AbstractPackageInstaller.php, line 30:

    /** Used to decide what the shop source directory is. */
    const EXTRA_PARAMETER_SOURCE_PATH = 'source-path';
(0012501)
QA   
2018-06-08 10:37   
It is still in discussion, but it is currently not intended to change the source directory via this parameter.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6838 [OXID eShop (all versions)] 4.07. Source code, Test minor always 2018-06-07 14:27 2018-06-08 09:59
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
MySQL Version: Not defined
Summary: Exception handling is not PHP 7.x compatible
Description: The exception handler was NOT converted to be PHP 7.x and PHP 5.x compatible.

If an PHP Error is thrown (for example a TypeError) PHP creates a fatal error, because of the incompatible type in the exception handler.

For examples take look at http://php.net/manual/en/migration70.incompatible.php#migration70.incompatible

A screenshot of the resulting error (xdebug) error message is attached.
Tags: Exception, fatal, PHP
Steps To Reproduce:
Additional Information:
Attached Files: Screenshot at Jun 07 13-20-07.png (90,864 bytes) 2018-06-07 14:27
https://bugs.oxid-esales.com/file_download.php?file_id=1627&type=bug
Notes
(0012500)
robert blank   
2018-06-08 09:59   
This has already been fixed.
See https://github.com/OXID-eSales/oxideshop_ce/commit/b9ab795f5df3534a6e11173a1d2feb15785892ae
The fix will be rolled out with the next minor release.

You could ask product management to consider backporting the fix to the next patch release.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6840 [OXID eShop (all versions)] 2.1. Master Settings minor always 2018-06-08 09:15 2018-06-08 09:18
Reporter: QA Platform:  
Assigned To: OS:  
Priority: low 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
MySQL Version: Not defined
Summary: AutoSearchOnCat has no functionality
Description: In admin panel, go to Master Settings > Core Settings > Settings > Search. There you will find the option 'Start Search automatically if User selects a Category'. I have absolutely no clue what this option is supposed to do. I checked the code and can't find any part where it's actually being used in a functional way (only translations and config).

[sp]
Tags: Admin, Configuration Options, Search
Steps To Reproduce: Search in source code for 'AutoSearchOnCat'.
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6836 [OXID eShop (all versions)] 6. ------ Setup ------- minor always 2018-06-04 18:41 2018-06-07 09:37
Reporter: Helmut L. Platform:  
Assigned To: OS:  
Priority: low 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
MySQL Version: Not defined
Summary: duplicate Demo images
Description: Almost all images in the oxideshop-demodata-ce, -pe and -ee modules are identical. Since for a shop installation of a EE all three demo data modules are a requirement you end with downloading the same images three times.

Just remove the duplicates from the -pe and -ee modules.
Tags: Demo Data
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012494)
Helmut L.   
2018-06-07 09:37   
I just noticed that the demodata images are also present in the oxideshop-ce module. Which means if you're installing an EE you currently end up with the same images four times in your vendor folder.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6835 [OXID eShop (all versions)] 1.05. Users feature always 2018-06-03 07:07 2018-06-04 10:53
Reporter: flexisticker Platform:  
Assigned To: OS:  
Priority: normal 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
MySQL Version: Not defined
Summary: DSGVO - Datenauskunft für Kunden
Description: Hello,

the DSGVO writes before the customer a disclosure of the data stored about you must be able to request.
It would make sense to add such a function directly in the shop in the My Account area.

After approval by an ADMIN, the shop could output all database entries in the form of a simple PDF.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012490)
QA   
2018-06-04 10:53   
Please post bug tickets in english. Thank you.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6831 [OXID eShop (all versions)] 4.01. Database handling feature always 2018-05-25 08:51 2018-05-25 17:00
Reporter: mkr73 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
MySQL Version: Not defined
Summary: Increase Column size for Text columns in oxcontents
Description: In relation with the VisualCMS module, i run a size store problem.
With the new DSGVO (over 65535 bytes big) a can not store the whole Text.
I have to split the the Text and include theme per Smarty code ([{oxcontent ident="trackingoptout"}])

Is it possible to use MEDIUMTEXT or LONGTEXT instead of TEXT type?
Tags:
Steps To Reproduce: Add a Text bigger than 65535 bytes long, and store them in the VisualCMS or CMS-Pages menu.
Only the first 65535 bytes will be stored. In VisualCMS the whole syntax will be damaged.
Additional Information:
Attached Files:
Notes
(0012484)
QA   
2018-05-25 17:00   
I changed the database field type to MEDIUMTEXT and did not encounter any problems. Maybe the table allocates more storage, but the performance didn't seem to get worse.

Think you can change it on you own, but - like always as you change something - I recommend sufficient testing.

[sp]


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6516 [OXID eShop (all versions)] 1.01. Products (product, categories, manufacturer, promotions etc.) minor always 2016-09-30 18:28 2018-05-11 10:28
Reporter: keywan.ghadami Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version: 6.0.3  
    Target Version:  
Theme: Not defined
Browser: All
PHP Version: Not defined
MySQL Version: Not defined
Summary: When a country has the option "Do not bill VAT only if provided valid VAT I", the shop shows "* incl. VAT, plus shipping" anyway
Description: A customer registers with a country, which has the option "Do not bill VAT only if provided valid VAT ID". But the shops displays still "* incl. VAT, plus shipping" in the footer.

The shop has to display "exclusive shipping" instead of "incl. VAT", because there is no VAT and the shipping isn't in the article price included.
Tags: Solution Provided
Steps To Reproduce: 1. goto admin
2. activate a county, set the option "Do not bill VAT only if provided valid VAT ID" to true.
3. goto frontend
4. register a new customer with the land from step 2. with a valid vatid
5. have a look to the footer, the shop will still display "* incl. VAT, plus shipping", because the method oxUBase::isVatIncluded() doesn't check the vatid /vatidstatus of that user and therefore not if the user doesn't need to pay the VAT.
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6826 [OXID eShop (all versions)] 1.02. Price calculations (discounts, coupons, additional costs etc.) minor always 2018-05-02 16:08 2018-05-03 18:05
Reporter: henrik.steffen Platform:  
Assigned To: OS:  
Priority: low 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
MySQL Version: Not defined
Summary: One can choose wrapping for download products on basket page
Description: Doesn't really make sense, does it?
Tags:
Steps To Reproduce: Go to https://demoshop.oxid-esales.com/community-edition/ and choose the download product
https://demoshop.oxid-esales.com/community-edition/Downloads/Online-Shops-mit-OXID-eShop.html

Add to cart, and proceed to basket page.... add wrapping here...
Additional Information:
Attached Files: Bildschirmfoto 2018-05-02 um 16.07.31.png (347,883 bytes) 2018-05-02 16:08
https://bugs.oxid-esales.com/file_download.php?file_id=1625&type=bug
Notes
(0012472)
QA   
2018-05-03 18:04   
Wrapping possible, also if article is set as a "Intangible Product".


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6823 [OXID eShop (all versions)] 4.01. Database handling major always 2018-05-01 19:23 2018-05-03 15:51
Reporter: smxsm 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: 7.0
MySQL Version: 5.7
Summary: Migrations broken
Description: It looks like the migration functionality is broken in 6.0.2., no matter what migration (CE, EE, PE, PR) is executed, it always leads to a fatal error:

PHP Fatal error: Uncaught Doctrine\DBAL\Driver\Mysqli\MysqliException: Unsupported option '1002' with value 'SET @@SESSION.sql_mode='''
in ... /vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/Mysqli/MysqliConnection.php:237

It looks like this commit is responsible for the bug: https://github.com/OXID-eSales/oxideshop-doctrine-migration-wrapper/commit/cc9d230b8098c5ea53e4251e1b7951df565bee3b
Tags: doctrine, error, fatal, migration
Steps To Reproduce: Just call e.g.
./vendor/bin/oe-eshop-db_migrate migrations:migrate EE

The migrations will not run, but a fatal error will be reported in error_log.txt

Additional Information:
Attached Files:
Notes
(0012468)
QA   
2018-05-03 11:21   
Not reproducible:
Tested 6.0.2 CE > PE > EE

Maybe wrong paramater. It should look like this (no edition at the end):
vendor/bin/oe-eshop-db_migrate migrations:migrate
(0012469)
smxsm   
2018-05-03 14:35   
Makes no difference, even without parameter the migrations give me fatal errors, also if I set an environment parameter "MIGRATION_SUITE" as explained here: https://docs.oxid-esales.com/developer/en/6.0/oxid_components/migrations.html
(0012470)
QA   
2018-05-03 15:51   
Reproducable when using mysqli instead of pdo_mysql as database type.

Steps to reproduce:
config.inc.php: $this->dbType = 'mysqli'
./vendor/bin/oe-eshop-db_migrate migrations:migrate

Loading configuration from command option: /var/www/html/e602/vendor/oxid-esales/oxideshop-facts/src/Config/../../../../../vendor/oxid-esales/oxideshop-ee/migration/migrations.yml
PHP Fatal error: Uncaught Doctrine\DBAL\Driver\Mysqli\MysqliException: Unsupported option '1002' with value 'SET @@SESSION.sql_mode=''' in /var/www/html/e602/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/Mysqli/MysqliConnection.php:237
Stack trace:
#0 /var/www/html/e602/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/Mysqli/MysqliConnection.php(66): Doctrine\DBAL\Driver\Mysqli\MysqliConnection->setDriverOptions(Array)
#1 /var/www/html/e602/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/Mysqli/Driver.php(36): Doctrine\DBAL\Driver\Mysqli\MysqliConnection->__construct(Array, 'root', 'root', Array)
#2 /var/www/html/e602/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(360): Doctrine\DBAL\Driver\Mysqli\Driver->connect(Array, 'root', 'root', Array)
#3 /var/www/html/e602/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(429): Doctrine\DBAL\Connection->connect()
#4 /var/www/html/e602/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(389): Doctrine\DBAL\Connection->getDatabasePlatformVersion()
#5 /var/www/html/e602/vendor/do in /var/www/html/e602/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php on line 115
(0012471)
smxsm   
2018-05-03 15:51   
We solved the mystery in the skype channel - since the project is a migration, we somehow ended up with

$this->dbType = 'mysqli';

in config.inc.php - if I change that to

$this->dbType = 'pdo_mysql';

the migrations are running again :)
Thanks @Michael Keiluweit!


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6479 [OXID eShop (all versions)] 1. ----- eShop frontend ----- minor always 2016-08-17 08:49 2018-04-27 13:12
Reporter: keywan.ghadami Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 4.10.2 / 5.3.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.0.3  
    Target Version:  
Theme: Flow
Browser: All
PHP Version: Not defined
MySQL Version: Not defined
Summary: No oxOutOfStockException Error message returned within details.tpl when oxstockflag=2 (aka 'If out of Stock, offline')
Description: If an article runs out of stock and has oxstockflag set to 2 (aka 'If out of Stock, offline'), no stock error message is thrown within details.tpl.

There are two cases that do not work:
1. Article is totally out of stock -> nothing will be added to basket, and no message
What i expect: A Message will be shown in the Popup/Layer
2. Less Articles are available the requested -> only the available quantity will be added to basket but no feedback is shown (no messages, and no popup)
What i expect: Normal Popup/Layer will be opened but with a Message
Tags:
Steps To Reproduce: - go to demoshop
- in admin area change one article to respect the stock ('If out of Stock, offline')
- go to frontend,
- clear cart if not empty
- go to detailpage of that article
- add more then available
>> No message
Additional Information: the destination of the error message is 'popup' but no popup is shown.
Attached Files:
Notes
(0011744)
QA   
2016-08-17 18:01   
When an article with Stock as 10 is added to the basket with quantity 15 from the detailspage, only 10 gets added to the basket. The functionality is correct but the user is not informed whatsoever about why the quantity was changed from 15 to 10.
(0012284)
anton.fedurtsya   
2017-11-22 17:55   
Please check PR54 for possible solution


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4924 [OXID eShop (all versions)] 1.03. Basket, checkout process major always 2013-02-12 16:54 2018-04-20 09:29
Reporter: FibreFoX Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: resolved Product Version: 4.7.3 / 5.0.3 revision 54408  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.0.3  
    Target Version:  
Theme: Azure
Browser: All
PHP Version: Not defined
MySQL Version: Not defined
Summary: Can't change e-mail-adress when ordering wihout account
Description: When I'm on the last step of the ordering process and chose NOT to create an account, I will be displayed my E-mail address. Thats okay, thats what i want ... but in the case i mistyped my mail-adress, i am thinking of clicking on "change" ahead my billing adress, i just can change anything but NOT that i want optin to newsletter NOR my email-adress.
Tags: Basket, UX
Steps To Reproduce: 1. Put anything into the basket
2. In checkout, choose "Purchase without registration"
3. Insert some payment options
4. In order overview step, click "change" above "billing adress"
Additional Information: I think this is a huge usability-problem, tested with current CE-demoshop
Attached Files:
Notes
(0010461)
florian.auer   
2014-12-15 16:05   
Improved English text a little bit to make it easier for everyone to understand what this is about.
(0011173)
martinwegele   
2015-08-24 09:39   
This comment might explain the current behaviour: https://bugs.oxid-esales.com/view.php?id=1247#c1557
(0012207)
FibreFoX   
2017-08-14 09:56   
Any progress on this issue?
(0012447)
anton.fedurtsya   
2018-04-20 09:29   
Hello, the issue is fixed and will be available in next compilation.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6813 [OXID eShop (all versions)] 2.3. Extensions (modules, themes) minor always 2018-03-29 14:33 2018-04-04 11:05
Reporter: t.terhaar@laudert.com Platform:  
Assigned To: OS:  
Priority: low 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: 5.5
MySQL Version: Not defined
Summary: oxModuleInstaller::_filterModuleArray() compares path with id
Description: The problem appears for modules with an ID that doesn't match the pattern „vendor prefix + module root directory name“ (as recommended in the OXID Docs).
For these modules the function _filterModuleArray() which will be triggered in _removeNotUsedExtensions() doesn't work as expected. By mistake in the function the module path will be compared with the module id. Because of that the extensions won't be removed properly.

If you change the second parameter from „$oModule->getId()“ to „$oModule->getModulePath()“ in line 535, the extensions of these modules will be removed as expected.
Tags: Module, Solution Provided
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012431)
QA   
2018-03-29 16:21   
Thank you for your report, but provided information in bugtracker always has to be in english. Please translate your issue report.
(0012432)
t.terhaar@laudert.com   
2018-03-29 16:38   
The problem appears for modules with an ID that doesn't match the pattern „vendor prefix + module root directory name“ (as recommended in the OXID Docs).
For these modules the function _filterModuleArray() which will be triggered in _removeNotUsedExtensions() doesn't work as expected. By mistake in the function the module path will be compared with the module id. Because of that the extensions won't be removed properly.

If you change the second parameter from „$oModule->getId()“ to „$oModule->getModulePath()“ in line 535, the extensions of these modules will be removed as expected.
(0012433)
QA   
2018-04-03 09:56   
I've updated the information directly in the description of the issue. Also updated "summary".
(0012434)
QA   
2018-04-04 11:05   
In OXID eShop 6 it's ModuleExtensionsCleaner::cleanExtensions() which calls the Method filterExtensionsByModuleId().


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6814 [OXID eShop (all versions)] 5. ------ UpdateApp / Update ------ minor always 2018-04-03 15:41 2018-04-04 09:25
Reporter: mikkelfilla Platform:  
Assigned To: OS:  
Priority: low 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
MySQL Version: Not defined
Summary: Update documentation link links to 5.3 Version
Description: The information about a new update (master settings -> core settings -> License) does have a link which links to the documenation for v5.3:
http://www.oxid-esales.com/de/support-services/dokumentation-und-hilfe/oxid-eshop/installation/oxid-eshop-aktualisieren/update-vorbereiten.html

Could be found here:
source/Application/views/admin/de/lang.php
Key = VERSION_UPDATE_LINK
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:
6176 [OXID eShop (all versions)] 1.02. Price calculations (discounts, coupons, additional costs etc.) minor always 2015-06-22 12:01 2018-03-29 15:42
Reporter: Kovalsky Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 4.9.3 / 5.2.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: 5.3
MySQL Version: Not defined
Summary: Discounts on Article level don't display correctly
Description: Discounts with no categorys/article assignment will be displayed in basket summary. If you assign this discount one article, discount will be not displayed in basket summary.

$oxcmp_basket->getDiscounts() = NULL
$oxcmp_basket->getTotalDiscountSum() = float(0)
Tags:
Steps To Reproduce: For Example Article 1203 in demoshop - add to basket
In basket you dont see discount in summary.
Now remove article assigment in shop-admin - discounts and you see discount information in basket summary.
Additional Information:
Attached Files: screen6176.png (48,586 bytes) 2015-06-25 15:28
https://bugs.oxid-esales.com/file_download.php?file_id=1377&type=bug
Notes
(0011061)
QA   
2015-06-25 15:30   
(Last edited: 2015-06-25 15:31)
I attached a screenshot to clarify which discount information is meant.
The discount will be displayed when the following requirements are given:

quantitiy | assigned | shown in basket
    1     |     1    |       0
    1     |     0    |       1
    0     |     1    |       0
    0     |     0    |       0


(assigned to an article or category)

(0011062)
bjoerk   
2015-06-25 16:38   
Discounts are only shown if the discount is _not_ assigned to a product or category.
If the discount is assigned the discount-value is not shown in the basket.

Would be nice to have a mechanism to display the discount-sum if there is an assignment to specific products or categories which is more usual imho
(0012430)
gerldental   
2018-03-29 15:42   
The reason ist probably that's the oxbasket::_aItemDiscounts has an initial value = array() thats never changes.

Array merging in oxbasket::getDiscounts(), Z. 2158:

...
return array_merge($this->_aItemDiscounts, $this->_aDiscounts);

works only if basket discount exists. Array with article discounts is always empty.

Seems to be - it was forgotten to save article discounts in oxbasket::_calcItemsPrice() method.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6783 [OXID eShop (all versions)] 1.01. Products (product, categories, manufacturer, promotions etc.) minor always 2018-01-31 21:33 2018-03-23 09:23
Reporter: Alpha-Sys 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.0.2  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
MySQL Version: Not defined
Summary: getManufacturerForSlider uses wrong setting
Description: In the function getManufacturerForSlider the setting 'bl_perfLoadAktion' is checked. But this is the wrong setting.
It should be "bl_perfLoadManufacturerTree" instead.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012373)
Alpha-Sys   
2018-01-31 21:41   
See pull request https://github.com/OXID-eSales/oxideshop_ce/pull/625
(0012428)
anton.fedurtsya   
2018-03-23 09:23   
Pull request merged.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6786 [OXID eShop (all versions)] 4.08. Cache major always 2018-02-06 11:00 2018-03-21 14:54
Reporter: QA Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 4.10.6 / 5.3.6  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
MySQL Version: Not defined
Summary: default.vcl cookie cleanup missing commas
Description: Default VCL cookie cleanup missing commas

In default.vcl the funciton oxClearCookiesByWhitelistRecv is responsible for cleaning up cookies.
The following section should remove empty strings with a comma:
# Cleaning up - empty string with "," found, cleaning it.
        set req.http.Cookie = regsuball(req.http.Cookie, "(^; )", "");

The regex is looking for semicolon instead of comma.

Multiple cookie headers will be reduced to a repetition of commas and spaces instead of getting removed in the process.

This might result in issues with libpcre which can lead to a varnish crash.
Tags:
Steps To Reproduce: See https://bugs.oxid-esales.com/view.php?id=6786#c12377
Additional Information:
Attached Files:
Notes
(0012377)
michael_keiluweit   
2018-02-07 09:31   
How to reproduce:

Create a script in the directory of the shop:
<?php
require_once 'bootstrap.php';

$o = oxNew('oxutilsserver');

for ($i = 0; $i < 72; $i++) {
    $o->setOxCookie('mk'.$i, 'value');
}


After calling the script via browser you will get a similar output:
Error 503 Backend fetch failed
Backend fetch failed

Guru Meditation:
XID: 3

Varnish cache server


The log varnishncsa logs in that situation this:
::1 - - [07/Feb/2018:09:23:57 +0100] "GET http://localhost/e536/bin/c.php HTTP/1.1" 503 278 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.119 Safari/537.36"



The varnishlog log:

$ sudo varnishlog
*   << BeReq    >> 32771     
-   Begin          bereq 32770 fetch
-   Timestamp      Start: 1517992250.508905 0.000000 0.000000
-   BereqMethod    GET
-   BereqURL       /e536/bin/c.php
-   BereqProtocol  HTTP/1.1
-   BereqHeader    Upgrade-Insecure-Requests: 1
-   BereqHeader    User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.119 Safari/537.36
-   BereqHeader    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
-   BereqHeader    Accept-Language: en-US,en;q=0.9,de;q=0.8
-   BereqHeader    X-Forwarded-For: ::1
-   BereqHeader    x-host: localhost
-   BereqHeader    x-url: /e536/bin/c.php
-   BereqHeader    host: localhost
-   BereqHeader    x-cookie: oxidadminprofile=0%40Standard%4010%401; oxidadminlanguage=de
-   BereqHeader    x-esi-level: 0
-   BereqHeader    Surrogate-Capability: varnish=ESI/1.0
-   BereqHeader    grace: none
-   BereqHeader    Accept-Encoding: gzip
-   BereqHeader    X-UA-Device: desktop
-   BereqHeader    X-UA-Language: en
-   BereqHeader    Cookie: oxidadminprofile=0%40Standard%4010%401; oxidadminlanguage=de
-   BereqHeader    X-Varnish: 32771
-   VCL_call       BACKEND_FETCH
-   VCL_return     fetch
-   BackendOpen    18 boot.default 127.0.0.1 8080 127.0.0.1 36652
-   Timestamp      Bereq: 1517992250.509432 0.000527 0.000527
-   BogoHeader     Too many headers: Set-Cookie: mk54=val
-   HttpGarbage    "HTTP/1.1%00"
-   BerespStatus   503
-   BerespReason   Service Unavailable
-   FetchError     http format error
-   BackendClose   18 boot.default
-   Timestamp      Beresp: 1517992250.519115 0.010210 0.009683
-   Timestamp      Error: 1517992250.519121 0.010216 0.000007
-   BerespProtocol HTTP/1.1
-   BerespStatus   503
-   BerespReason   Service Unavailable
-   BerespReason   Backend fetch failed
-   BerespHeader   Date: Wed, 07 Feb 2018 08:30:50 GMT
-   BerespHeader   Server: Varnish
-   VCL_call       BACKEND_ERROR
-   BerespHeader   Content-Type: text/html; charset=utf-8
-   BerespHeader   Retry-After: 5
-   VCL_return     deliver
-   Storage        malloc Transient
-   ObjProtocol    HTTP/1.1
-   ObjStatus      503
-   ObjReason      Backend fetch failed
-   ObjHeader      Date: Wed, 07 Feb 2018 08:30:50 GMT
-   ObjHeader      Server: Varnish
-   ObjHeader      Content-Type: text/html; charset=utf-8
-   ObjHeader      Retry-After: 5
-   Length         282
-   BereqAcct      692 0 692 3330 0 3330
-   End            

*   << Request  >> 32770     
-   Begin          req 32769 rxreq
-   Timestamp      Start: 1517992250.508652 0.000000 0.000000
-   Timestamp      Req: 1517992250.508652 0.000000 0.000000
-   ReqStart       ::1 33700
-   ReqMethod      GET
-   ReqURL         /e536/bin/c.php
-   ReqProtocol    HTTP/1.1
-   ReqHeader      Host: localhost
-   ReqHeader      Connection: keep-alive
-   ReqHeader      Cache-Control: max-age=0
-   ReqHeader      Upgrade-Insecure-Requests: 1
-   ReqHeader      User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.119 Safari/537.36
-   ReqHeader      Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
-   ReqHeader      Accept-Encoding: gzip, deflate, br
-   ReqHeader      Accept-Language: en-US,en;q=0.9,de;q=0.8
-   ReqHeader      Cookie: oxidadminprofile=0%40Standard%4010%401; oxidadminlanguage=de
-   ReqHeader      X-Forwarded-For: ::1
-   VCL_call       RECV
-   ReqHeader      x-host: localhost
-   ReqHeader      x-url: /e536/bin/c.php
-   ReqUnset       Host: localhost
-   ReqHeader      host: localhost
-   ReqHeader      x-cookie: oxidadminprofile=0%40Standard%4010%401; oxidadminlanguage=de
-   ReqHeader      x-esi-level: 0
-   ReqHeader      Surrogate-Capability: varnish=ESI/1.0
-   ReqUnset       Cookie: oxidadminprofile=0%40Standard%4010%401; oxidadminlanguage=de
-   ReqHeader      grace: none
-   ReqUnset       Accept-Encoding: gzip, deflate, br
-   ReqHeader      Accept-Encoding: gzip
-   ReqHeader      X-UA-Device: desktop
-   ReqHeader      X-UA-Language: en
-   VCL_return     hash
-   VCL_call       HASH
-   ReqURL         /e536/bin/c.php
-   VCL_return     lookup
-   VCL_call       MISS
-   ReqHeader      Cookie: oxidadminprofile=0%40Standard%4010%401; oxidadminlanguage=de
-   VCL_return     fetch
-   Link           bereq 32771 fetch
-   Timestamp      Fetch: 1517992250.519203 0.010550 0.010550
-   RespProtocol   HTTP/1.1
-   RespStatus     503
-   RespReason     Backend fetch failed
-   RespHeader     Date: Wed, 07 Feb 2018 08:30:50 GMT
-   RespHeader     Server: Varnish
-   RespHeader     Content-Type: text/html; charset=utf-8
-   RespHeader     Retry-After: 5
-   RespHeader     X-Varnish: 32770
-   RespHeader     Age: 0
-   RespHeader     Via: 1.1 varnish-v4
-   VCL_call       DELIVER
-   RespHeader     grace: none
-   RespHeader     Cache-Control: no-cache, no-store, must-revalidate, proxy-revalidate
-   RespHeader     Pragma: no-cache
-   RespHeader     Expires: Tue, 01 Jan 1985 00:00:00 GMT
-   VCL_return     deliver
-   Timestamp      Process: 1517992250.519241 0.010588 0.000038
-   RespHeader     Content-Length: 282
-   Debug          "RES_MODE 2"
-   RespHeader     Connection: keep-alive
-   Timestamp      Resp: 1517992250.519275 0.010623 0.000034
-   ReqAcct        491 0 491 380 282 662
-   End            

*   << Session  >> 32769     
-   Begin          sess 0 HTTP/1
-   SessOpen       ::1 33700 :80 ::1 80 1517992250.506763 15
-   Link           req 32770 rxreq
-   SessClose      REM_CLOSE 5.110
-   End            



!Be aware!: When the test script is executed with a lower number and varnish could handle that request, then the result is cached and further tests are meaningless. After getting the status 200 you must restart varnish to flush the cache.
(0012380)
Knut Steiner   
2018-02-14 13:01   
(Last edited: 2018-02-14 13:05)
My Colleagues are still suspecting the following line of gp.vcl to cause the crash:

{noformat}
        # Cleaning up - empty string with "," found, cleaning it.
        set beresp.http.Set-Cookie = regsuball(beresp.http.Set-Cookie, "^(, )+", "");
{noformat}

On our test system, my colleagues have replaced that position with this block:

{noformat}
        # Unset Set-Cookie if only comma-spaces are left
        if (beresp.http.Set-Cookie ~ "^[, ]*$") {
            unset beresp.http.Set-Cookie;
        } else {
            # Cleaning up - empty string with "," found, cleaning it.
            set beresp.http.Set-Cookie = regsuball(beresp.http.Set-Cookie, "^(, )+", "");
        }
{noformat}

The idea of my colleagues was to dispose of a string consisting exclusively of comma-blanks en bloc, without replacing with regsuball () the whole places of discovery. It may be natural that the match () (represented by the tilde) also causes the library to fall.
After we've tested the VCL on our test system, we replaced the VCL on our customers live system early in the morning.
But we have still found strings consisting of comma-blanks that crash the libpcre. Only much less often. Yesterday we updated also the libpcre on theserver. It works but nothing has changed.

Therefore we still need OXIDs help on this case and hope that you will find a solution to fix that problem.

(0012381)
Knut Steiner   
2018-02-15 10:20   
UPDATE!!!
Today we went back to the "old" gp.vcl because of much slower page speeds since we've made the modification.

That means we are waiting for a solution that will fix the problem 'cookie cleanup missing commas'.
It would be nice if OXID could fix that problem contemporary.
(0012414)
Knut Steiner   
2018-03-12 14:48   
Hello,

I must apologize that we didn't give you a message belonging the varnish problems. Because of my illness no one took care of that ticket.

After my colleagues received your email on the 20th of february they implemented the changes to the VCL. After they've tested the configuration on the Pötschke test-system they implemented the changes onto the live-VARNISH.
Since that time we couldn't detect a crash of the libpcre. But we detected some cases of ' , , , , , , , ' after the changes. By the way, the shop works fine and our customer didn't receive any failure warnings that cause a 502 failure.

Thank you for your support.
Knut Steiner


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5998 [OXID eShop (all versions)] 4.11. Image handling minor always 2014-12-15 11:40 2018-03-14 13:50
Reporter: eike_spriess Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 4.9.3 / 5.2.3  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Azure
Browser: All
PHP Version: any
MySQL Version: any
Summary: If option $this->sAltImageDir is set in config.inc.php, new article pictures are no longer generated
Description: Alternative URL to remote image server can be specified in configuration file config.inc.php by setting sAltImageUrl and sSSLAltImageUrl.

Thus all product pictures will be loaded from this alternative server instead of the local one.

However, uploaded files will be stored locally. In this case synchronization to external server has to be done manually or with custom scripts.
Tags:
Steps To Reproduce:
Additional Information: If option $this->sAltImageDir = "subdomain/images"; is set in config.inc.php, new pictures are no longer generated from master picture stored locally.

So copying the new pictures to subdomain/images/ did not solve the problem, because pictures were also not generated in /out/pictures/ folder.
Attached Files:
Notes
(0010450)
Linas Kukulskis   
2014-12-15 11:44   
(Last edited: 2018-03-14 13:50)
https://oxidforge.org/en/list-of-configuration-options there are explanation with note



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6782 [OXID eShop (all versions)] 6. ------ Setup ------- minor always 2018-01-31 18:29 2018-03-13 09:41
Reporter: florian1996 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.0.2  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: 5.6
MySQL Version: Not defined
Summary: install EE Version 6.0.0 failed
Description: I tried with the command "composer create-project oxid-esales/oxideshop-project V6 dev-b-6.0-ee
" to install OXID EE Version 6.0.0.

But there comes the following error: "Script if [ -f ./vendor/bin/oe-eshop-ide_helper ]; then oe-eshop-ide_helper; fi handling the oe:ide-helper:generate event returned with error code 255".

and then comes in the setup of "directories and login" this error:
Error while executing the command 'Migration'.Returncode' 0 ' (the whole error is in the appendix)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Bildschirmfoto 2018-01-31 um 10.12.23.png (137,652 bytes) 2018-01-31 18:29
https://bugs.oxid-esales.com/file_download.php?file_id=1582&type=bug
Notes
(0012374)
QA   
2018-02-01 09:35   
I tried your command on a machine running PHP 5.6 and didn't face any of the errors. Composer ended without any error and also the shop setup finished correct. Shop is working.

Can't acknowledged the issue as a bug, because I'm unable to reproduce it. I'm pretty sure the problem comes from your system and has nothing to do with the OXID eShop 6.0.
(0012416)
gregor.hyneck   
2018-03-13 09:07   
This issue was reproduced with these settings in the my.cnf-configuration file:

[mysqld]
collation-server = utf8_unicode_ci
character-set-server = utf8

This is a bug in Doctrine migrations.
(0012419)
gregor.hyneck   
2018-03-13 09:30   
Fixed with https://github.com/OXID-eSales/oxideshop-doctrine-migration-wrapper/tree/v2.1.1


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6807 [OXID eShop (all versions)] 2.6. Administer orders minor always 2018-03-09 17:13 2018-03-09 17:26
Reporter: henrik.steffen Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 4.10.6 / 5.3.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
MySQL Version: Not defined
Summary: Discount removed from orderitem when adding another discount in oxid admin backend
Description: If you have a discount, which is limit just to some articles (not to categories!), this type of discount will be removed when applying an additional discount in oxid admin backend.
Tags:
Steps To Reproduce: 1. Modify the discount "10% on 200 Euro or more" to be limited just to one item like e.g. article number 1302
2. Purchase this item in store frontend. Product price will be shown as 479 € on details page, but as soon as you put it into the basket the item price changes to 431,10 €
3. Submit the order
4. Go to admin orders main tab and change the "Discount" field value from "0" to "1"
5. Order amount didn't decrease by 1 € as expected, instead, the orderitem-discount 10% was removed, so the new total order amount is 478,00 € (479 € - 1 € discount)


Additional Information:
Attached Files: Bildschirmfoto 2018-03-09 um 17.04.06.png (111,415 bytes) 2018-03-09 17:13
https://bugs.oxid-esales.com/file_download.php?file_id=1606&type=bug
Bildschirmfoto 2018-03-09 um 17.03.54.png (103,540 bytes) 2018-03-09 17:13
https://bugs.oxid-esales.com/file_download.php?file_id=1607&type=bug
Bildschirmfoto 2018-03-09 um 17.03.38.png (83,485 bytes) 2018-03-09 17:13
https://bugs.oxid-esales.com/file_download.php?file_id=1608&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6806 [OXID eShop (all versions)] 2.6. Administer orders minor always 2018-03-09 16:30 2018-03-09 17:15
Reporter: henrik.steffen Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 4.10.6 / 5.3.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
MySQL Version: Not defined
Summary: Error message not translated, translation key shown instead
Description: When item quantity is increased beyond the available oxstock of the article and oxstockflag is "not buyable" or "offline" when out of stock, the error message

ERROR_MESSAGE_ARTICLE_ARTICLE_NOT_BUYABLE

is displayed as a translation key, and not translated.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Bildschirmfoto 2018-03-09 um 16.28.27.png (141,682 bytes) 2018-03-09 16:30
https://bugs.oxid-esales.com/file_download.php?file_id=1605&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5610 [OXID eShop (all versions)] 2.6. Administer orders major always 2014-01-18 22:36 2018-03-05 10:40
Reporter: Mitmacher Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 4.8.1 / 5.1.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: All
Browser: All
PHP Version: Not defined
MySQL Version: Not defined
Summary: Bundled products will be deleted from their orders after using forms in order_main or order_article
Description: If you have orders with bundled products then edit these orders in the backend and you will see that the bundles have been deleted magically.
Tags:
Steps To Reproduce: 1. create an article bundle
2. order this article and reopen backend
3. in order_overview and order_articles the bundle is listed correctly
4. click "Save" in order_main or "Update" in order_articles
5. the bundle has been deleted from its order!
Additional Information: Please look at the function addOrderArticleToBasket(...) in oxbasket.php. Since OXID 4.5.x there is an if statement wich causes this problem:

if ( $oOrderArticle->oxorderarticles__oxamount->value > 0 && !$oOrderArticle->isBundle() ) {
   ...
} elseif ( $oOrderArticle->isBundle() ) {
    // deleting bundles, they are handled automatically
    $oOrderArticle->delete();
}

So, if you simply delete "&& !$oOrderArticle->isBundle()", everything seems to work as expected again. But what's the reason for the comment? I neither can't find such automatism nor it seems to work. Bundles are just deleted.
Attached Files:
Notes
(0009429)
svetlana   
2014-01-20 15:46   
Reminder sent to: Mitmacher
Hi,
We have a question to make sure how you reproducing the bug. Does the discount with bundle product is still active and the expiration date is still valid for this discount during you make update in the admin? Because I can reproduce this issue in this case:
1. create discount with the item.
2. purchase product with item discount.
3. deactivate created discount
4. in admin update the order.
(0009430)
Mitmacher   
2014-01-20 16:18   
Hi,
no, it is also reproducable if the bundle is still active! The funny thing is that if you delete the article (to which the deleted one was bundled) and re-add it again in admin, than the bundle is also re-added. But if you than update the order once more (without change) it is deleted again! Crazy ;-)
(0009432)
Mitmacher   
2014-01-20 22:45   
Ah, now I see: I don't meant discount bundles, but the simple variant to bundle one article to another in product admin. I didn't recognize there are two ways of creating so-called bundles, sorry! ;)

But I've created a summarized (german) forum thread for all the problems with updating orders in admin:
http://forum.oxid-esales.com/showthread.php?t=21886

Thanks for relating to 0004624, because I didn't find all those topics before! :)
(0012410)
henrik.steffen   
2018-03-05 10:40   
Would be great if this annoying issue could actually be solved, more than 4 years after reporting it.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6800 [OXID eShop (all versions)] 1.05. Users minor always 2018-02-26 11:53 2018-02-26 13:18
Reporter: E.W. Platform:  
Assigned To: OS:  
Priority: low 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
MySQL Version: Not defined
Summary: Basket is dropped if user registration failed.
Description: Basket is dropped every time the user registrations fails.

Here is the problematic coe: https://github.com/OXID-eSales/oxideshop_ce/blob/ddef4f79e3ce69ca9e53130cf85a44b8a399d3ff/source/Application/Component/UserComponent.php#L304
Tags:
Steps To Reproduce: 1. Not logged in state.
2. Add one or more products to the basket.
3. Try to register an user account with an already existing e-mail.
- click at the top of the page 'Log in' -> 'Register'
- doesn't work if you register while in basket context (see note for more info)
4. Oxid throws an Exception and drops the basket.
Additional Information:
Attached Files: basketDrop_inBasketContext.JPG (77,359 bytes) 2018-02-26 13:17
https://bugs.oxid-esales.com/file_download.php?file_id=1598&type=bug
basketDrop.JPG (75,467 bytes) 2018-02-26 13:17
https://bugs.oxid-esales.com/file_download.php?file_id=1599&type=bug
Notes
(0012399)
QA   
2018-02-26 13:17   
This issue only occurs if you try to register an account with a click to 'Login' -> 'Register' at the top of the site (result in Fig. 1). If you are in basket context and say 'Open Account' at step 2, basket won't be dropped (result in Fig. 2).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6798 [OXID eShop (all versions)] 4.09. SEO, SEO URL feature sometimes 2018-02-23 14:41 2018-02-26 09:25
Reporter: leofonic Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 6.0.1  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
MySQL Version: Not defined
Summary: hreflang tags do not fit well with canonical tags
Description: Hreflang tags use the same mechanism as the language dropdown, and both do not use the same urls as in canonical tag.
If hreflang tags are used together with canonical tags, it should be made clear what to index:
- hreflang tags should not be used on pages that point to a different url with a canonical tag
- pages that point to themselves with canonical tag should use the canonical tag versions in hreflang tags

This seems not so easy to fix because:
- method getCanonicalUrl does not take a language parameter.
- Oxid tries to guess language on the start page, so if you use the actual base url for language switching, you cannot go back to the default langauge.

Additionally, Oxid does not even use "startseite" and "en/home" on the start page anymore, instead oxid uses "index.php?cl=start" (since V6)
Tags: Canonical Link, SEO
Steps To Reproduce: Do a Google search for "demoshop oxid", the first result points to:
https://demoshop.oxid-esales.com/professional-edition/index.php?cl=start
This is the link from hreflang, so Google seems to ignore the canonical tag because hreflang differs.
Additional Information:
Attached Files:
Notes
(0012395)
QA   
2018-02-23 16:22   
I tested the scenario in Vivaldi browser, getting the url https://demoshop.oxid-esales.com/professional-edition/.
I tested again in Chrome browser and the url https://demoshop.oxid-esales.com/professional-edition/index.php?cl=start appeared.
Found out the difference is that I'm not logged in into my Google account in Chrome browser.

However, we are not able to prescribe which url to index. The search engines 'do what they want'. We can only try to request something but Google and co don't have to work as we wish they do.

So it is not completly clear what's the bug - I can't see anything OXID eShop 6 doing wrong. Maybe you could provide some more information to clarify the issue.
(0012396)
leofonic   
2018-02-23 16:55   
"We can only try to request something"

If there is one url given by canonical tag and a different url given by hreflang then you request contradicting things. You can see this in effect in the example search, Google does not index the url given in canonical as expected but instead the one given in hreflang.

So this should be changed:
- urls in canonical and hreflang should be equal for pages that shall be indexed.
- urls that shall not be indexed should not use hreflang

Also see https://www.rebelytics.com/hreflang-canonical/
(0012397)
QA   
2018-02-26 09:23   
Thank you for your response and clarification.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6792 [OXID eShop (all versions)] 4.01. Database handling minor always 2018-02-19 15:53 2018-02-23 13:58
Reporter: usenff 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: Not defined
PHP Version: 7.0
MySQL Version: Not defined
Summary: [Enterprise Edition] exception - when adding a newly created model to session
Description: If you create a model, save it to the database and add the resulting object to the session you get an exception like this:

[16-Feb-2018 13:00:53 Europe/Berlin] PHP Fatal error: Uncaught PDOException: You cannot serialize or unserialize PDO instances in /var/www/dev.schwab.de/vendor/oxid-esales/oxideshop-ce/source/Core/Session.php:411
Stack trace:
#0 [internal function]: PDO->__sleep()
#1 /var/www/dev.schwab.de/vendor/oxid-esales/oxideshop-ce/source/Core/Session.php(411): session_write_close()
#2 /var/www/dev.schwab.de/vendor/oxid-esales/oxideshop-ce/source/Application/Controller/OxidStartController.php(71): OxidEsales\EshopCommunity\Core\Session->freeze()
#3 /var/www/dev.schwab.de/vendor/oxid-esales/oxideshop-ce/source/Core/Config.php(628): OxidEsales\EshopCommunity\Application\Controller\OxidStartController->pageClose()
#4 /var/www/dev.schwab.de/vendor/oxid-esales/oxideshop-ce/source/Core/ShopControl.php(292): OxidEsales\EshopCommunity\Core\Config->pageClose()
#5 /var/www/dev.schwab.de/vendor/oxid-esales/oxideshop-ce/source/Core/ShopControl.php(137): OxidEsales\EshopCommunity\Core\ShopControl->_process('OxidEsales\\Esho...', 'addVoucher', NULL, NULL)
#6 /var/www/dev.schwab.de/vendo in /var/www/dev.schwab.de/vendor/oxid-esales/oxideshop-ce/source/Core/Session.php on line 411
Tags:
Steps To Reproduce: In one request
- create a new VoucherSeries (or any other object that inherits BaseModel)
- write it to the database
- add it to the session
Additional Information: The exception is thrown because the BaseModel references a PDO-Object which cant be serialized:

The reference is set in:
OxidEsales\EshopEnterprise\Core\Model\BaseModel->_insert()

Resulting in the following object-chain:
\OxidEsales\EshopProfessional\Core\Model\BaseModel :: $_oElement2ShopRelations ==> \OxidEsales\EshopEnterprise\Core\Element2ShopRelations :: $_oDbGateway ==> OxidEsales\EshopEnterprise\Core\Element2ShopRelationsDbGateway :: $_oDb ==> OxidEsales\Eshop\Core\Database\Adapter\Doctrine\Database

Possible solution 1:
Don't save a reference to the Database in the Element2ShopRelationsDbGateway. Use the Registry instead.

Possible solution 2:
Implement Element2ShopRelationsDbGateway->__sleep() and set "$_oDb" = NULL
Attached Files: pdoerror.php (1,335 bytes) 2018-02-20 13:30
https://bugs.oxid-esales.com/file_download.php?file_id=1592&type=bug
pdoErrorNotReproducable.JPG (349,336 bytes) 2018-02-20 15:51
https://bugs.oxid-esales.com/file_download.php?file_id=1593&type=bug
Notes
(0012389)
QA   
2018-02-20 12:45   
It's true that PDO instances can't be serialized, but I tried to reproduce the described scenario with OXID framework and didn't run into any error. My voucher series object got successfully stored in the session object. So I can't see any problems with OXID eShop.

Therefore I have to ask you for a documented script that reproduces the behavior you mentioned here.
(0012390)
usenff   
2018-02-20 13:30   
Hi,

I attached the file "pdoerror.php". If you put it into your source directory and call it via browser it should reproduce the error.
Important: The error only occures in the Enterprise Edition.

Kind regards,
Uwe
(0012391)
QA   
2018-02-20 15:51   
(Last edited: 2018-02-20 15:51)
Hello Uwe,

thank you again for your information and provided data!

Unfortunatelly, I have to tell you, that your script looks similar to my own testing script. So as I expected, I didn't run into the error.

I added one line to the end of your script to show you the result of my successfull execution (Fig. 1). The issue was tested with a standard installation of OXID eShop Enterprise 6.0.1 running with PHP 7.0. As a conclusion I have to assume that you have done some modifications in the past, now interfering with the given use case.

(0012392)
usenff   
2018-02-20 16:27   
Hi,

I setup an new ee-shop without our changes and ran the "pdoerror.php". The error was logged to my php-error-logs.
To see the error in your browser please add the following lines __below__ "require_once $sPath . DIRECTORY_SEPARATOR . "bootstrap.php";"

error_reporting(E_ALL);
ini_set('display_errors', 1);

The output in your browser should be something like this:
Fatal error: Uncaught PDOException: You cannot serialize or unserialize PDO instances in [no active file]:0 Stack trace: #0 [internal function]: PDO->__sleep() #1 {main} thrown in [no active file] on line 0

Kind regards,
Uwe
(0012394)
QA   
2018-02-23 13:58   
Hello Uwe,

I modified the script and have to tell, that I now run into the error.
Issue is set to acknowledged.

Thanks for your response and work.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6796 [OXID eShop (all versions)] 1.05. Users minor always 2018-02-22 15:18 2018-02-23 09:47
Reporter: vilma_liorensaityte 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
MySQL Version: Not defined
Summary: It is possible to delete default mall user
Description: After changing the default user id from static value to dynamic, it is now possible to delete default mall admin in backend.
Tags:
Steps To Reproduce: 1. Install new shop
2. Login as default mall admin into the backend
3. Go to Administer Users->Users and delete all users even your self
4. You will be logged out and it will not be possible to login into backend anymore.
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6797 [OXID eShop (all versions)] 1.02. Price calculations (discounts, coupons, additional costs etc.) minor always 2018-02-22 21:49 2018-02-23 09:45
Reporter: henrik.steffen Platform:  
Assigned To: OS:  
Priority: normal 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
MySQL Version: Not defined
Summary: Random order in voucher discount recalculation leads to changing order amounts in admin backend upon saving
Description: It's a difference if you apply a percentual voucher after an absolute voucher or the other way round.

Example:
Basket amount: 100,00 €
Apply a 10 € absolute voucher: 90,00 €
Apply additional 10 % percentual voucher: 81,00 €

If however you'd add the voucher codes in opposite order the calculation gives this:

Basket amount: 100,00 €
Apply 10 % percentual voucher: 90,00 €
Apply additional 10 € absolute voucher: 80,00 €

As you see, the order amounts differ by 1 €, even though the same voucher codes where used.

This is a funny fact for the customer, if he'd ever try to play with the order in which vouchers are added to the basket.
But in the OXID backend it gets really ugly, and this should be considered a serious bug:
Order recalculation in admin backend applies vouchers in a RANDOM order, this means, not in the same order as the customer entered his voucher codes. So, the order total amount could change by simply saving the order again in admin backend order section (except on the main tab where discount recalculcation is not performed).

So, when trying to capture the order on credit cards or similar, the amount might differ, which could result in a capture error, if the order amount increased or changed.


Tags: Price Calculation, Solution Provided, Voucher
Steps To Reproduce:
Additional Information: To solve:

application/models/oxorder.php
$sQ = 'select oxid from oxvouchers where oxorderid = ' . $oDb->quote($this->getId());
add an "order by oxreserved" to the query statement, so the same order will be used as when the user entered the voucher codes in the shop frontend.

Attached Files: vouchers2.png (61,929 bytes) 2018-02-22 21:49
https://bugs.oxid-esales.com/file_download.php?file_id=1594&type=bug
vouchers1.png (63,334 bytes) 2018-02-22 21:49
https://bugs.oxid-esales.com/file_download.php?file_id=1595&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6795 [OXID eShop (all versions)] 6. ------ Setup ------- minor always 2018-02-22 08:51 2018-02-22 10:17
Reporter: vilma_liorensaityte 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
MySQL Version: Not defined
Summary: Default shop language will not be updated during setup
Description: If you select English as default language in setup second step, it will not be updated in data base. German still stays as default language.
Tags:
Steps To Reproduce: 1. Start new shop Setup
2. In second setup step choose English as Shop language
3. Finish setup as usually
4. Go to shop Admin->Master Settings->Languages: German is a default language and not English
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6794 [OXID eShop (all versions)] 6. ------ Setup ------- feature always 2018-02-21 14:52 2018-02-21 14:55
Reporter: QA Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: assigned 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
MySQL Version: Not defined
Summary: Downloading and installing OXID eShop 6.0 without demodata
Description: If you installing OXID eShop 6.0 with composer, the demodata is always being downloaded. Demodata has around 200 MB, most users don't need/want.
Tags: Demo Data
Steps To Reproduce: - install OXID eShop 6.0 with composer
Additional Information: There's a "--no-dev" parameter, which excludes some files like the testing library. A second parameter could named "--no-demodata", doing exactly the same with the demodata packages. Many users would appreciate this.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4592 [OXID eShop (all versions)] 4.09. SEO, SEO URL feature always 2012-10-05 14:47 2018-02-16 15:17
Reporter: b.hasis Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: assigned Product Version: 4.6.4 revision 49061  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: Not defined
Browser: All
PHP Version: Not defined
MySQL Version: Not defined
Summary: Show SEO Suffix in Category just works for the Supershop and all malls inherit that setting
Description: The checkbox for "Show SEO Suffix in Category" in the SEO tab by the categories, dont work like expected.

I want to trigger the suffix in all Malls separately, not just in the Supershop for all malls one Time.
Tags: Category, SEO
Steps To Reproduce:
Additional Information: Please DONT remove the checkbox in all malls. Move oxshowsuffix into oxobject2seodate.
Attached Files:
Notes
(0009700)
svetlana   
2014-03-28 09:59   
waiting for the PO decision.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6790 [OXID eShop (all versions)] 2.3. Extensions (modules, themes) minor always 2018-02-14 08:27 2018-02-14 08:33
Reporter: QA 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: Not defined
PHP Version: Not defined
MySQL Version: Not defined
Summary: Shop doesn't work after Amazon Pay module deactivation
Description: If you deactivate the Amazon Pay & Login 4 OXID by BESTIT module, the (incorrect) frontend will be shown in backend (Fig. 1) and the frontend doesn't work correctly anymore (Fig. 2).
Problems also appearing in shop's EXCEPTION_LOG (see attached files).
Tags: Module
Steps To Reproduce: (- activate Amazon Pay & Login 4 OXID by BESTIT module)
- deactivate Amazon Pay & Login 4 OXID by BESTIT module
Additional Information: If you clear the shop's /tmp folder (including /smarty folder!), shop works again.
Attached Files: amazonPayIssue_frontend.JPG (55,341 bytes) 2018-02-14 08:31
https://bugs.oxid-esales.com/file_download.php?file_id=1589&type=bug
amazonPayIssue_backend.JPG (78,669 bytes) 2018-02-14 08:31
https://bugs.oxid-esales.com/file_download.php?file_id=1590&type=bug
EXCEPTION_LOG_20180213.txt (14,715 bytes) 2018-02-14 08:31
https://bugs.oxid-esales.com/file_download.php?file_id=1591&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6497 [OXID eShop (all versions)] 4.01. Database handling critical always 2016-09-02 13:35 2018-02-12 10:03
Reporter: marco_steinhaeuser Platform:  
Assigned To: OS:  
Priority: urgent OS Version:  
Status: resolved Product Version: 4.10.1 / 5.3.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 4.9.10 / 5.2.10  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
MySQL Version: Other
Summary: Checkout doesn't work with MySQL v5.7
Description: Whith MySQL v5.7, the checkout process stops at shipping & payment, displaying the message for 'MESSAGE_NO_SHIPPING_METHOD_FOUND'.
Tags: Checkout, MySQL
Steps To Reproduce:
Additional Information: As web hosting providers seem to upgrade to MySQL 5.7 currently (partially irreversible and without announcement), shop owners get information from their clients that the checkout couldn't be finished. This behaviour is currently reported in the forums, e.g.:
http://forum.oxid-esales.com/showthread.php?t=40141
Attached Files:
Notes
(0011848)
vilma_liorensaityte   
2016-10-25 14:20   
(Last edited: 2016-11-17 13:54)
The issue is fixed in the eShop version 5.3.2:
https://github.com/OXID-eSales/oxideshop_ce/commit/9e747ac2ef765d0af31ba43861d0b64b59de256d
https://github.com/OXID-eSales/oxideshop_ce/commit/25ca7d365f7e25803c945c05c9feb201ac82c9bf

The issue is fixed in the eShop version 5.2.x:
https://github.com/OXID-eSales/oxideshop_ce/commit/6e62ac3f1bf61e21f9ea21a7f5b8901377132e9b
https://github.com/OXID-eSales/oxideshop_ce/commit/d40565401b969c356abedb492b12e82ba4eec077

The issue is fixed in the eShop version 6.0:
https://github.com/OXID-eSales/oxideshop_ce/commit/133fc8bbf658a2793755e9431c148180848cf15f



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6787 [OXID eShop (all versions)] 2.7. Customer info major always 2018-02-06 18:36 2018-02-07 08:37
Reporter: marco_steinhaeuser Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: acknowledged Product Version: 6.0.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 6.1.0  
Theme: All
Browser: All
PHP Version: All
MySQL Version: All
Summary: Banners cannot be uploaded any more
Description: Promotional banners cannot be uploaded any more from this version on (used to work still in v6.0.0). This problem appears after update or in a new installation of v6.0.1.
Tags: Banner, Promotion, Solution Provided
Steps To Reproduce: Go to admin -> customer info -> prormotions and try to upload a new home page banner
Additional Information: https://forum.oxid-esales.com/t/6-0-1-speichert-keine-banner-bilder/92964/

This bug was already resolved with PR 624 https://github.com/OXID-eSales/oxideshop_ce/pull/624 (merged).
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6721 [OXID eShop (all versions)] 4.06. Language and translations minor always 2017-11-14 14:17 2018-01-29 14:31
Reporter: anton.fedurtsya Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.0.0-rc.3  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.0.1  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
MySQL Version: Not defined
Summary: Missing translations
Description: There are missing translations in the eShop. At least those:
* PAGE_DETAILS_THANKYOUMESSAGE1
* PAGE_DETAILS_THANKYOUMESSAGE2
* PAGE_DETAILS_THANKYOUMESSAGE3
* FORM_SUGGEST_MESSAGE1
* FORM_SUGGEST_MESSAGE2
Tags:
Steps To Reproduce: 1. Invitation form:
* Go Admin -> Master settings -> Core settings -> Settings -> Invitations - Turn it on.
* Go to frountend -> Login -> Use "Invite your friends" link on the bottom of the page to see translation errors in form.

2. Price alert form:
* Go to frontend -> Go to any product -> Fill the "Price alert" form and press Send.
* You should get success message like this: ERROR: Translation for PAGE_DETAILS_THANKYOUMESSAGE1 not found! OXID eShop 6ERROR: Translation for PAGE_DETAILS_THANKYOUMESSAGE2 not found! ERROR: Translation for PAGE_DETAILS_THANKYOUMESSAGE3 not found! 123,00 € ERROR: Translation for PAGE_DETAILS_THANKYOUMESSAGE4 not found!
Additional Information:
Attached Files:
Notes
(0012279)
Igor Iegupov   
2017-11-22 09:43   
https://github.com/OXID-eSales/oxideshop_ce/commit/233b05b48d1920aa71e54c98d16e45ddb7c3ac70


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6694 [OXID eShop (all versions)] 4.09. SEO, SEO URL minor always 2017-09-14 11:10 2018-01-29 14:30
Reporter: HR Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.0.0-rc.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.0.1  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: 5.6
MySQL Version: 5.5
Summary: Manufacturer Seo urls not properly stored in database
Description: Issue can be seen when calling SeoEncoderManufacturer::getManufacturerPageUrl().

oxseo.oxtype 'oxmanufacturers' is not in the enum list for oxseo.oxtype.

`OXTYPE` enum('static','oxarticle','oxcategory','oxvendor','oxcontent','dynamic','oxmanufacturer') NOT NULL COMMENT 'Record type')

Database entries are stored with truncated oxseo.oxtype (empty), so shop will not find them again and tries again and again to store that seo page.

NOTE: the fix requires a database change.
Tags:
Steps To Reproduce: See tests/Integration/Seo/GetManufacturerPageSeoTest.php in branch
https://github.com/OXID-eSales/oxideshop_ce/tree/SeoEncoderManufacturer_GetManufacturerPage_oxtype_oxmanufacturers-6694
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6729 [OXID eShop (all versions)] 2.3. Extensions (modules, themes) minor always 2017-11-27 16:33 2018-01-29 14:26
Reporter: HR 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.0.1  
    Target Version: 6.1.0  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
MySQL Version: Not defined
Summary: admin/ajax.php does not work for metadata v1 modules
Description: The fix for 0006711/0006668 introduced another issue.
Now modules for a module with metadata 1 own ajax controller the
admin ajax popup does no longer work.
Tags:
Steps To Reproduce: * Install OXID eSHop 6.0.0 EE with B2B b-2.x module.
* Enable b2b modules via setup script.
* in shop admin, go to products, select a product, click service product.
* enable as service product
* click on 'assign products', ajax popup is empty
Additional Information: Suggested fix can be found in
https://github.com/OXID-eSales/oxideshop_ce/tree/oxajax_fix_for-OXDEV-341

* Test for metadata V1 module was added:
   AjaxFunctionalityAdminTest::testOxAjaxContainerClassResolutionMetadata1Module().
* Not working test for metadata V2 module was skipped momentarily:
  AjaxFunctionalityAdminTest::testOxAjaxContainerClassResolution().
  NOTE: this test passes with and without fix for 0006711 and 0006668 in place.
  Test module and test should best be changed according to metadata V1 module (means: use test12 and fully port to metadata 2).

TODO:
* reproduce
* review suggested changes
* fix AjaxFunctionalityAdminTest::testOxAjaxContainerClassResolution() test.
* run in CI, that was not done yet.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6693 [OXID eShop (all versions)] 1.05. Users minor always 2017-09-14 10:42 2018-01-29 14:23
Reporter: wolkenkrieger Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 4.10.5 / 5.3.5  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.0.1  
    Target Version:  
Theme: Not defined
Browser: Not defined
PHP Version: Not defined
MySQL Version: Not defined
Summary: Not trimmed ZIP-Codes
Description: ZIP-Codes (andy maybe other parts of a address) are not trimmed by default. The user can save ZIP-Codes with whitespaces to the database.
Tags:
Steps To Reproduce: Enter a ZIP-Code with a trailing/and or ending whitespace an save the adress.
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3194 [OXID eShop (all versions)] 4.11. Image handling minor always 2011-08-26 14:23 2018-01-29 14:18
Reporter: tjungcl Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: resolved Product Version: Past development  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.0.1  
    Target Version:  
Theme: Not defined
Browser: All
PHP Version: Not defined
MySQL Version: Not defined
Summary: transparent gif looses transparency when generated to different size
Description: as in https://bugs.oxid-esales.com/view.php?id=970 the same happens with gifs.

After upload via backend, the master image is still transparent, while all generated versions have a black background instead.

I tried a transparent gif as manufacturer-logo.
Tags: Image Conversion
Steps To Reproduce:
Additional Information:
Attached Files: trans.gif (706 bytes) 2011-09-01 09:49
https://bugs.oxid-esales.com/file_download.php?file_id=596&type=bug
trans2.PNG (260,073 bytes) 2012-04-23 10:43
https://bugs.oxid-esales.com/file_download.php?file_id=753&type=bug
Notes
(0005158)
birute_meilutyte   
2011-08-31 14:58   
Reminder sent to: tjungcl
Hello,

sorry, but i can not reproduce the case. Do you still experience the same problem in our latest nightly build (fresh install)? If so, could you please attach this gif image to this bug report?


greetings,
(0005164)
tjungcl   
2011-09-01 09:49   
(Last edited: 2011-09-01 09:50)
I wont do a fresh install of the latest nightly build to verify.

However I tested again in rev 38439 since when no modifications where done to oxdynimggenerator.php

Its important, that the master gif has a different resolution than the generated image will have.

I attached the gif with which i had the problem

(0006266)
dainius.bigelis   
2012-04-13 09:09   
@Developers: please check discussion in forums:
http://www.phpfreaks.com/forums/index.php?topic=302542.0
http://mediumexposure.com/smart-image-resizing-while-preserving-transparency-php-and-gd-library/

and probably need to check the new version of library as described. Might solve the problem.
(0006378)
rimvydas_paskevicius   
2012-04-20 16:24   
Tried upload your attached gif and another one - all works fine. Gif's are resides and transparency is not corrupted. Maybe it depends on GD libary version.

For testing used:

GD Version: 2.0.34
libPNG Version: 1.2.42
(0006398)
tjungcl   
2012-04-23 10:43   
I reproduce it in your own demoshop.
See screenshot
(0008479)
leofonic   
2013-03-06 13:59   
Gif resize Quality is probably bad because oxpicgenerator.php resizeGif uses imagecreate instead of imagecreatetruecolor. From http://www.php.net/manual/en/function.imagecopyresampled.php :
Note:

There is a problem due to palette image limitations (255+1 colors). Resampling or filtering an image commonly needs more colors than 255, a kind of approximation is used to calculate the new resampled pixel and its color. With a palette image we try to allocate a new color, if that failed, we choose the closest (in theory) computed color. This is not always the closest visual color. That may produce a weird result, like blank (or visually blank) images. To skip this problem, please use a truecolor image as a destination image, such as one created by imagecreatetruecolor().


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5735 [OXID eShop (all versions)] 1.05. Users major always 2014-04-11 21:53 2018-01-29 14:11
Reporter: gerldental Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: resolved Product Version: 4.8.4 / 5.1.4  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version: 6.0.1  
    Target Version:  
Theme: Azure
Browser: All
PHP Version: Not defined
MySQL Version: Not defined
Summary: user role 'admin' dont't have rights to save banner-promotion
Description: here is seems to be user-rights issue in backend. I have an user with admin-rights in main shop. As fulls rights for the promotions in 'admin roles' are on, it's impossible to save promotion (button inactive). I tried this in live-shop and in clean EE installation - with tha same effect.
Tags: Admin
Steps To Reproduce: Make an user of type shop-admin. In 'Administer user -> admin roles' make all rights to 'Full', save and login to the shop with a new user name. Go to the Customer Info -> promotions and try to edit one of them.
Additional Information:
Attached Files:
Notes
(0009841)
jurate.baseviciene   
2014-04-16 10:38   
Reminder sent to: gerldental
Hi,

Thanks a lot for submitting this issue, but unfortunately we can not reproduce this issue. If there still is a problem, maybe you could send us more details about it? Could you please let us know if you still experience same problem on our demoshop http://demoshop.oxid-esales.com/EnEd ?
We try reproduce with steps:

1. Make an user of type shop-admin.
We created new user: For user right we set Admin(OXID eShop 5)
Assigned User to "Shop Admin" group and save.

2. In 'Administer user -> admin roles' make all rights to 'Full',
 We go to "Administer user -> admin roles"
 Created new admin role and maked all rights to "Full" to this admin role Assigned new user

3. Then login to the shop with those new user

4. Go to the Customer Info -> promotions and try to edit one of them. And we can edit promotions

Which step we do wrong?


Best regards
(0012330)
gerldental   
2018-01-02 15:07   
(Last edited: 2018-01-02 15:23)
>Which step we do wrong?

Sorry, it's taked some time to answer.

I found the reason of this problem. For the first: it's happens only in multishop config:
Only Mall-Admins can edit actions - not Shop Admins.

The reason is this code in application/views/admin/tpl/actions_main.tpl:

  [{ if !$allowSharedEdit }]
    [{assign var="disableSharedEdit" value="readonly disabled"}]
  [{else}]
    [{assign var="disableSharedEdit" value=""}]
  [{/if}]

there no "disableSharedEdit" template variable in source-code defined.

I found only 'allowSharedEdit' ( in oxadminview.php, Z. 170 )

$this->_aViewData['allowSharedEdit'] = $myConfig->getConfigParam('blAllowSharedEdit');



and config variable "blAllowSharedEdit" defined in class oxutils, Z. 962 as

//#1552T
//So far this blAllowSharedEdit is Equal to blMallAdmin but in future to be solved over rights and roles
$myConfig->setConfigParam('blAllowSharedEdit', true);

also, it's setted to true but for Mall-Admins only!

It has nothing to do with rights & roles, as i supposed at first.

I think the code in application/views/admin/tpl/actions_main.tpl is obsolete und must be deleted...
I just commented that out and all works fine now.

(0012337)
benjamin.joerger   
2018-01-03 15:16   
The bug is already fixed and will be shipped with the next maintenance version.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6780 [OXID eShop (all versions)] 2.3. Extensions (modules, themes) minor always 2018-01-26 20:39 2018-01-29 10:00
Reporter: twaldorf Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: acknowledged Product Version: 6.0.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Theme: All
Browser: All
PHP Version: All
MySQL Version: All
Summary: Module "Invoice PDF" doesn't generate note of delivery without a logo
Description: The module "Invoice PDF" generates an invoice instead of a note of delivery when choosing the option "note of deliver without logo".
Tags: pdf dnote invoice modul, Solution Provided
Steps To Reproduce: Go to orders -> Generate note of delivery without logo.
Additional Information: Resolution in /source/modules/oe/invoicepdf/models/invoicepdfoxorder.php:

replace
    case 'dnote':

with
    case ('dnote' || 'dnote_without_logo'):
Attached Files:
Notes
(0012368)
marco_steinhaeuser   
2018-01-26 21:14   
https://forum.oxid-esales.com/t/bug-ce-6-0-0-modul-invoice-pdf-erstellt-keinen-lieferschein-ohne-logo/92942/
(0012369)
tabsl   
2018-01-27 10:38   
https://github.com/OXIDprojects/pdf-invoice-module/pull/4
(0012370)
QA   
2018-01-29 10:00   
Found something interesting:
If I install using composer, there are no options 'without logo'.
If I install by cloning or with the zip file, I see these option and I was able to reproduce the issue.
In both cases, the backend shows module version 2.0.1.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6747 [OXID eShop (all versions)] 6. ------ Setup ------- block always 2017-12-19 01:20 2018-01-26 15:08
Reporter: leofonic 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
MySQL Version: Not defined
Summary: Shop installation fails with error 500 at domainfactory
Description: At german hoster domainfactory, installation stops at db migration (external database command migration:migrate) with error 500. This happens because the setup sends an output to stdout. The hosting provider says this is normal behaviour because "you execute a PHP-Shellscript with cgi. The webserver is waiting for headers at this stage and therefore interprets the output as such. It is definitely not possible to push CLI-messages over CLI on our systems".
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012338)
gn2_netwerk   
2018-01-03 16:27   
(Last edited: 2018-01-03 16:29)
this is not a global problem for the hoster, but only occurs if the script limits in shared hosting are not sufficient, on dedicated servers the installation works without problems, even in the large packages it should fit.

(0012339)
leofonic   
2018-01-03 18:43   
@gn2_netwerk: Of course this can differ from machine to machine. The cause however is not script limits but an output to stdout, as stated in the report. I couldn't find any specs what is allowed or not not allowed to send to stdout of apache's cgi process though. But i noticed that in tests this output is quieted by this line:
$output->setVerbosity(ConsoleOutputInterface::VERBOSITY_QUIET);
but in setup it is not. If the same is done in setup, installation runs through without problems on this shared server.

https://github.com/OXID-eSales/oxideshop_ce/blob/a8cd0baa2cfc5376a7781dde4b3fc4e20021b1a8/tests/Integration/Setup/UtilitiesTest.php#L43
(0012340)
QA   
2018-01-04 08:15   
Thank you for your report!

Unfortunately I can't reproduce this.
As this case wasn't reported yet and we didn't get any other requests about that topic, it feels more like a feature request to enhance the setup process therefore it works on further server settings. For now I will leave it as a bug which is currently not reproducible.

@leofonic: Can you provide us the settings from the webserver which are causing this behaviour in the setup process? Please write them in the notes or send them to support@oxid-esales.com and refer to this bug entry. Thank you in advance!
(0012341)
leofonic   
2018-01-04 11:33   
Unfortunately i have no info about server settings because this is not my own server, i will try to get more info. But i think this is an oxid bug from source code side, because a console output is started and messages are pushed to its output handler that do not appear anywhere, so they might as well be supressed, as it is done in the tests i quoted.
(0012352)
leofonic   
2018-01-12 15:48   
If PHP is running as cgi, output to stdout is sent directly to the browser, so if there is anything sent to stdout before headers, this is interpreted as header. I tried on another shared server this time Strato, and got a similar result:
12.01.2018 15:38:30 xxx.de [client x.x.x.x] malformed header from script. Bad header= : index.php, referer: http://xxx.de/oxid_6/source/Setup/index.php
(0012366)
michael_keiluweit   
2018-01-26 08:31   
I couldn't reproduce it with fastCGI either. But I leave this entry open with this improvement proposal:

"But i noticed that in tests this output is quieted by this line:
$output->setVerbosity(ConsoleOutputInterface::VERBOSITY_QUIET);
but in setup it is not. If the same is done in setup, installation runs through without problems on this shared server.

https://github.com/OXID-eSales/oxideshop_ce/blob/a8cd0baa2cfc5376a7781dde4b3fc4e20021b1a8/tests/Integration/Setup/UtilitiesTest.php#L43"
See comment c0012339
(0012367)
leofonic   
2018-01-26 15:08   
@Michael yes on most systems running fcgi output to stdout is discarded, only on some not. I was not able to find the reason for this yet.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6737 [OXID eShop (all versions)] 2.3. Extensions (modules, themes) major always 2017-12-05 18:53 2018-01-23 11:33
Reporter: lins 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.0.1  
    Target Version:  
Theme: All
Browser: All
PHP Version: 7.0
MySQL Version: 5.6
Summary: Module with namespaces not working on Windows
Description: Modules which uses namespaces are currently not working on windows.
Tags: Module, Namespaces, Solution Provided
Steps To Reproduce: E.g. install "composer require linslin/oxid6-example-module:dev-master" on a Windows machine to reproduce this bug.

[05 Dec 15:21:46.003093 2017] [exception] [type OxidEsales\Eshop\Core\Exception\SystemComponentException] [code 0] [file C:\development\webroot\test-shop\app\vendor\oxid-esales\oxideshop-ce\source\Core\UtilsObject.php] [line 222] [message EXCEPTION_SYSTEMCOMPONENT_CLASSNOTFOUND linslinexamplemodulemain]
[05 Dec 15:21:46.003093 2017] [exception] [stacktrace] #0 C:\development\webroot\test-shop\app\source\oxfunctions.php(103): OxidEsales\EshopCommunity\Core\UtilsObject->oxNew(‘linslinexamplem…’)
#1 C:\development\webroot\test-shop\app\vendor\oxid-esales\oxideshop-ce\source\Core\ShopControl.php(372): oxNew(‘linslinexamplem…’)
#2 C:\development\webroot\test-shop\app\vendor\oxid-esales\oxideshop-ce\source\Core\ShopControl.php(272): OxidEsales\EshopCommunity\Core\ShopControl->_initializeViewObject(‘linslinexamplem…’, NULL, NULL, NULL)
#3 C:\development\webroot\test-shop\app\vendor\oxid-esales\oxideshop-ce\source\Core\ShopControl.php(137): OxidEsales\EshopCommunity\Core\ShopControl->_process(‘linslinexamplem…’, NULL, NULL, NULL)
#4 C:\development\webroot\test-shop\app\vendor\oxid-esales\oxideshop-ce\source\Core\Oxid.php(26): OxidEsales\EshopCommunity\Core\ShopControl->start()
#5 C:\development\webroot\test-shop\app\source\index.php(15): OxidEsales\EshopCommunity\Core\Oxid::run()
#6 C:\development\webroot\test-shop\app\source\admin\index.php(11): require_once(‘C:\development\…’)
#7 {main}
Additional Information:
Attached Files:
Notes
(0012308)
leofonic   
2017-12-05 21:06   
In \vendor\oxid-esales\oxideshop-ce\source\Core\Module\ModuleChainsGenerator.php, basename is used in order to get the class name of old style metadata. The problem is that on windows, basename accepts both slashes and backslashes as directory separator, on linux only slashes. So the namespaced classnames are treated as directory structures on windows.
I did a quick hack to get modules running on windows, from line 238:

            if ($this->createClassExtension($parentClass, $extensionPath)) {
                //EDIT
                //namespaced
                if (strpos($extensionPath, '\\')){
                    $parentClass = $extensionPath;
                    $lastClass = $extensionPath;
                }
                //old style
                else {
                    $parentClass = basename($extensionPath);
                    $lastClass = basename($extensionPath);
                }
                //END EDIT
            }
(0012309)
lins   
2017-12-05 21:44   
Nice work! Are you guys going to release a hotfix version?
(0012320)
marco_steinhaeuser   
2017-12-19 11:18   
@lins, we only publish hotfixes as kind of workarounds for critical bugs like security issues etc. Please take a look at this article (yes, has to be updated) for getting a clue about the main release policies: https://oxidforge.org/en/getting-started#toggle-id-4
(0012322)
lins   
2017-12-19 11:27   
@marco_steinhaeuser, thanks for your response. So I guess this bug will not be fixed in v6.0.1?
(0012356)
leofonic   
2018-01-17 20:28   
PR: https://github.com/OXID-eSales/oxideshop_ce/pull/623
(0012361)
anton.fedurtsya   
2018-01-23 10:58   
Hello guys, i have merged the pull request to b-6.x recently, so will come with the next release.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6773 [OXID eShop (all versions)] 2.4. Administer products minor always 2018-01-18 20:17 2018-01-19 10:58
Reporter: marco_steinhaeuser Platform:  
Assigned To: OS:  
Priority: normal 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: Internet Explorer
PHP Version: Not defined
MySQL Version: Not defined
Summary: WYSIWYG-Pro doesn't work in Internet Explorer 11 any more
Description: WYSIWYG-Pro doesn't work in Internet Explorer 11 any more: It loads but shows no reaction when clicking on the buttons (JS-rendering)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012357)
QA   
2018-01-19 10:55   
There are a few workarounds:
1) Using backend with IE compatible mode. Doesn't look good, but works.
2) Using hotkeys (Ctrl+b for bold text, Ctrl+i for italic text, ...)
3) Preformatting your text in MS Word/LibreOffice and copy&paste to the WYSIWYG editor.
4) Using a alternative WYSIWYG editor, e.g. TinyMCE for OXID eShop CE Versions (https://github.com/vanilla-thunder/bla-tinymce).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6771 [OXID eShop (all versions)] 1.05. Users feature always 2018-01-12 21:01 2018-01-15 10:35
Reporter: henrik.steffen Platform:  
Assigned To: OS:  
Priority: low 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
MySQL Version: Not defined
Summary: Address book
Description: A registered user can edit his billing-address and both, add and edit shipping addresses within the my account section of OXID eShop. But how is a user supposed to delete an old or invalid shipping address from his address book? There is no delete button at all.
Tags: Address, UX
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012353)
QA   
2018-01-15 09:26   
It's correct, there's no button for the user in frontend, but Admins can delete addresses in backend.
However, I have to say it's not a bug, it's a feature request. (changed severity to 'feature')


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6767 [OXID eShop (all versions)] 4.07. Source code, Test major always 2018-01-12 11:15 2018-01-12 14:46
Reporter: henrik.steffen 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
MySQL Version: Not defined
Summary: Lazy loading problem with __isset() in BaseModel.php
Description: We've noticed that the behavior in lazy loading somehow changed comparing PHP 5.6 and PHP 7.

It can happen that isset() gives NULL if the specified variable has never been accessed before.

Obviously OXID developers also noticed the problem, because in function getCustomVAT() from OXID version 4.10.6 to 6.0.0 the code was changed from:

 public function getCustomVAT()
    {
        if (isset($this->oxarticles__oxvat->value)) {
            return $this->oxarticles__oxvat->value;
        }
    }


into:

public function getCustomVAT()
   {
       if ($this->__isset('oxarticles__oxvat') || $this->__get('oxarticles__oxvat')) {
           return $this->oxarticles__oxvat->value;
       }
   }

This solves the problem for the oxvat ONLY -

However, we would suggest to apply this patch not here but directly in the BaseModel.php by adding a __get to the __isset function... changing it from:

return isset($this->$variableName);

return isset($this->$variableName) === true || $this->__get($variableName);

This would make sure, all occurencies of __isset() in the code would work as expected without any lazy loading issues.
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:
6768 [OXID eShop (all versions)] 4.08. Cache minor always 2018-01-12 11:25 2018-01-12 12:04
Reporter: QA Platform:  
Assigned To: OS:  
Priority: normal 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
MySQL Version: Not defined
Summary: Memcached causes shop crashes
Description: We were able to identify a problem in the shop that arises because the memcached cannot cope with it if a cache object ID contains a space. This can occur in OXID, for example, when a CMS page is created whose ident contains a blank space. If you then try to load this CMS page, the request terminates. If you want to link to this CMS page e. g. in the footer, i. e. on all pages, it is no longer possible to call up only one of the shop pages.
 
Our suggested solution would be to return only hashed values at places in the core classes where a cache key is created (e. g. oxContent:: getCacheKey ()) and thus to eliminate all special characters that could lead to a problem in the memcached. It may also make sense to define a global getCacheKey function in the core class oxCacheBackend or oxMemcachedCacheConnector, which can replace the individual getCacheKey functions in the various model classes.
 
We solved the problem with us by removing all blanks for the cache key from the CMS identities in order to have the memcached working again.
Tags:
Steps To Reproduce: Enable caching in the Default Cache Backend area and configure Memcached as Connector.
Extend a Smarty template as described below
 
Example input in a Smarty template:
[{oxifcontent ident="test test2 test3"}][{/oxifcontent}]
[{oxifcontent ident="test4"}][{/oxifcontent}]
 
The CMS pages for the idents don't even have to exist.
request cancels in the function oxContent::LoadFromCache ($sOXID) when trying to save "test4" in the cache
Line 164: $oCache->set ($sKey, $oCacheItem);
Additional Information: Additional information
 
If the memcached is switched to the binary protocol, it could handle spaces in cache keys. However, we will no longer be able to delete only selected objects from the cache (regular expression on the cache keys). This is currently used by our customer to delete all cache entries except for the sessions from the memcached.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5504 [OXID eShop (all versions)] 2.4. Administer products minor always 2013-11-06 12:29 2018-01-12 11:26
Reporter: michael_keiluweit Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Ve