Skip to content
GitLab
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
  3. 08 Nov, 2017 1 commit
  5. 10 Oct, 2017 1 commit
  7. 04 Oct, 2017 1 commit
  9. 24 Jul, 2017 1 commit
  11. 14 Jun, 2017 1 commit
  13. 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
  15. 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
  17. 20 Feb, 2017 1 commit
  19. 15 Feb, 2017 1 commit
  21. 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
  23. 04 Jan, 2017 1 commit
  25. 03 Jan, 2017 1 commit
  27. 30 Aug, 2016 1 commit
  29. 08 Oct, 2015 1 commit
  31. 18 Sep, 2015 1 commit
  33. 05 Aug, 2015 1 commit
  35. 30 Jan, 2015 1 commit
  37. 13 Dec, 2014 1 commit
  39. 18 Sep, 2014 1 commit
  41. 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
  43. 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
  45. 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
  47. 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
  49. 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
  51. 12 Mar, 2014 1 commit
  53. 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
  55. 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
  57. 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
  59. 20 Feb, 2014 1 commit
  61. 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
  63. 18 Feb, 2014 1 commit
  65. 17 Feb, 2014 1 commit
  67. 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