Bug #65364

_languageUid gets overwritten on updating a new domain object.

Added by Marco Huber over 4 years ago. Updated about 1 year ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Extbase
Target version:
-
Start date:
2015-02-26
Due date:
% Done:

100%

TYPO3 Version:
6.2
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

When creating a new domain object the property _languageUid is NULL. When this object gets persisted \TYPO3\CMS\Extbase\Persistence\Generic\Backend::insertObject() sets the language field to "-1" like it is described in the documentation http://docs.typo3.org/typo3cms/ExtbaseFluidBook/9-CrosscuttingConcerns/1-localizing-and-internationalizing-an-extension.html#multi-language-domain-objects. But after the insert the objects are updated (f.e. to insert missing relation ids and stuff) immediately and persisted again. \TYPO3\CMS\Extbase\Persistence\Generic\Backend::updateObject() sets "$row[$dataMap->getLanguageIdColumnName()] = $object->_getProperty('_languageUid');" and because the object's property _languageUid is NULL a 0 is inserted in the database.

So if the object was created in a multi language environment (sys_language_uid > 0) extbase doesn't find it anymore.

Solution 1:
Update the object's property _languageUid in \TYPO3\CMS\Extbase\Persistence\Generic\Backend::insertObject(). But this should be done only, if the developer hasn't set _languageUid himself (see FORGE). Then the update finds the -1 in the property _languageUid and everything works like it is documentated.

diff --git a/typo3/sysext/extbase/Classes/Persistence/Generic/Backend.php b/typo3/sysext/extbase/Classes/Persistence/Generic/Backend.php
index 8c6e3f0..b7f1efd 100644
--- a/typo3/sysext/extbase/Classes/Persistence/Generic/Backend.php
+++ b/typo3/sysext/extbase/Classes/Persistence/Generic/Backend.php
@@ -635,6 +635,7 @@ class Backend implements \TYPO3\CMS\Extbase\Persistence\Generic\BackendInterface
                $this->addCommonFieldsToRow($object, $row);
                if ($dataMap->getLanguageIdColumnName() !== NULL && ($object->_getProperty('_languageUid') === NULL || !$object->_getProperty('_languageUid'))) {
                        $row[$dataMap->getLanguageIdColumnName()] = -1;
+                       $object->_setProperty('_languageUid', -1);
                }
                if ($parentObject !== NULL && $parentPropertyName) {
                        $parentColumnDataMap = $this->dataMapper->getDataMap(get_class($parentObject))->getColumnMap($parentPropertyName);

Solution 2:
Do "$row[$dataMap->getLanguageIdColumnName()] = $object->_getProperty('_languageUid');" only if _languageUid is not NULL in \TYPO3\CMS\Extbase\Persistence\Generic\Backend::updateObject().

diff --git a/typo3/sysext/extbase/Classes/Persistence/Generic/Backend.php b/typo3/sysext/extbase/Classes/Persistence/Generic/Backend.php
index f3d89c9..c6aeb59 100644
--- a/typo3/sysext/extbase/Classes/Persistence/Generic/Backend.php
+++ b/typo3/sysext/extbase/Classes/Persistence/Generic/Backend.php
@@ -850,7 +850,9 @@ class Backend implements \TYPO3\CMS\Extbase\Persistence\Generic\BackendInterface
                $this->addCommonFieldsToRow($object, $row);
                $row['uid'] = $object->getUid();
                if ($dataMap->getLanguageIdColumnName() !== NULL) {
-                       $row[$dataMap->getLanguageIdColumnName()] = $object->_getProperty('_languageUid');
+                       if($object->_getProperty('_languageUid') !== NULL){
+                               $row[$dataMap->getLanguageIdColumnName()] = $object->_getProperty('_languageUid');
+                       }
                        if ($object->_getProperty('_localizedUid') !== NULL) {
                                $row['uid'] = $object->_getProperty('_localizedUid');
                        }

I would prefer the first solution, because it seems cleaner to me. Or should both solutions be implemented?

If someone has a good idea for a commit message I will submit a patch to gerrit.


Related issues

Related to TYPO3 Core - Bug #65363: Set _languageUid to -1 only if the developer hasn't set it himself Closed 2015-02-26
Related to TYPO3 Core - Bug #60544: Pid property not set after insert Closed 2014-07-24

Associated revisions

Revision 86ac2558 (diff)
Added by Marco Huber about 4 years ago

[BUGFIX] _languageUid property not set on insert

The patch ensures new objects are created with default language only.
Database field and object property are set properly to 0.

Furthermore the language uid is set only if not set before from outside.

Resolves: #65363
Resolves: #65364
Releases: master, 6.2
Change-Id: Ifc777e482ef12dba46938f826548a97758e531a1
Reviewed-on: http://review.typo3.org/41595
Reviewed-by: Nicole Cordes <>
Tested-by: Nicole Cordes <>
Reviewed-by: Anja Leichsenring <>
Tested-by: Anja Leichsenring <>
Reviewed-by: Daniel Goerz <>
Tested-by: Daniel Goerz <>
Reviewed-by: Morton Jonuschat <>
Tested-by: Morton Jonuschat <>

Revision 4f6d1669 (diff)
Added by Marco Huber about 4 years ago

[BUGFIX] _languageUid property not set on insert

The patch ensures new objects are created with default language only.
Database field and object property are set properly to 0.

Furthermore the language uid is set only if not set before from outside.

Resolves: #65363
Resolves: #65364
Releases: master, 6.2
Change-Id: I57c4834f7e77644620831abeeb2bc2e644f95395
Reviewed-on: http://review.typo3.org/43427
Reviewed-by: Morton Jonuschat <>
Tested-by: Morton Jonuschat <>

History

#1 Updated by Marco Huber over 4 years ago

Workaround: Set _languageUid manually.

$myObject = $objectManager->get('MyObject')
$myObject->_setProperty('_languageUid', -1); //or whatever you want, f.e. $GLOBALS['TSFE']->sys_language_uid
$myObjectRepository->add($myObject);
$persistanceManager->persistAll();

#2 Updated by Gerrit Code Review over 4 years ago

  • Status changed from New to Under Review

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/41595

#3 Updated by Gerrit Code Review about 4 years ago

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/41595

#4 Updated by Daniel Goerz about 4 years ago

Hey Marco,
could you provide the steps to reproduce this error (and maybe add a testextension to the ticket) so we can test your patch? That would be great.

#5 Updated by Marco Huber about 4 years ago

I'll try... :-)

#6 Updated by Gerrit Code Review about 4 years ago

Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/41595

#7 Updated by Gerrit Code Review about 4 years ago

Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/41595

#8 Updated by Gerrit Code Review about 4 years ago

Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/41595

#9 Updated by Gerrit Code Review about 4 years ago

Patch set 6 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/41595

#10 Updated by Gerrit Code Review about 4 years ago

Patch set 7 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/41595

#11 Updated by Gerrit Code Review about 4 years ago

Patch set 1 for branch TYPO3_6-2 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/43427

#12 Updated by Marco Huber about 4 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100

#13 Updated by Benni Mack about 1 year ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF