[BUGFIX] Pass field name variable to flexform DS utility

A field name parameter is not being passed from within
DataHandler when copying a record which has a FlexForm
DF associated with it. This causes dynamic FlexForm DS
definitions to not be able to depend on the field name,
in turn causing the problem that an incorrect DS may be
returned from the DS utility which makes TYPO3 process
the data value incorrectly (for example, not detecting
file fields and processing the values accordingly).

To solve this the $field parameter is passed.

Resolves: #59423
Releases: 6.3, 6.2, 6.1
Change-Id: Icfafd553f76e17ad5db651bb3f5dea52b140dcf7
Reviewed-on: https://review.typo3.org/30891
Reviewed-by: Markus Klein
Tested-by: Markus Klein
[BUGFIX] Use system locale when indexing external documents

If paths or filenames of external documents contain utf-8 characters
the system locale must be used. Functions like escapeshellarg and
basename are locale aware.

Change-Id: I50a73a42d60de569c63e5ba27ad6a6a3a66fd6c8
Fixes: #30244
Releases: 4.5, 6.0, 6.1, 6.2
Reviewed-on: https://review.typo3.org/26918
Reviewed-by: Markus Klein
Tested-by: Markus Klein
[BUGFIX] Followup to "system locale when indexing"

A backport mistake happened letting the jpeg file extension
vanish. Undo that mistake.

Resolves: #30244
Releases: 6.1
Change-Id: I9e12485f03b5f4f468920e47b81308de2e0c6a4a
Reviewed-on: https://review.typo3.org/30897
Reviewed-by: Markus Klein
Tested-by: Markus Klein
[BUGFIX] Treat link handler links as internal URLs

The RteHtmlParser will now check if a scheme found by parse_url()
matches a configured typolinkLinkHandler. If this is the case the
link will be treated as internal.

Resolves: #49036
Releases: 6.3, 6.2, 6.1
Change-Id: Ie4e6bded7a1c4d0c61e4f1a20bc23115612c1519
Reviewed-on: https://review.typo3.org/30976
Reviewed-by: Markus Klein
Tested-by: Markus Klein
[BUGFIX] Fix empty globalString LIT condition comparison

An empty "LIT:" condition results in NULL, so the strict compare
doesn't match with the empty string.

Solution is to cast the haystack to string before, like it was
done anyway later in the preg_match.

Releases: 6.3, 6.2, 6.1
Resolves: #59344
Change-Id: I1e4b00e454d921eedd0c03a1767d4ec57c321bd7
Reviewed-on: https://review.typo3.org/30992
Reviewed-by: Markus Klein
Tested-by: Markus Klein
[BUGFIX] Remove misspelled setting rootlevel for sys_file_collection

The correct setting would have been rootLevel. So it was never
evaluated, remove it.

Resolves: #59773
Releases: 6.3, 6.2, 6.1
Change-Id: I594924caed47c5c911def94524148354790b77b4
Reviewed-on: https://review.typo3.org/31012
Reviewed-by: Philipp Gampe
Tested-by: Philipp Gampe
Revert "[BUGFIX] Inaccessible pages on shortcuts/PageNotFound handler"

This introduced a regression. It turns out that it needs more work
to get all cases covered correctly.

Resolves: #58728
Reverts: #16472
Releases: 6.1, 6.2, 6.3

This reverts commit 203c1eb9d1c621726be57268619b7b48ffbffeb6

Change-Id: I469461a042f37757daafbf23d27a73ad236fcb50
Reviewed-on: https://review.typo3.org/31041
Reviewed-by: Helmut Hummel
Tested-by: Helmut Hummel
[!!!][BUGFIX] Content Object instances are reused

The ContentObjectRenderer creates instances for each content
object to be rendered, e.g. TEXT, COA, CONTENT, etc. However,
these instances are re-used and therefore we introduced work
arounds since serialization of FLUIDTEMPLATE failed back then.
If dealing with nested record sets using RECORDS or CONTENT,
reusing objects might be tricky since the parent pointer to the
ContentObjectRenderer might be wrong and strange things happen.

This patch removes the pseudo singleton approach since the
objects are not state-less and might lead to unexpected
results in rare cases.

Resolves: #55941
Releases: 6.2
Change-Id: I043a31403c05b87e1591f0e0237effa21bf93c98
Reviewed-on: https://review.typo3.org/27586
Reviewed-by: Markus Klein
Tested-by: Markus Klein
Reviewed-by: Stefan Neufeind
Tested-by: Stefan Neufeind
Reviewed-by: Helmut Hummel
Tested-by: Helmut Hummel
[FEATURE] Introduce MM_oppositeUsage property

On copying a sys_category record, a new MM reference is created,
however without setting the "fieldname". This value is basically
defined from the opposite entity with MM_match_fields, but
cannot be accessed.

This change introduces the MM_oppositeUsage property for MM
definitions in the TCA.

Example:
'config' => array(
  'allowed' => '*',
  'MM' => 'tx_myextension_first_second_mm',
  'MM_oppositeUsage' => array(
    'tt_content' => array('somefield'),
    'tx_myextension_domain_model' => array('some_property'),
  ),
),

Resolves: #56061
Documentation: #56123
Releases: 6.2
Change-Id: I26fd54688cf44d6a026ccdb3ca9276583b32acd3
Reviewed-on: https://review.typo3.org/27677
Reviewed-by: Wouter Wolters
Reviewed-by: Ernesto Baschny
Tested-by: Wouter Wolters
Reviewed-by: Oliver Hader
Tested-by: Oliver Hader
[BUGFIX] Use MM_oppositeUsage for category relations

The MM_oppositeUsage property allows to apply match fields
of the opposite relation to MM records. This feature shall
be enabled for sys_category records as well.

Resolves: #56122
Related: #56061
Releases: 6.2
Change-Id: I33c9f3c471d66c4154be5c2fb5180254401096f0
Reviewed-on: https://review.typo3.org/27731
Reviewed-by: Wouter Wolters
Tested-by: Wouter Wolters
Reviewed-by: Oliver Hader
Tested-by: Oliver Hader
[BUGFIX] moveContentRecordToDifferentPageAndChangeSorting fails

In a workspace, an existing content record is moved to an
existing page. Another existing record is moved after the
previously moved record on the target page. The Functional
Tests show, that the content records are faulty after the
processing and the first content record disappeared.

A similar behaviour has been discovered for pages which finally
lead to the regression causing this bug in issue #33104. Back
then a hook has been introduced for moving page records and
post-processing the database values. However, this hook has
been called for all move operations for any table and was wrong
in terms of the expected specific problem to be solved.

The hook gets reverted, since it's sufficient to resolve move
placeholders if a record shall be created after an existing one.

Resolves: #55573
Releases: 6.2
Change-Id: Ie5cbc95daf4d46f4204cf18e80e17ff4fa37f496
Reviewed-on: https://review.typo3.org/27733
Reviewed-by: Wouter Wolters
Tested-by: Wouter Wolters
Reviewed-by: Oliver Hader
Tested-by: Oliver Hader
[BUGFIX] Avoid superfluous IRRE child record duplication

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
[FEATURE] Introduce shadowColumnsForMovePlaceholders property

$TCA[<table>]['ctrl']['shadowColumnsForMovePlaceholders'] behaves
similar to shadowColumnsForNewPlaceholders but is only used for
move placeholders.

If shadowColumnsForMovePlaceholders is not defined in particular
for a table, but shadowColumnsForNewPlaceholders is defined,
then that value is used as a fallback - since that property
existed for a longer time already.

Resolves: #56994
Documentation: #56749
Releases: 6.2
Change-Id: Icdbd35234efae8162cfb2dc15a2838acd22370b1
Reviewed-on: https://review.typo3.org/28473
Reviewed-by: Oliver Hader
Tested-by: Oliver Hader
[FEATURE] Save current workspace in ReferenceIndex

To reduce queries to accordant relations saved in the reference
index, add the current workspace that is used. This information
will be used later during publishing nested record sets (e.g.
for Inline Relational Record Editing).

Resolves: #56977
Releases: 6.2
Change-Id: I92851e243581a525bb99fafc9ed656fd613eeb82
Reviewed-on: https://review.typo3.org/28472
Reviewed-by: Wouter Wolters
Reviewed-by: Oliver Hader
Tested-by: Oliver Hader
[BUGFIX] Invalid relations of IRRE records in workspaces

* 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
[BUGFIX] Invalid relations of MM records in workspaces

The basic problem with MM (ManyToMany) relations in workspaces is
that the intermediate table (MM table) does not have any
information about actually being a reference in a particular
workspace - there is no "t3ver_wsid" field. Thus, the meaning of
a relation needs to be determined from the entities on both sides
of the relation. The following is possible:

* both sides are live -> valid in live only
* exactly one side is versioned -> valid in a workspace only
* both sides are versioned -> valid in a workspace only

The difficulties now start with versioning one side first and
after some time the other side - thus the relation with exactly
one version and one live entity needs to be turned into an entry
pointing to both versions.

Resolves: #57169
Releases: 6.2
Change-Id: Idb043d520c30f15e85d54a016e52690f5f05cedc
Reviewed-on: https://review.typo3.org/28624
Reviewed-by: Oliver Hader
Tested-by: Oliver Hader
[TASK] Refactor element dependency resolving

Dependency element resolving of nested data structures currently
is used in CommandMap only. However the logic can be used for
other tasks as well, like e.g. showing nested structures in the
workspaces module. Callback methods are extracted to the new
ElementEntityProcessor to reduce further code duplication.

Resolves: #57231
Releases: 6.2
Change-Id: If588e2c644fb897f0ac5f7aaf4f341ce8ac5c232
Reviewed-on: https://review.typo3.org/28700
Reviewed-by: Oliver Hader
Tested-by: Oliver Hader
[BUGFIX] Check WorkspaceEnabled for MM field related table

If you try to edit a MM field associated to a table which doesn't use
versioning (t3ver_* fields are missing) you get a database error.
This patch adds a check if versioning for the table is enabled.

Resolves: #57291
Releases: 6.2
Change-Id: I3fc5dfeb77ce9a67a6e4494a3b2247c3007d0d25
Reviewed-on: https://review.typo3.org/28783
Reviewed-by: Oliver Hader
Tested-by: Oliver Hader
[BUGFIX] IRRE children's children are not moved with parent

Having a parent-child structure spanning three levels, only the
first and second level elements are moved to a different page.
All child elements below the second level are not changed.

The reason is, that the move-placeholder is only created for
the first level of children.

Resolves: #59111
Releases: 6.2
Change-Id: Ia044a1241b8b1e4885cabbbc44b777f847b4c9e5
[BUGFIX] Field size of t3ver_label too low

During workspace move operations sometimes a warning like
this can be found:

  102: These fields are not properly updated in database:
  (t3ver_label) Probably value mismatch with fieldtype.

The reason is, that the t3ver_label field in almost every
record is limited to 30 characters in the SQL definition.
Besides that the error code "102" of the mentioned warning
is invalid and should just be "1" to be recognized by the
accordant functional tests as well.

Resolves: #59110
Releases: 6.2
Change-Id: Ia97a32dbefd1d27e33f186c19c5a6a495dcc194a