View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006987||OXID eShop (all versions)||2.4. Administer products||public||2019-05-28 17:00||2020-04-03 16:15|
|Target Version||Fixed in Version|
|Summary||0006987: 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'
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'
|Steps To Reproduce||see description|
|Tags||Admin, Article, EE, Multi Shop, Products, WYSIWYG|
|PHP Version||Not defined|
|Database Version||Not defined|
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.
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?
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.
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.
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.
I can confirm this bug.
In EE 5.x with 1 master shop for all articles and several subshops we could edit OXLONGDESC in the subshops separately, although even then the field was _not_ stored in oxarticle, but in oxfield2shop.
After upgrading to EE 6.1.5 this did not work any more.
The problem is that when editing a subshop version of the article OXLONGDESC is correctly written to oxfield2shop but _also_ to oxartextends, thus overwriting the master shop version of OXLONGDESC.
protected function _update()
Íf you edit a subshop version of an article the if() applies, updates the field2shop table and returns.
Later in vendor/oxid-esales/oxideshop-ce/source/Application/Model/Article.php
in public function save()
$this->_saveArtLongDesc(); is called which updates the master shop version of the OXLONGDESC, which is an error.
The problem, as far as I can see, is that with the new split between EE and CE article class in EE V6.x the function
protected function _skipSaveFields()
is never called when updating the subshop version of an article.
If this function would be called then the _aSkipSaveFields array would contain OXLONGDESC and the master version of OXLONGDESC would not be updated.
In EE 5.x the function _skipSaveFields() was called within _update of the oxarticle class and everything was fine.
Another minor problem is the fact that the possibility to edit field values separately in subshops is only working when you have clicked "Allow individual price for inherited articles" in the "Mall" tab of the subshop configuration. The naming of this checkbox is misleading. For instance in our case we do not allow inherited subshop articles to have different prices from their master shop versions, but we _do_ want to edit OXSHORTDESC and OXLONGDESC in the subshop articles. So the checkbox should be renamed to something like "Allow individual values of fields defined in config.inc".