This project is mirrored from https://git.typo3.org/typo3/typo3.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer or owner.
Last successful update .
  1. 15 Nov, 2017 1 commit
  2. 08 Nov, 2017 1 commit
  3. 10 Oct, 2017 1 commit
  4. 04 Oct, 2017 1 commit
  5. 24 Jul, 2017 1 commit
  6. 14 Jun, 2017 1 commit
  7. 07 Jun, 2017 1 commit
    • Christian Kuhn's avatar
      [BUGFIX] mssql: Proper types inserting / updating rows · 325d95b9
      Christian Kuhn authored and Frank Nägler's avatar Frank Nägler committed
      MS SQL server is more picky about types than postgres and
      mysql. This is especially true for LOB columns - even empty
      strings need a proper cast and specific handling.
      
      Various parts of the core deal with arbitrary tables and
      don't know if a column is int, text or lob, or whatever.
      Those are blindly updated / inserted, resulting in mssql
      saying "no".
      
      Solution is to fetch column schema and to set proper types
      based on that schema. This is expensive. We will have to
      refactor that again, and we will probably end up with a
      (cache?) entry that knows the entire table schema of an
      instance.
      
      Solving that in a good way would also fix various mysql strict
      issues we still have in the core. However, this needs more work.
      
      Goal of the current patch is to bring mssql to a working state.
      The solution must be seen as hacky, but is restricted to that
      platform only and can be relaxed and improved as soon as we
      take the next steps with schema handling in the TYPO3 core.
      
      Change-Id: I9b582a9bde7461cfbcc2414192518fb7b7b1341d
      Resolves: #81498
      Releases: master, 8.7
      Reviewed-on: https://review.typo3.org/53150
      
      
      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: Frank Nägler's avatarFrank Naegler <frank.naegler@typo3.org>
      Tested-by: Frank Nägler's avatarFrank Naegler <frank.naegler@typo3.org>
      325d95b9
  8. 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
  9. 20 Feb, 2017 1 commit
  10. 15 Feb, 2017 1 commit
  11. 07 Feb, 2017 1 commit
    • 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
  12. 04 Jan, 2017 1 commit
  13. 03 Jan, 2017 1 commit
  14. 30 Aug, 2016 1 commit
  15. 08 Oct, 2015 1 commit
  16. 18 Sep, 2015 1 commit
  17. 05 Aug, 2015 1 commit
  18. 30 Jan, 2015 1 commit
  19. 13 Dec, 2014 1 commit
  20. 18 Sep, 2014 1 commit
  21. 22 Jun, 2014 1 commit
    • Michael Schams's avatar
      [TASK] Re-work/simplify copyright header in PHP files - Part 4 · 60eb4f47
      Michael Schams authored
      This patch replaces the copyright/license header in PHP files with a
      new, simplified one. The new header does not show the year figure, nor
      an author name, and refers to the LICENSE.txt file for the full
      copyright information. License is: GPL2 or any later version.
      
      This is a multi-part commit due to the huge number of changed files.
      See issue #59780 for further details.
      
      Resolves: #59780
      Releases: 6.3, 6.2
      Change-Id: I00eff31cdff19774527e3b1bb06e29152928414c
      Reviewed-on: https://review.typo3.org/31025
      Reviewed-by: Krzysztof Adamczyk
      Tested-by: Krzysztof Adamczyk
      Reviewed-by: Markus Klein
      Tested-by: Markus Klein
      60eb4f47
  22. 13 Jun, 2014 1 commit
    • Oliver Hader's avatar
      [TASK] Restructure functional frontend tests · 26819f9e
      Oliver Hader authored and Oliver Hader's avatar Oliver Hader committed
      In the scope of enabling Extbase frontend rendering during
      functional test runs, the response object contains multiple
      data values for TypoScript ("default") and the called Extbase
      actions. Processing them all at once just has practical reasons
      to avoid additional frontend requests for each aspect.
      To decouple the actual testing structure from assertions
      and constraints, a new Contraint namespace has been introduced.
      
      The irre_tutorial extension has been enriched with an accordant
      frontend rendering for Extbase context to return structured JSON
      data like in the current frontend tests.
      
      This change contains Extbase TypoScript which will be activated
      in a separate bugfixing change.
      
      Resolves: #59521
      Releases: 6.2
      Change-Id: I42c0bf8957d9c4c1e4389049695512851b436d14
      Reviewed-on: https://review.typo3.org/30687
      Reviewed-by: Wouter Wolters
      Tested-by: Wouter Wolters
      Reviewed-by: Oliver Hader
      Tested-by: Oliver Hader
      26819f9e
  23. 16 May, 2014 3 commits
    • Oliver Hader's avatar
      [TASK] Cleanup DataHandler functional tests · 8b264890
      Oliver Hader authored and Christian Kuhn's avatar Christian Kuhn committed
      Some DataHandler functional test cases are duplicated or are not
      required anymore. Here's a list of what has changed and moved
      into some existing testing structure:
      
      Core:
      * DataHandlerTest::canCreateTtContent
      ** Regular\Modify\ActionTest::createContents
      * DataHandlerTest::canLocalizeTtContent
      ** Regular\Modify\ActionTest::localizeContent
      * DataHandlerTest::canCopyPasteTtContent
      ** Regular\Modify\ActionTest::copyPasteContent
      * DataHandlerTest::canCutPasteTtContent
      ** Regular\Modify\ActionTest::movePasteContentToDifferentPage
      * IRRE\MtoNMMAsymetricLocalizationKeepTest::*
      ** IRRE\CSV\Modify\ActionTest::localizeParentContent*
      ** IRRE\ForeignField\Modify\ActionTest::localizeParentContent*
      * IRRE\MtoNMMAsymetricLocalizationSelectTest::*
      ** IRRE\CSV\Modify\ActionTest::localizeParentContent*
      ** IRRE\ForeignField\Modify\ActionTest::localizeParentContent*
      
      Workspaces:
      * IRRE\MToNMMTest::*
      ** ManyToMany\Modify\ActionTest::*
      ** ManyToMany\Publish\ActionTest::*
      ** ManyToMany\PublishAll\ActionTest::*
      * IRRE\OneToNCSVTest::*
      ** IRRE\CSV\Modify\ActionTest::*
      ** IRRE\CSV\Publish\ActionTest::*
      ** IRRE\CSV\PublishAll\ActionTest::*
      * IRRE\OneToNForeignFieldTest::*
      ** IRRE\ForeignField\Modify\ActionTest::*
      ** IRRE\ForeignField\Publish\ActionTest::*
      ** IRRE\ForeignField\PublishAll\ActionTest::*
      
      Resolves: #58870
      Releases: 6.2
      Change-Id: I0c75fcf826d05f8515a5609cb00c153992ba7b44
      Reviewed-on: https://review.typo3.org/30177
      Reviewed-by: Christian Kuhn
      Tested-by: Christian Kuhn
      8b264890
    • Oliver Hader's avatar
      [TASK] Extend DataHandler IRRE functional tests · b36a41ab
      Oliver Hader authored and Christian Kuhn's avatar Christian Kuhn committed
      Extend CSV and ForeignField test with
      * copyParentContentToDifferentPage
      * modifyHotelChild
      
      Resolves: #58854
      Releases: 6.2
      Change-Id: Iba332ccee1728bf1e28ff5719029b6ab73a30c53
      Reviewed-on: https://review.typo3.org/30176
      Reviewed-by: Christian Kuhn
      Tested-by: Christian Kuhn
      b36a41ab
    • Oliver Hader's avatar
      [TASK] Unify DataHandler test structure · 34181bbc
      Oliver Hader authored and Christian Kuhn's avatar Christian Kuhn committed
      Resolves: #58868
      Releases: 6.2
      Change-Id: I0f5aeb1d211e542cb323fba11b07a0b8be7d3ed0
      Reviewed-on: https://review.typo3.org/30175
      Reviewed-by: Christian Kuhn
      Tested-by: Christian Kuhn
      34181bbc
  24. 22 Mar, 2014 1 commit
    • Oliver Hader's avatar
      [BUGFIX] Invalid relations of IRRE records in workspaces · 740b4435
      Oliver Hader authored and Oliver Hader's avatar Oliver Hader committed
      * general -> always use live id as pointer value
      * create records -> automatically fill placeholder pointers
      * copy records -> currently leads to problems with sorting
      * move records -> follow and create child move placeholders
      * delete records -> forward delete data in copy(!) process
      * ReferenceIndex needs to hold the most specific relations
        since the CommandMap handler is based on this information
      * ReleationHandler is extended for IRRE references to fetch
        the live default parent pointer automatically (this new
        behaviour can be disabled by public methods for each
        RelationHandler instance)
      * The method version_swap_procBasedOnFieldType of the version
        DataHandlerHook is completely removed since IRRE records are
        now referenced using the live default parent pointer value
      * UserTSconfig property options.workspaces.swapMode is set
        to "pages" per default - thus, if a page gets published all
        accordant records on that page are published as well
      
      Resolves: #56376
      Releases: 6.2
      Change-Id: I75248d10b000de73ca623770f07e8c2e89d4cdd8
      Reviewed-on: https://review.typo3.org/27774
      Reviewed-by: Oliver Hader
      Tested-by: Oliver Hader
      740b4435
  25. 17 Mar, 2014 1 commit
    • Alexander Stehlik's avatar
      [BUGFIX] Avoid superfluous IRRE child record duplication · c81102bf
      Alexander Stehlik authored and Oliver Hader's avatar Oliver Hader committed
      If copying a page, all records on that page will be copied to
      the accordant destination page. IRRE parent-child structures
      are cloned along the way as well. However, if a table (that is
      defined a IRRE child) is processed before the accordant parent
      record, the parent itself will duplicate its children again.
      This behaviour leads to superfluous duplicates and is wrong.
      
      A check in DataHandler::copyRecord_procBasedOnFieldType() now
      ensures that records are only copied once during the accordant
      DataHander copy process.
      
      Resolves: #44795
      Releases: 6.2
      Change-Id: Ia1e4129432f37c0dd6bfedb5fd69394e2c244d34
      Reviewed-on: https://review.typo3.org/26552
      Reviewed-by: Oliver Hader
      Tested-by: Oliver Hader
      c81102bf
  26. 12 Mar, 2014 1 commit
  27. 11 Mar, 2014 1 commit
    • Oliver Hader's avatar
      [TASK] Add Publish and PublishAll DataHandler workspaces tests · 0bf260e1
      Oliver Hader authored and Oliver Hader's avatar Oliver Hader committed
      Extend current functional action tests with those actions:
      * modification (Modify)
      * publish single records (Publish)
      * publish all records in a workspace (PublishAll)
      
      The Publish and PublishAll tasks extend the accordant basic
      Modify functional tests.
      
      Resolves: #56708
      Related: #56710
      Releases: 6.2
      Change-Id: I1f7a70df39585c29b3b4ff5675b5147610f254f2
      Reviewed-on: https://review.typo3.org/28236
      Reviewed-by: Wouter Wolters
      Tested-by: Wouter Wolters
      Reviewed-by: Oliver Hader
      Tested-by: Oliver Hader
      0bf260e1
  28. 08 Mar, 2014 1 commit
    • Oliver Hader's avatar
      [BUGFIX] Unnatural processing order in IRRE tests · 47b292af
      Oliver Hader authored and Jigal van Hemert's avatar Jigal van Hemert committed
      The IRRE tests for creating and modifying records first process
      offer, hotel then content which is the unnatural order compared
      to the processing delivered by the FormEngine (t3lib_TCEforms).
      To avoid incorrect testing behaviour and invalid testing
      results, the order is changed to content, hotel and offer
      (parent to child).
      
      Resolves: #56374
      Releases: 6.2
      Change-Id: Ib14fc2d50b493e4be982faeba77401b320868639
      Reviewed-on: https://review.typo3.org/27887
      Reviewed-by: Wouter Wolters
      Tested-by: Wouter Wolters
      Reviewed-by: Jigal van Hemert
      Tested-by: Jigal van Hemert
      47b292af
  29. 24 Feb, 2014 1 commit
    • Oliver Hader's avatar
      [TASK] Windows issues with long file names in Git sources · 77e287f7
      Oliver Hader authored and Oliver Hader's avatar Oliver Hader committed
      The recent DataHander functional tests integrate file names that
      are very long since they contain a description of what actually
      is expected in the accordant test assertion file.
      
      However, Windows has a limit of 260 characters per file path.
      The longest file path of the mentioned functional tests has been
      223 characters and is now reduced to 166 characters.
      
      Resolves: #56177
      Releases: 6.2
      Change-Id: I1490a3f0fae7ef40547d81e304cb98077ab6142b
      Reviewed-on: https://review.typo3.org/27815
      Reviewed-by: Marc Bastian Heinrichs
      Reviewed-by: Oliver Hader
      Tested-by: Oliver Hader
      77e287f7
  30. 20 Feb, 2014 1 commit
  31. 19 Feb, 2014 1 commit
    • Oliver Hader's avatar
      [TASK] Enable DataHandler frontend rendering tests · 3376a5e6
      Oliver Hader authored and Oliver Hader's avatar Oliver Hader committed
      After having performed changes to data structures using the
      DataHandler, the correct impact for the frontend needs to be
      asserted. This patch checks the correct behavior for DataHandler
      action tests for regular, MM and IRRE disposal.
      
      Resolves: #56104
      Releases: 6.2
      Change-Id: I99f11f6b039c31e08614caf8ee9bca9d47700b93
      Reviewed-on: https://review.typo3.org/27711
      Reviewed-by: Oliver Hader
      Tested-by: Oliver Hader
      3376a5e6
  32. 18 Feb, 2014 1 commit
  33. 17 Feb, 2014 1 commit
  34. 02 Feb, 2014 1 commit
    • Oliver Hader's avatar
      [TASK] Add functional test cases to DataHandler (live) · 46574717
      Oliver Hader authored and Oliver Hader's avatar Oliver Hader committed
      This change-set adds new functional tests for the DataHandler
      to ensure the correct behaviour in the Live Workspace. The
      difference to current functional tests is, that here a more
      complete picture is checked in the database instead of only
      particular ids and values.
      
      The tests use a DataSet, which is basically only a CSV file
      that hold the record values for required tables. These CSV
      files can easily be modified by any spreadsheet application.
      The "Scenario" DataSets are used to define the scenario each
      test case is based on - the "Assertion" DataSets are used to
      acutally assert that the correct processing was done in
      the DataHandler.
      
      Resolves: #54855
      Releases: 6.2
      Change-Id: I5d748cde04a70b9c158d09f9a0bd337ef809fd02
      Reviewed-on: https://review.typo3.org/27188
      Reviewed-by: Peter Kuehn
      Tested-by: Peter Kuehn
      Reviewed-by: Anja Leichsenring
      Tested-by: Anja Leichsenring
      Reviewed-by: Oliver Hader
      Tested-by: Oliver Hader
      46574717