Feature #37639
Allow overwriting the resource base uri
Status: | Rejected | Start date: | 2012-05-31 | |
---|---|---|---|---|
Priority: | Could have | Due date: | ||
Assigned To: | Karsten Dambekalns | % Done: | 0% |
|
Category: | Resource | |||
Target version: | TYPO3 Flow Base Distribution - 2.0 beta 1 | |||
PHP Version: | Complexity: | |||
Has patch: | No |
Description
currently, the resourcesBaseUri
is assumed from the current request (Resource\Publishing\FileSystemPublishingTarget::detectResourcesBaseUri()
).
This makes every resource URI looking like this:
http://www.acme.com/_Resources/Persistent/cff1839e83120f9a4d711dde511ca09fbb562005.js
It would be nice to have an additional setting like
1TYPO3:
2 FLOW3:
3 resource:
4 publishing:
5 overruleBaseDomain: 'cdn.acme.net'
Having set only this, the resource URI will look like the following:
http://cdn.acme.net/_Resources/Persistent/cff1839e83120f9a4d711dde511ca09fbb562005.js
In addition, overruleBaseSubdirectory
is possible:
1 publishing:
2 overruleBaseDomain: 'cdn.acme.net'
3 overruleBaseSubdirectory: 'ResourceStorage/WebResources/'
will result into
http://cdn.acme.net/ResourceStorage/WebResources/Persistent/cff1839e83120f9a4d711dde511ca09fbb562005.js
Setting
1 overruleBaseSubdirectory: ''
http://cdn.acme.net/Persistent/cff1839e83120f9a4d711dde511ca09fbb562005.js
(in order to get rid of the '_Resources' subdirectory).
I'd say that overruleBaseSubdirectory
is only possible/allowed to set if overruleBaseDomain
is set.
Of course an alternative to overruleBaseSubdirectory
is to introduce baseSubdirectory
which is per default active and set to '_Resources'
(this would change
1 public function initializeObject() {
2 if ($this->resourcesPublishingPath === NULL) {
3 // $this->resourcesPublishingPath = FLOW3_PATH_WEB . '_Resources/';
4 $this->resourcesPublishingPath = FLOW3_PATH_WEB . $this->settings['resource']['publishing']['baseSubdirectory'];
5 }
To also have an option to get rid of the Static/
and Persistent/
subdirectories, the same configuration rules can go for these, for example:
1 publishing:
2 overruleBaseDomain: 'cdn.acme.net'
3 overruleBaseSubdirectory: 'ResourceStorage/WebResources/'
4 overruleStaticBaseDomain: 'static.cdn.acme.net'
5 overruleStaticBaseSubdirectory: ''
6 overrulePersistentBaseDomain: 'persistent.cdn.acme.net'
7 overrulePersistentBaseSubdirectory: ''
An important clarification: all of this only affects the Web representation, i.e. what is outputted to the frontend in order to get an HTTP URI. The storage/symlink creation location does not change in any way.
Changing these settings are intended to require a setup in the rewrite rules, for example, because the actual storage on the file system isn't affected.
History
#1 Updated by Sebastian Kurfuerst about 3 years ago
-1, CDN support should rather be implemented using custom ResourcePublishers.
#2 Updated by Karsten Dambekalns about 3 years ago
- Status changed from New to Rejected
- Assigned To set to Karsten Dambekalns
The point of resource publishers is to support those things. So instead of "misusing" the filesystem publisher, a CDN publisher should be created. Then this is not needed.