Bug #91824
closedDeprecation of BackendUserAuthentication modAccess() function inconsistent
0%
Description
Deprecation in TYPO3 9 states:
The second argument of method modAccess() has been marked as deprecated, as the method should not trigger runtime exceptions anymore.
So, it says the function should not trigger runtime messages but since TYPO3 10.4 that is the default behaviour: to trigger the exceptions (without the parameter which is now removed).
In 9, it is not possible to get this behaviour (throws an exception) without triggering a deprecation.
Also, I am not sure if the phpdoc comment is consistent with the code. (in master):
Will return FALSE if the module name is not even found in $TBE_MODULES
If not isModuleSetInTBE_MODULES(), the function will throw an exception as well.
Updated by Sybille Peters over 3 years ago
See also docs page (9.5): https://docs.typo3.org/m/typo3/reference-coreapi/9.5/en-us/ApiOverview/BackendUserObject/Index.html#checking-access-to-current-backend-module
This was recently updated via https://github.com/TYPO3-Documentation/TYPO3CMS-Reference-CoreApi/pull/896
Updated by Markus Klein over 3 years ago
The original deprecation message in the code said:
Calling BackendUserAuthentication->modAccess() with a second argument is deprecated, as the default behaviour is throwing exceptions, which might get customized in TYPO3 v10.0. Remove the second argument within modAccess() to avoid the deprecation, and ensure to catch the Exception in the callers code.
Does that make it clear for you how to resolve the docs?
Updated by Sybille Peters over 3 years ago
Thank you, yes that is much clearer.
I think for the main docs, I have all I need.
Maybe someone else can decide if the changelog should be updated and also the phpdoc header for the function. IMHO the changelog is misleading: https://docs.typo3.org/c/typo3/cms-core/master/en-us/Changelog/9.5/Deprecation-86441-VariousMethodsAndPropertiesInsideBackendUserAuthentication.html
The second argument of method modAccess() has been marked as deprecated, as the method should not trigger runtime exceptions anymore.
Updated by Markus Klein over 3 years ago
For the time being I would say that this information is obsolete, since v10 is our current stable. New projects are using v10 and therefore this intermediate description of v9 is pointless now, you have to deal with the v10 behaviour.
Updated by Benni Mack over 2 years ago
- Status changed from New to Closed
Hey Sybille,
unfortunately, we cannot fix this in v9 anymore (no new releases), and in v10 this code is gone (AFAICS), as well as in v11. Correct? If there is something we can do, let me know, so I can re-open the issue.