1. 05 May, 2021 2 commits
  2. 27 Jan, 2020 1 commit
  3. 08 Feb, 2019 1 commit
    • Oliver Hader's avatar
      [BUGFIX] Keep language reference for children using l10n_mode=exclude · 20715ad2
      Oliver Hader authored and Benni Mack's avatar Benni Mack committed
      Having 1:n child associations being defined as l10n_mode=exclude on their
      parent side, currently leads to deleting and recreating the child entity
      (re-synchronization). For composite relations (children can only exist
      with their parent - usually accessed through their parent as aggregate
      root) this is "okay" in terms of domain-driven design.
      
      However having large data-sets leads to performance impact during the
      re-synchronization process.
      
      In the current scenario children processed with l10n_mode=exclude did not
      have any pointer to their language origin (due to l10n_parent not being
      set). This change copies these children and applies the same values as
      used for localizations - without actually invoking the localization
      process.
      
      For l10n_mode=exclude children this means, the sys_language_uid and
      l10n_parent values are now set - which have been empty before.
      
      Resolves: #87640
      Releases: master, 9.5
      Change-Id: I3d862f536603b9e49c7a5d3205ccfc2b4e2e9532
      Reviewed-on: https://review.typo3.org/59667
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      20715ad2
  4. 29 Sep, 2018 1 commit
  5. 16 May, 2018 1 commit
    • Christian Kuhn's avatar
      [TASK] Streamline TSconfig API · 45c582a8
      Christian Kuhn authored
      Final patch to de-mess the user / page TSconfig related API.
      
      Page TSconfig can be overriden in user TSconfig by prefixing the
      path with 'page.' in user TSconfig. However, method
      BackendUtility::getModTSconfig() violated this principle and
      had a special merge strategy that allowed ommitting the 'page.'
      prefix. This has been marked as deprecated in the TSconfig docs for
      various years and has been lately removed in the docs altogether,
      but the code still existed.
      The patch moves this merge into BackendUtility::getPagesTSconfig()
      and properly deprecates this case. Usages of getModTSconfig() are
      changed to use getPagesTSconfig() directly, dropping the artificial
      'properties' and 'value' sub arrays and omitting some rather expensive
      string operations at the same time.
      This obsoletes getModTSconfig() and a couple of related methods.
      
      Additionally, BackendUserAuthentication->getTSConfig() has been
      abused frequently to operate on different arrays than it's own userTS.
      Those usages are dropped with the patch. Handing over arguments to
      getTSConfig() is now deprecated, effectively reducing the method a getter.
      
      This reduces the API down to BackendUtility::getPagesTSconfig($pid)
      and BackendUserAuhtentiction->getTSConfig() both just returning the
      entire array. This simplified API can now be documented in the docs.
      
      Change-Id: I4bbb066c1d4e2edbc0182f7967897a1558cc3c0d
      Resolves: #85016
      Related: #84982
      Releases: master
      Reviewed-on: https://review.typo3.org/56968
      
      
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: Jan Helke's avatarJan Helke <typo3@helke.de>
      Tested-by: Jan Helke's avatarJan Helke <typo3@helke.de>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      45c582a8
  6. 02 Mar, 2018 1 commit
  7. 20 Feb, 2018 1 commit
  8. 12 Feb, 2018 1 commit
  9. 13 Jan, 2018 1 commit
  10. 27 Nov, 2017 1 commit
  11. 16 Nov, 2017 1 commit
  12. 08 Nov, 2017 1 commit
  13. 17 Oct, 2017 1 commit
  14. 23 Aug, 2017 2 commits
  15. 24 Jul, 2017 1 commit
  16. 14 Jun, 2017 2 commits
  17. 12 May, 2017 1 commit
  18. 04 Apr, 2017 1 commit
  19. 03 Apr, 2017 1 commit
  20. 23 Mar, 2017 1 commit
  21. 12 Mar, 2017 1 commit
  22. 11 Mar, 2017 1 commit
    • Oliver Hader's avatar
      [BUGFIX] Add allowLanguageSynchronization chain resolving · e7217da4
      Oliver Hader authored and Oliver Hader's avatar Oliver Hader committed
      Currently the localization behavior does not consider localization
      chains concerning field values to be synchronized over multiple
      localization hops that use the relative l10n_state "source".
      
      Imagine the following scenario of content elements:
      * { uid:10, sys_language_uid:0, l18n_parent:0, l10n_source:0,
          header:Value, l10n_state:null }
      * { uid:11, sys_language_uid:1, l18n_parent:10, l10n_source:10,
          header:Value, l10n_state:{header:parent} }
      * { uid:12, sys_language_uid:2, l18n_parent:10, l10n_source:11,
          header:Value, l10n_state:{header:source} }
      
      Now if the record of the default language (uid:10) will be updated and
      the header value set to "Modified", only direct dependents would be
      synchronized. The automated update of the direct-child localization
      record (uid:11) does not trigger another update for the grand-child
      localization (uid:12).
      To achieve this, the data-map processor has been extended to collect
      new modifications to the data-map caused by synchronization processes
      - as long as modifications could be determined, another synchronization
      round is triggered for the modified items.
      This way the localization chain is completely synchronized if required,
      depending on the according l10n_state settings.
      
      Change-Id: Ic08460f3ed0071f3dca6c6d1666031895bc3d832
      Resolves: #80141
      Releases: master
      Reviewed-on: https://review.typo3.org/51952
      
      
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Tested-by: Susanne Moog's avatarSusanne Moog <susanne.moog@typo3.org>
      Reviewed-by: Susanne Moog's avatarSusanne Moog <susanne.moog@typo3.org>
      Reviewed-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
      Tested-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
      e7217da4
  23. 06 Mar, 2017 1 commit
  24. 27 Feb, 2017 1 commit
  25. 24 Feb, 2017 1 commit
  26. 20 Feb, 2017 1 commit
  27. 16 Feb, 2017 1 commit
  28. 15 Feb, 2017 1 commit
  29. 14 Feb, 2017 4 commits
  30. 10 Feb, 2017 1 commit
  31. 07 Feb, 2017 2 commits
    • Wouter Wolters's avatar
      [TASK] Fix PSR-2 violations with php-cs-fixer · 61a0ef65
      Wouter Wolters authored and Christian Kuhn's avatar Christian Kuhn committed
      Resolves: #79668
      Releases: master
      Change-Id: I78b9b85a5af2170ddb725dee969f090be1d444e3
      Reviewed-on: https://review.typo3.org/51566
      
      
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <typo3@scripting-base.de>
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <typo3@scripting-base.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      61a0ef65
    • Oliver Hader's avatar
      [FEATURE] Introduce allowLanguageSynchronization · 2fd70c83
      Oliver Hader authored and Christian Kuhn's avatar Christian Kuhn committed
      This feature introduces a new functionality called
      "allowLanguageSynchronization" which can be set on a field
      configuration of a TCA column. This is the successor of
      "l10n_mode=mergeIfNotBlank" as the old option had several
      conceptual downsides:
      
      1) "mergeIfNotBlank" took the value of the default record
         during runtime, but only if the translation field was empty.
         This means it was not possible to see what the record
         actually contained without having all fields of the parent
         at hand.
      
      2) It was not possible to have a value "santa" in the original
         record but remove the option in a translation (because an
         empty string "" implicitly triggered the runtime call in the
         frontend)
      
      3) "mergeIfNotBlank" did not work on relations except for files
         fetched via the FileRepository API calls, but for no other
         inline elements.
      
      4) "mergeIfNotBlank" did the overlay functionality in the frontend,
         but only FormEngine and DataHandler took care of the option.
         Custom backend modules had to implement the same functionality.
      
      5) In FormEngine, there was an icon in the translation record that
         if the record kept empty the value of the original language was
         taken, but this is not optimal in terms of usability.
      
      6) "mergeIfNotBlank" did not take the new l10n_source option into
         account, where localizations could be made from other records
         than the default language "0".
      
      The new feature can be set on any TCA column setting:
      
      $GLOBALS['TCA'][<table-name>]['columns']
      	[<field-name>]['config']['behaviour']
      		['allowLanguageSynchronization'] = true;
      
      This brings an option to records with translations (both from
      l10n_parent and l10n_source) to have the value for all translations
      synchronized or explictly have a checkbox to use a custom value.
      
      The information whether a field is custom filled, or kept in sync
      from l10n_parent/l10n_source is stored in a separate field called
      "l10n_state" inside the database.
      
      The introduced upgrade wizard and TCA migration to remove
      "l10n_mode=mergeIfNotBlank" has been modified to migrate to this
      option and add a l10n_state database field if a TCA table used
      "mergeIfNotBlank" but did not add the l10n_state field manually
      via ext_tables.sql yet.
      
      New extensions can easily use the new option right away,
      extensions that need to stay compatible with v7 and v8 can add
      both options right away to have the same output.
      
      The main goals to achieve with this change is now:
      
      * Have consistent database values for all records regardless
        of l10n_mode=mergeIfNotBlank paving the way to fetch translated
        records without having to overlay (once l10n_mode=exclude is
        also copying values and relations)
      * Be more explicit for editors about records that have a different
        or the same state as their l10n_parent/l10n_source as a benefit
        for bigger instances with a lot of languages
      * Avoid hidden magic when retrieving localized records in the
        TYPO3 Frontend.
      
      Resolves: #79658
      Related: #79243
      Releases: master
      Change-Id: I6c2dbfeb09b47f958a536c9ab050c24ba4bbcbbd
      Reviewed-on: https://review.typo3.org/51291
      
      
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: Frans Saris's avatarFrans Saris <franssaris@gmail.com>
      Tested-by: Frans Saris's avatarFrans Saris <franssaris@gmail.com>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Tested-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      2fd70c83