Feature #39441

Add TYPO3 Context information

Added by Fabien Udriot 10 months ago. Updated about 1 month ago.

Status:Rejected Start date:2012-08-01
Priority:Should have Due date:
Assignee:- % Done:

0%

Category:-
Target version:-
TYPO3 Version:6.1 Complexity:hard
PHP Version:
Votes: 1 (View)

Description

What is your opinion about introducing a TYPO3 Context?

This would imply:

  • Add a TYPO3_CONTEXT constant
  • The constant could be set by either simply setting the constant or by a PHP Environment variable or by PHP configuration.

# Computes Context
if (!defined('TYPO3_CONTEXT')) {
    if (getenv('TYPO3_CONTEXT')) {
        define('TYPO3_CONTEXT', getenv('TYPO3_CONTEXT'));
    } elseif (ini_get('TYPO3_ENV')) {
        define('TYPO3_CONTEXT', ini_get('TYPO3_CONTEXT'));
    } else {
        define('TYPO3_CONTEXT', 'Production');
    }
}
  • TYPO3 would automatically load FooConfiguration.php if Foo is the Context name
  • Add a new TypoScript condition for convenience
  [context = Foo]
  [end]
  • Display a possible message in the BE Header of the current Context (should be only displayed if the Context is not production).
  • The Core could possibly ship some default presets for particular context (e.g. Development)

The default Context would be "Production" to stay backwards compatible.


Related issues

related to Extbase MVC Framework - Feature #34224: Introduce Contexts Rejected 2012-02-24

History

Updated by Fabien Udriot 10 months ago

  • Subject changed from Add a Context in which TYPO3 is running to Add TYPO3 Context information

Updated by Christian Kuhn 2 months ago

  • Status changed from New to Rejected
  • TYPO3 Version changed from 6.0 to 6.1
  • Complexity set to hard

Yes, context definitions in TYPO3 CMS must be done, we are heavily missing this.

But an approach to base this on constants is not good enough: They are not extendable, unflexible and nearly impossible to change or get rid off later on. Thus I'd -2 any approach based on constants. Imho FLOW has a way better concept at this point: It has an object for context and subcontexts, they can be extended and new subcontexts can be added. This is the way to go for us, too. I think, Thomas is working on a similar thing in his sandbox and has something at hand already.

For now, I'm going to reject this approach here. I really think that we must solve this once and for all with a good underlying design.

Updated by Ingo Renner about 1 month ago

I'd also vote for an object, for the same reasons: Being extendable in what information a context can carry. In general, +1 for context information. Also the TS condition is a neat idea!

Also available in: Atom PDF