NamelessCoder
commented
7 years ago Hi @webloft - sorry to hear you got caught by the removed ViewHelper.
This isn't an attempt to downplay your problem, but I would like to take this opportunity to explain our normal practice regarding deprecations, and explain the specific case of the Grid widget.
First, our normal practice:
- We do of course dispatch deprecation warnings, but you have to find these in the deprecation log and this means the deprecation log must be enabled - which isn't always the case on a production site. It is, however, also the method used by TYPO3 itself to warn about deprecations, so we adopt this in order to put our deprecation messages where all other ones are put (when developers follow the standard practice).
- We follow the semantic versioning scheme which means that any major revision may contain some breaking changes - and only major versions. In the past this hasn't always been the case, but for some time and for the foreseeable future, we'll strictly keep to this scheme exactly so you can know what to expect before an upgrade.
- We use class aliases and proxy classes when deprecating and we preserve those until a coming major revision (which is when the truly breaking change is "allowed" to be removed). This was also the case for the Grid Widget which since version 7.2.0 has been deprecated but had a class alias with deprecation logging in place right up until the release of 8.0.0 (one reason for the major version bump was in fact the removal of this class).
- When something is really breaking we do our best to warn about this; in changelogs as REMOVAL prefixed messages, on fluidtypo3.org blog with reasons behind it, and using deprecation logging.
So while I don't wish to dismiss your bad experience, I do sincerely think that we handle breaking changes and in particular removals of public API, very carefully and in accordance with normal TYPO3 practices; e.g. deprecate ahead of time.
Now that the general stuff is hopefully well explained, I do have some comments for the practices you describe:
If this happens in the extension manager for example, the Typo3 installation will be unusable till the extension which used the broken part will be unloaded again
This is very true and it is indeed a rather serious issue when this can happen. Our normal strategy to avoid this is to be very careful what we allow to process when we detect the install tool is being used (as in: ext_localconf.php gets loaded in install tool and if this causes any errors, it's a critical problem). Therefore: if you do spot any such cases don't hesitate to report them and we'll make sure the case is prevented. However, outside the install tool we face a different situation: even in production mode, if for example Flux is unable to process a template, this is every bit as serious a problem as if you had misconfigured TCA or an Extbase plugin. Such issues also cause exceptions to be thrown (with a limited message when you're in production mode) - but there are even exceptions to this, for example some Flux methods will swallow Exceptions when detecting templates if the template can't be processed, and instead of reporting an error, log a warning. In a way, we already took your suggestions into consideration ;) - but please don't stop giving feedback!
If you spot places where a logged warning is better in production mode we're happy to consider it, absolutely!
This behaviour makes updates of single components near impossible for simple users (aka customers).
This is just personal advise (also based on experience with exactly customer sites where customer is not a dev) - I would not allow my customers to update extensions. I would instead aim to sell them for example an upgrade plan where the customer is entitled to have you do the upgrades if/when a vital upgrade is available. There are also utilities around (I'll find links if you are interested) which lets you remotely monitor extension versions and warn about available upgrades. In any case, I would consider some way to prevent your customers from having admin access. It's rarely a good idea (not only for FluidTYPO3 extensions but also realurl, powermail, news and many others). Having a qualified person do upgrades (one who understands risks, knows how upgrade scripts work, reads changelogs and understands semantic versioning - so, a dev!) is quite important for the end user impression - on any platform.
Also please note, simple content elements can and will be used for view-logic. Thus it can be overwritten by a template override and every features you mark as deprecated need to patched again in every file!
This too is very true! And I will add that this is as much a problem for FluidTYPO3 extensions as it is for - just as an example - customised EXT:news templates. It is a very new thing, but quite recently we got a command line utility which can actually detect such problems in all templates which follow conventions (FluidTYPO3 does, and you do to if you follow our advise of using a provider extension for templates, which I hope you do). There are two utilities you may find useful:
- https://github.com/TYPO3/Fluid.Lint can do very basic linting. It is however limited to templates which only uses ViewHelpers from Fluid itself (so, cannot lint for example VHS usages correctly). If you are developing templates for an 8.x TYPO3, chances are that this utility may catch problems. It does however need to be passed each template file in order to lint it.
- https://github.com/NamelessCoder/typo3-cms-fluid-precompiler is a small composer library (not extension, just a tiny dependency) which works with TYPO3 8.4 and is capable of detecting problems in any convention-following template, using any number of imported namespaces. This utility should be the ideal way to quickly detect such problems when you're doing a test upgrade locally.
In addition to that I'll do my best to contribute a feature for TYPO3 for the install tool which can catch template issues just like the precompiler, and works along the lines of the "check for broken extensions" button. While that doesn't immediately do anything to prevent issues when you upgrade an extension, it would allow a nice way to detect all issues without visiting each page to render templates and it would obviously catch issues that can occur when you upgrade TYPO3 and due to version constraints also have to update some extensions.
I encourage you to point out any places you may come across these issues. We depend on user feedback for those issues we don't encounter ourselves, and we'd rather have one bug report too many than too few. I also encourage you read our change logs (although they are just git log exports, you can get a quick overview of REMOVAL and FEATURE changes which are the important ones when it comes to potentially breaking changes). And last, I hope my advise above can be useful to you in the future, especially the one about not letting customers be admins ;)
Have a nice weekend to you as well :)
Cheers, Claus
webloft
Dear developers,
please keep in mind a backward compatibility of flux, vhs and related components. Our extensions must work with every new version of these components.
Our last issue: The widget.grid viewhelper is gone. And every load of an upatched CE-file raises an unwanted exception, of course. If this happens in the extension manager for example, the Typo3 installation will be unusable till the extension which used the broken part will be unloaded again. Every exception thrown is very very bad. This behaviour makes updates of single components near impossible for simple users (aka customers).
Also please note, simple content elements can and will be used for view-logic. Thus it can be overwritten by a template override and every features you mark as deprecated need to patched again in every file!
Suggestion: Use of a missing deprecated viewhelper should return false and only raise a warning in the BE log in production mode. In case of the widget.grid viewhelper even no warning is really necessary or depending on the context, an exception can be thrown in developer mode.
I hope you understand the problem. Have a nice weekend and thank you for the great work!