1. 13 Nov, 2020 1 commit
  2. 12 Nov, 2020 1 commit
    • Benni Mack's avatar
      [!!!][TASK] Do not create new version placeholders in workspaces anymore · 74899ecf
      Benni Mack authored
      Creating a new record in a workspace adds two database rows.
      
      One that is the "placeholder", which - since v10.4 - contains
      the same metadata as the other record:
      
      * t3ver_wsid = workspaceID
      * t3ver_oid = 0 (simulating behavior of an "online pendant record")
      * t3ver_state = 1
      
      And the "versionized" record, identified by:
      
      * t3ver_wsid = workspaceID
      * t3ver_oid = uid of the new placeholder record
      * t3ver_state = -1
      
      As of TYPO3 v10, the first record is not needed anymore,
      the versioned record can be queried directly, however, since
      the relations (except MM) point to the placeholder record,
      this one is kept.
      
      As result, only one record is created from now on:
      
      * t3ver_wsid = workspaceID
      * t3ver_oid = 0 (no online counterpart)
      * t3ver_state = 1
      
      On reading, the record is queried directly (no overlay needed anymore!)
      with the existing Database Doctrine Restrictions. On publishing, the
      record just gets the state/stage/wsid set and is "live".
      
      This brings fundamental benefits:
      
      * No overlays needed when querying
      * Fewer database records (placeholders are not helpful)
      * Conceptual problems with placeholder and shadowed fields are removed
      
      Resolves: #92791
      Releases: master
      Change-Id: I0288cc63fe72d8442d586f309bd4054ac44e829b
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65587
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      74899ecf
  3. 12 Oct, 2020 1 commit
    • Benni Mack's avatar
      [!!!][TASK] Remove move placeholders · 27c7de8a
      Benni Mack authored and Christian Kuhn's avatar Christian Kuhn committed
      Workspaces ("Element-based versioning") previously had - due to
      the "pid=-1" logic until TYPO3 v10 - a so-called "MOVE PLACEHOLDER".
      
      This was indicated by t3ver_state = 3, all relevant fields:
      * t3ver_state = 3 (move placeholder)
      * t3ver_oid = 0 no connected live record, it allowed fetching these records
        with one query together with live records as db restrictions t3ver_oid > 0
      * t3ver_wsid = workspace UID
      * t3ver_move_id = UID of the live record
      * pid = new PID the version was moved to
      * sorting - when a record was moved within page with activated sorting
      
      Other record fields were not important. However, when moving a record, the
      value from TCA ctrl section "shadowColumnsForMovePlaceholders" was used to
      fill in gaps from the live record.
      
      The ACTUAL versioned record was indicated by t3ver_state = 4, the so-called
      "MOVE POINTER". In previous version until TYPO3 v10, it's PID field was set
      to -1, but since TYPO3 v10, it has the same PID as the "MOVE PLACEHOLDER".
      
      Characteristics of the move pointer as of TYPO3 v10:
      * t3ver_state = 4 (move pointer)
      * t3ver_oid = UID of the live record
      * t3ver_wsid = workspace UID
      * t3ver_move_id = 0
      * pid = PID the version was moved to
      * sorting - same value as the live record (not evaluated until now)
      * All other fields with optionally modified content
      
      Both move placeholder and move pointer did not know each other directly.
      Fetching the move pointer for a move placeheldor (or the other way around)
      involved the live record, leading to many queries.
      
      The patch obsoletes the move placeholder records, moving necessary
      information to the move pointer: It now contains the updated sorting
      and is considered in the Database Restrictions to be fetched.
      
      In general, when publishing, the moved record now
      behaves identical to the other versioned types.
      
      This makes the internal code much easier, creates less DB queries
      on read + write and leads to less DB records in the database.
      
      The change removes creation of move placeholders, and considers the
      move pointers when evaluating sorting and PID in DataHandler.
      
      Read functionality from BackendUtility and PageRepository don't need an
      additional step to fetch the live version of a move placeholder anymore.
      
      An upgrade wizard takes existing move placeholders (state=3), updates
      pid+sorting (PID generally not needed, just to be sure) of the move
      pointer (state=4) and then deletes the move placeholder.
      
      TCA definition $TCA[my-table][ctrl][shadowColumnsForMovePlaceholders]
      is not needed anymore and removed by an auto TCA migration.
      
      Finally, workspace enabled tables do not need the t3ver_move_id field
      anymore: The live record UID is already in t3ver_oid field for state=4
      records, just like with all other versioned records. The field will
      be fully removed with a separate patch in order to keep the actual CSV
      tests readable for this patch.
      
      Resolves: #92497
      Releases: master
      Change-Id: I206336aec8be8a324fefdfd69f648f5a298c6ad1
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65797
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      27c7de8a
  4. 07 Sep, 2020 1 commit
  5. 31 Jul, 2020 1 commit
  6. 22 May, 2020 1 commit
  7. 28 Apr, 2020 1 commit
  8. 15 Apr, 2020 1 commit
  9. 14 Apr, 2020 2 commits
  10. 13 Apr, 2020 1 commit
  11. 15 Jan, 2019 1 commit
  12. 01 Oct, 2018 1 commit
  13. 19 Sep, 2018 1 commit
  14. 15 Sep, 2018 1 commit
  15. 05 Mar, 2018 1 commit
  16. 13 Jan, 2018 2 commits
  17. 23 Aug, 2017 1 commit
  18. 28 Apr, 2017 2 commits
  19. 03 Apr, 2017 1 commit
  20. 14 Feb, 2017 1 commit
  21. 10 Feb, 2017 1 commit
  22. 07 Feb, 2017 2 commits
    • Helmut Hummel's avatar
      [FEATURE] Add new imageManipulation supporting multiple crop variants · 06393839
      Helmut Hummel authored and Andreas Fernandez's avatar Andreas Fernandez committed
      This feature extends the image cropping tool in the backend
      so that editors can now not only select one crop area,
      but multiple ones per image.
      
      Within the crop are now also a focus are can be selected
      and to preview areas that will be covered once the image
      is rendered in the frontend one or more cover areas can be configured
      to be shown inside the crop area.
      
      This change also adds a format.json view helper and a view helper
      to generate backend URIs that are used in the now fully Fluid rendered
      imageManipulation element.
      
      This is the TYPO3 integration part. TypeScript and CSS
      will be done in a second commit.
      
      Resolves: #75880
      Releases: master
      Change-Id: I646f0f0a149d05d1f3d8283bcc92ab09aede768e
      Reviewed-on: https://review.typo3.org/51515
      
      
      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: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <typo3@scripting-base.de>
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <typo3@scripting-base.de>
      06393839
    • 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
  23. 12 Jan, 2017 1 commit
  24. 11 Jan, 2017 2 commits