Resolves #10908

Fixes #10975

Fixes: #8749

* Raised Version Number to 1.3.0beta2

This fixes: #11101

Since r3062 Extbase uses the t3lib_FlashMessageQueue to store flashmessages.
Now you can output them including title and severity, making it possible
to render flashmessages just like the ones from the core in BE mode.
To keep backwards compatibility, the default rendering still outputs
only the message bodies in an unordered list. Set the renderMode argument
to "div" in order to display the new style:
<f:flashMessages renderMode="div" />

Relates to: #10821

[+TASK] Fluid (View): Added additional check for deprecated lower case template filenames that works on case insensitive file systems (Windows) too. Watch your deprecation log in typo3conf and fix your template filenames if they're still lower case.

This fixes: #10902

* Updated ChangeLog

[+FEATURE] Fluid (ViewHelpers): the subject argument of the count ViewHelper is now optional so you can use it like {objects -> f:count()}
[+BUGFIX] Fluid (ViewHelpers): Fixed inline documentation of widget.autocomplete ViewHelper. This fixes #10882
[+TASK] Fluid (ViewHelpers): Added some more inline documentation for cObject, widget.paginate, widget.autocomplete & count ViewHelpers

[+BUGFIX] Fluid (ViewHelpers): replaced two occurrences of Tx_Extbase_Dispatcher::*() by using the injected ConfigurationManager
[+TASK] Fluid (ViewHelpers): uri.image now works in BE mode too

The Fluid ViewHelper now uses the skinning API correctly.
This bugfix has been already in TYPO3 Core, but not yet here.

Renaming Widget link ViewHelpers from 
<f:link.widget> and <f:uri.widget> to
<f:widget.link> and <f:widget.uri>

[+FEATURE] Fluid (ViewHelpers/Widget): Slightly improved paginate widget: The link to the first page now skips the currentPage argument resulting in nicer URLs and less cHashes
[+FEATURE] Fluid (ViewHelpers): excluding obsolete widget arguments & cHash from widget links if they're not explicitly set

[+BUGFIX] Fluid (Core/Widget): AjaxWidgetContextHolder now uses a unique id for the Ajax WidgetContext. This makes sure, that the ajax response gets the right context, even if you open multiple browser windows in the same session
[+BUGFIX] Fluid (Core): The Fluid Widget Bootstrap now initializes the object manager in order to respect "config.tx_extbase.object" configuration.. TODO: this should be somehow refactored to avoid code duplication
[+BUGFIX] Fluid: Reduced the typeNum for the fluidAjaxWidgetResponse page. Apparently 7076857368 was too large ;) TODO: the typeNum should be somehow configurable
[~TASK] Fluid (ViewHelpers/Widget): removed $GLOBALS['TSFE']->additionalHeaderData call from AutocompleteViewHelper as this is not configurable like this. Moved the jQuery includes to Configuration/TypoScript/setup.txt which can be included in your main TS template

[+BUGFIX] Fluid (ViewHelpers): Fixed Widget URI generation in widget.link/widget.uri ViewHelpers/Link/WidgetViewHelpers
[~TASK] Fluid (ViewHelpers/Widget): Tweaked PaginateViewHelper: Minor refactoring of controller & template

[-TASK] Fluid (Compatibility): Forgot to remove obsolete Tx_Fluid_Compatibility_ObjectManager in previous commit

[+FEATURE] Fluid (Core/Widget): Added Tx_Fluid_Core_Widget_Bootstrap that is used to dispatch Ajax requests (see ext_typoscript_setup.txt).
[~TASK] Fluid (Compatibility): Removed Tx_Fluid_Compatibility_ObjectManager and replaced instances by Tx_Extbase_Object_ObjectManagerInterface instances
[~TASK] Fluid (Core/Widget): AbstractWidgetController has to be a singleton so it can be injected in the WidgetViewHelper.. To be discussed!
[+TASK] Fluid (Core/Widget): AjaxWidgetContextHolder is now correctly stored in the BE/FE Users session if the ajaxWidget of the corresponding Widget is TRUE.
[+TASK] Fluid (Core/Widget): The WidgetContext now contains a reference to the parent extension & plugin name. That's needed for the widgetAjaxResponse.
[+BUGFIX] Fluid (Core/Widget): WidgetRequestBuilder now correctly interprets GET parameters and dispatches Ajax requests
[+BUGFIX] Fluid (ViewHelpers): Modified ViewHelpers cObject, format.crop, format.html, image, uri.image so that they use dependency injection in order to retrieve the current cObject instance from the configurationManager
[+BUGFIX] Fluid (ViewHelpers): Fixed form ViewHelper to respect configured pluginNamespace in field name prefixes
[+BUGFIX] Fluid (ViewHelpers): link.widget/uri.widget ViewHelpers now create correct URIs
[+BUGFIX] Fluid (ViewHelpers): replaced @inject annotation by injectController method in AutocompleteViewHelper.

This is the first step of the Widget backport (#8773). This contains all the core classes that are required for the widget implementation and two exemplary Widget ViewHelpers "widget.paginate" and "widget.autocomplete".
Note: Ajax widgets are not yet working!!

Relates to: #8773
Relates to: #10568

Tx_Fluid_View_AbstractTemplateView now implements the Tx_Extbase_MVC_View_ViewInterface that was changed in r2675.
NOTE: This is a breaking change because the API method Tx_Fluid_View_TemplateView::hasTemplate was renamed to canRender(). Besides I deleted the TemplateViewInterface that is no longer needed. Implement Tx_Extbase_MVC_View_ViewInterface or simply extend Tx_Fluid_View_AbstractTemplateView if you want to write your own view implementation

Relates to: #8990

Relates to: #9062

Make sure, that the configurationManager is initialized.
This is just a preliminary solution that will be replaced as soon
as the Extbase dispatcher refactoring (#7153) is done.

In order to be able to use Fluid templates beyond the Extbase plugin context
(e.g. to render E-Mail templates or to use the new FLUIDTEMPLATE content object)
we created a new template view, that encapsulates inner workings and provides
an easy-to-use API:

$view = t3lib_div::makeInstance('Tx_Fluid_View_TemplateView');
$view->setTemplatePathAndFilename('foo/Bar.html');
print $view->render();

Note: This has to be *forward ported* still

This relates to #10473

The image view helper did not call the parent constructor, which registeres the "additionalAttributes" argument. Thanks to Michael Knoll.

This resolves #10251

In I14c6dd4d9db13a98f1873a79bb43fbf299d2c835, we have introduced
a change which caused the Menu generation in TYPO3 Phoenix to crash,
as {settings} is not available in these templates.

Now, a check has been added which checks for {settings} being present.

Additionally, a unit test has been written testing this behavior.

Now, the {settings} are automatically available in partials and sections.
Before, they had to be passed explicitely, i.e. by calling
<f:render section="..." arguments="{settings: settings}" />.

If somebody defined his own "settings"-argument, this still takes precedence:
<f:render section="..." arguments="{settings: some.different.settings}" />
This means that this change is completely backwards compatible.

NOTE: The settings are NOT merged together, like it has been suggested in #6289,
as this will lead to un-obvious behavior for the user.

This method has accidentally gotten an @api annotation,
and was only needed for the Viewhelpertest package.

Now, this package is cleaned up, and this method can be
completely thrown away.

Since #6521 you can use the "objectName" argument to specify the name of a bound object rather then using the "name" attribute.
But if you do so, the rendered hidden identity field is not correct anymore. This behavior is fixed with this commit.

Resolves: #9515

you can now use <f:security.ifAuthenticated> and <f:security.ifHasRole role="foo">
in your Fluid templates to check whether an FE user is currently logged in / belongs to the
specified usergroup.
Note: if role is a numeric value the uid of the usergroup is compared, otherwise the title
of the usergroup.

to deal with BE users you can use the respective be.security.* view helpers

Resolves #9143

In rare cases, on some systems (like mine), the
PCRE parser reproducably crashes if one passes very
long argument strings into it, or very complex ones.

With this patch, the parser is slightly modified
to decrease the use of backtracking; which then avoids
the crashes mostly.

There were some undocumented regular expressions
in the parser, which needed to be formatted nicely.

Boolean expressions with negative numbers did not work so far.
Now, they work as expected. Example from Viewhelpertest which displayed
a wrong result before, and now displays the correct result:

<f:if condition="{testVariables.number.minusOne} < -1.1">
	<f:then>Then part!</f:then>
	<f:else>Else part!</f:else>
</f:if>

Issue: #9434