Feature #39441
Add TYPO3 Context information
Status: | Closed | Start date: | 2012-08-01 | |
---|---|---|---|---|
Priority: | Should have | Due date: | ||
Assigned To: | - | % Done: | 0% |
|
Category: | - | Spent time: | - | |
Target version: | - | |||
PHP Version: | Sprint Focus: | |||
Complexity: | hard |
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
History
#1 Updated by Fabien Udriot about 3 years ago
- Subject changed from Add a Context in which TYPO3 is running to Add TYPO3 Context information
#2 Updated by Christian Kuhn over 2 years 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.
#3 Updated by Ingo Renner over 2 years 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!
#4 Updated by Ingo Renner about 2 years ago
- Status changed from Rejected to Closed
Relevant sub tasks have been extracted into separate issues now, see linked issues.