Skip to content

Latest commit

 

History

History
341 lines (294 loc) · 24.8 KB

CHANGELOG.md

File metadata and controls

341 lines (294 loc) · 24.8 KB
Raw

Flux Change log

7.3.0 - 2015-11-20

New minor release introducing TYPO3 7.6 LTS compatibility - which also means that from this point onward, the minimum supported TYPO3 version is 7.6. For those that still require critical fixes but must remain on for example TYPO3 6.2 we provide a legacy branch: https://github.com/FluidTYPO3/flux/commits/legacy

However, some notes about the legacy branch:

  1. We Provide this branch as-is, not guaranteeing compatibility.
  2. We do not actively maintain this branch:
    • We happily accept suggestions for fixes including code
    • We happily accept pull requests to the legacy branch (but please observe our contribution guidelines very closely when making patches for this branch - we aim for a minimal maintenance effort)
  3. There is no expected maximum lifetime of the branch, but you should prioritise upgrading your TYPO3 site to LTS as soon as you can. The 6.2 branch of TYPO3 no longer receives bug fixes (including security patches).

The following new changes and features are highlighted:

All ViewHelpers compilable

This change means that all Flux ViewHelpers can now be compiled to native PHP which increases the performance, in particular for templates that have many instances, such as page templates.

However, this change has required a small change to the internal API of Flux: the getComponent method on Form component ViewHelpers is now static which may yield warnings if you use custom component ViewHelpers - and depending on your PHP version. Very few should be affected since custom components are rare, only causes warnings and only warns on newer versions of PHP.

Compatibility Registry

A special registry has been introduced to facilitate easy version based dependency configuration. Essentially it allows you to provide a list of TYPO3 versions and values that apply to that version, with resolving happening in a way that the maximum viable configuration always gets returned. For example you can specify class names to return for TYPO3 versions 7.4 and 7.6, and if the active version is 7.5 the 7.4-specific class name gets returned (because the 7.6-specific one cannot be used).

\FluidTYPO3\Flux\Utility\CompatibilityRegistry::register(
	'MyVendor\MyExtension\MyClass',
	array(
		'7.4.0' => 'MyVendor\MyExtension\Legacy\MyClass',
		'7.6.0' => 'MyVendor\MyExtension\MyClass'
	)
);
\FluidTYPO3\Flux\Utility\CompatibilityRegistry::get('MyVendor\MyExtension\MyClass');

The compatibility registry is introduced to make version checks completely uniform and allow any number of alternatives to be speficied, consistently returning a single value without you having to care about checking TYPO3 versions. In addition, the static signature means you can use the registry from anywhere (and manipulate it without mocking from unit tests).

On-the-fly TCA manipulation

Provider classes are fitted with a method that together with the new FormEngine allows TCA to be manipulated freely. If a Provider is triggered when editing a record, every aspect of the editing form's composition can be manipulated. To utilise this feature all you need to do is implement public function processTableConfiguration(array $row, array $configuration) in your Provider class and make the method return the (modified) $configuration array. The $configuration array is a big array of FormEngine configuration and is at the time of writing this not fully documented. See the official TYPO3 documentation for more information about the FormEngine configuration - or debug the array and make your own experiments, it's not too difficult except for the size.

Various other changes

7.2.3 - 2015-09-30

7.2.2 - 2015-09-20

Solid round of bug fixes mainly, few added minor (and fully backwards compatible) features and focus on fixes for drag-and-drop and copy-paste behavior on TYPO3 6.2. Some minor fixes for workspaces support.

Notable changes/features:

  1. Template paths now use 0 as default index instead of previous 10. This can have an adverse effect on sites that for some reason has one or more sets of templates which: a) are configured by replacing the default 10 index, AND, b) have removed one or more templates that exist in the original path. Such a setup may begin to display previously disabled template files as selectable options in the backend. To fix this, update your TypoScript template paths to use 0 as the bottom priority paths.
  2. Icons now support SVG files. Not much to say about this one - use an .svg file as icon for a template, either through the icon Form option or by placing it in the convention-based expected icon path.
  3. Form now supports sorting as a global option that can be used by any implementation; previously fluidcontent added its own but can now delegate this to Flux. This means that from now on you should define options="{sorting: 10}" instead of wrapping the sorting value in a scope like {Fluidcontent: {sorting: 10}}.
  4. When rendering Requests and when retrieving Form instances from templates, Flux will now respect the vendorName request parameter - and will in fact pass-through the original Request (as a cloned instance) whenever an original Request exists. Though this change doesn't have any effect on the surface, it does improve frontend rendering scope consistency when rendering through a custom Flux controller.
  5. TYPO3 7.4 is now supported.

List of all changes affecting users:

7.2.1 - 2015-05-20

7.2.0 - 2015-03-18

Flux has undergone a lot of maintenance work and optimisations. The main goal has been to increase performance and remove bottlenecks, and to make the Flux API simpler and more consistent to use. A lot of legacy support has been removed and the existing support for template paths has been improved, bringing it completely into sync with the TYPO3 core. Overall, Flux now uses much more of the TYPO3 core's code to do the job especially concerning the View aspect.