[FLOW3-general] Deactivate packages in certain contexts

Marc Neuhaus apocalip at gmail.com
Fri Oct 26 18:15:07 CEST 2012


Hey Bastian,

in general i would absolutely recommend not to install the Debug.Toolbar on
a production machine, because it gathers quite extensive and possible
dangerous data. Currently i'm handling this by using the Debug.Toolbar as a
'require-dev' in my dist composer.json to only install it on environments i
want to test on.

So the question is probably, if you are forced to use the same
"codebase/installation" for those 2 different contexts, or if you could
split those and only install the Toolbar and Plumber on the
Production/Development target?

Nonetheless, i think context-dependent package states and a way to disable
the Debug.Toolbar both make sense i guess :)

Greetings Marc :)

2012/10/26 Bastian Waidelich <bastian at typo3.org>

>
> Hello all,
>
> I think it's a valid use case to have some packages only available in
> certain contexts.
> For a concrete example I'd like to have a new context
> "Production/Debugging" that loads the "Debug.Toolbar" package
> ("Sandstorm.PhpProfiler" & "Sandstorm.Plumber" respectively) but they
> shouldn't be active in the regular Production context.
>
> Do you think it makes sense to introduce such feature (to be able to
> install packages only in a certain context) or do you think it would be too
> complex usage and/or implementation wise?
>
>
> For a compromise I tried to disable the packages above with some special
> settings. Plumber comes with a setting "enableProfiling" so I tried to
> implement something similar in Debug.Toolbar.
> Enabling the AOP aspects based on some setting turns out to be really easy
> in Flow. One can just replace annotations as follows:
>
> @Flow\After("method(TYPO3\**Flow\Security\Policy\**PolicyService->**
> getPrivilegesForJoinPoint(*))"**)
>
> @Flow\After("setting(Debug.**Toolbar.enable) &&
> method(TYPO3\Flow\Security\**Policy\PolicyService->**
> getPrivilegesForJoinPoint(*))"**)
>
> But then the custom request handler is still active and will be used and I
> did not find a way to disable that with some setting (because the
> configuration manager is not yet fully initialized when RequestHandler::**canHandleRequest()
> is called..
> Does anybody have an idea here?
>
> Best
>
> --
> Bastian Waidelich
> TYPO3 Core Team Member
>
> TYPO3 .... inspiring people to share!
> Get involved: typo3.org
> ______________________________**_________________
> FLOW3-general mailing list
> FLOW3-general at lists.typo3.org
> http://lists.typo3.org/cgi-**bin/mailman/listinfo/flow3-**general<http://lists.typo3.org/cgi-bin/mailman/listinfo/flow3-general>
>


More information about the FLOW3-general mailing list