[BUGFIX] Fix double ? in eID url for encryption key

The AJAX url for retrieving a new encryption key contains
two question marks. This causes the request to fail.

Fix this by removing the superflous ? from the parameters.

Resolves: #59034
Releases: 6.1, 4.7, 4.5
Change-Id: Iab3833f50a48b71b25cf0205f7eb8d6b57dd859a
Reviewed-on: https://review.typo3.org/30385
Reviewed-by: Alexander Opitz
Reviewed-by: Michael Schams
Tested-by: Michael Schams
Reviewed-by: Wouter Wolters
Reviewed-by: Helmut Hummel
Tested-by: Helmut Hummel
Reviewed-by: Markus Klein
Tested-by: Markus Klein
[BUGFIX] Fix wrong JS function name in RTE

RTE feature "userlinks" generates a wrong JS function
name due to the automatic replacement during the
namespace conversion.

Revert this line to use the correct JS function name.

Resolves: #59302
Releases: 6.2, 6.1, 6.0
Change-Id: Ia6b51e7e1b1dfa0e618106f4f039bd0774464a97
Reviewed-on: https://review.typo3.org/30540
Reviewed-by: Markus Klein
Tested-by: Markus Klein
[BUGFIX] DataHandler::log() must not return NULL

Ensure the DataHandler::log() function does return integers
in all cases as denoted in the doc header.

Resolves: #59185
Releases: 6.2, 6.1, 6.0
Change-Id: I2a6aa0415b7cc19f10b4a290e43bd20065e6c9e1
Reviewed-on: https://review.typo3.org/30549
Reviewed-by: Wouter Wolters
Tested-by: Wouter Wolters
[BUGFIX] Fix frontend unit tests if executed standalone

* Unit tests are allowed for CLI anyway
* Remove allow all in data provider

The latter implicitly caused a global allow, as PHPUint parses
all data providers before any test is run, thus setting globals there
will cause them to be preserved (and restored when backup globals is true).

Releases: 6.2, 6.1, 6.0
Resolves: #59343
Change-Id: I646294bb472027e22d6edc0622068698fe9a88fc
Reviewed-on: https://review.typo3.org/30563
Reviewed-by: Helmut Hummel
Tested-by: Helmut Hummel
[BUGFIX] Warning in SearchController

$this->sWArr is not defined SearchController.
Fix this to use the correct $this->searchWords variable.

Change-Id: Iba888f1a47dcc0952ffbbb1e3bb4413435c2a95e
Resolves: #59277
Releases: 6.2, 6.1
Reviewed-on: https://review.typo3.org/30587
Reviewed-by: Markus Klein
Tested-by: Markus Klein
[BUGFIX] Illegal string offset 'uid' in TypoScriptFrontendController

Logoff sets user property to an empty string instead of NULL. This
leads to a PHP Warning in PHP 5.4

Change-Id: Ib0e1a31dbf2fd3fcbcf1e7afd972b53d60c3ab5d
Resolves: #59364
Releases: 6.2, 6.1
Reviewed-on: https://review.typo3.org/30595
Reviewed-by: Wouter Wolters
Tested-by: Wouter Wolters
[!!!][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
[BUGFIX] MM relations are not correctly resolved in Backend view

DataPreprocessor is taking care of preparing data for the form
view processed in the FormEngine. However, MM relations are not
correctly resolved in a workspace context.

The method DataPreprocessor::getDataIdList() is used for a mixed
kind of relations there, without properly applying the differences
for MM records. The rule is, to always use the live default id,
except for MM relations - use the specific workspace value.

Resolves: #58735
Releases: 6.2
Change-Id: I256969adb46bfea80681160e2901387a8c7c9a7d
Reviewed-on: https://review.typo3.org/30037
Reviewed-by: Georg Ringer
Tested-by: Georg Ringer
Reviewed-by: Markus Klein
Reviewed-by: Helmut Hummel
Tested-by: Helmut Hummel