Project

General

Profile

Actions

Feature #22896

closed

cannot integrate a constant into <INCLUDE_TYPOSCRIPT: source=/fileadmin/{$myconstant}

Added by d.ros no-lastname-given almost 14 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Could have
Assignee:
-
Category:
TypoScript
Target version:
-
Start date:
2010-06-16
Due date:
% Done:

0%

Estimated time:
PHP Version:
5.3
Tags:
Complexity:
Sprint Focus:
Needs Decision

Description

cannot integrate a constant into a path in TS-Setup while using
<INCLUDE_TYPOSCRIPT: source=/fileadmin/{$myconstant} . . .

would be nice if this works as it is interesting feature in multidomaintrees

(issue imported from #M14744)


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #47985: INCLUDE_TYPOSCRIPT does not resolve TS-ConstantsRejected2013-05-06

Actions
Actions #1

Updated by Paul Voss over 13 years ago

Would really like to see this feature, too. Makes setting up new projects (with similar fileadmin structures) much faster.

Actions #2

Updated by Steffen Gebert over 13 years ago

+1
would also like this very much! d.ross or Paul, are you able to create a patch?

Actions #3

Updated by Fedir RYKHTIK over 13 years ago

Hi there,
it could be very handy suche feature.
Looks like, what need to patch function checkIncludeLines in t3lib/class.t3lib_tsparser.php.

The code is some old, so it's not so easy to understand the logic. Normally, need to add regexp, which will preparse and substitue the TS constants.

If anybody could indicate the documentation about TS parsing (checking constants etc), probably, could take care about this feature.

Regards,
Fedir

Actions #4

Updated by Alexander Opitz almost 11 years ago

  • Status changed from New to Needs Feedback
  • Target version deleted (0)

As this report is very old, is the handling in newer TYPO3 CMS Versions (like 6.0/6.1) more like you expect it?

Actions #5

Updated by d.ros no-lastname-given almost 11 years ago

Untested but afaik it doesn´t work in 6.1 either

Actions #6

Updated by Alexander Opitz over 10 years ago

  • Status changed from Needs Feedback to New
Actions #7

Updated by Alexander Opitz over 10 years ago

  • Category set to TypoScript
Actions #8

Updated by Stefan Neufeind over 10 years ago

  • Status changed from New to Rejected

In #47985 Thorsten Kahler explained:
This behaviour is documented, see http://docs.typo3.org/typo3cms/TyposcriptSyntaxReference/Syntax/Includes/Index.html
Reason: The final TS constants tree can't be used before all includes are resolved, so this is kind of a hen and egg problem. Otherwise includes could not be used for constants.

Actions #9

Updated by Franz Holzinger over 10 years ago

The issue request has been about the include statements inside of a setup. This could be realized for the setup only. Includes for constants could be disallowed for this enhanced feature.

Actions #10

Updated by d.ros no-lastname-given over 10 years ago

Franz is correct. Inside setup would be sufficient as you can deliver the fixed constants file by extension, while TS path needs to be flexible.

Cheers

David

Actions #11

Updated by Jigal van Hemert over 10 years ago

  • Status changed from Rejected to Needs Feedback
  • Priority changed from Should have to Could have

It could be done for Setup only, but it requires quite some changes in the processing. Substitution of constants must be done twice, once for includes second time for "normal" constant substitutions. Handling of includes must be done in two steps.
It will most likely take extra processing time, this has to be taken into account.

I personally doubt the extra value of this feature. Now that it's possible to include entire directories (recursively, only certain file extensions), it's easier to change the includes without touching the actual <include command itself.

Can someone give a use case which cannot be solved by the include directory directive?

Actions #12

Updated by Alexander Opitz almost 10 years ago

Can someone give a use case which cannot be solved by the include directory directive?

If there won't be any response in 3 months, the issue will be closed.

Actions #13

Updated by d.ros no-lastname-given almost 10 years ago

I personally doubt the extra value of this feature. Now that it's possible to include entire directories (recursively, only certain file extensions), it's easier to change the includes without touching the actual <include command itself.

The usecase remains the same.

If you have a multidomaintree where you want to divide the branches from each other you would go with an automatic include path for ts like this -> "fileadmin/usecase/{$BRANCHNAME}/scripts/ts"

So in the end this option is still handy if it would be there.

It will most likely take extra processing time, this has to be taken into account.

But AFAIK only once until it is cached?

Actions #14

Updated by d.ros no-lastname-given almost 10 years ago

Can someone give a use case which cannot be solved by the include directory directive?

Other way round asked: How would you divide a multidomaintree with branches in fileadmin with the automatic include option -without touching the path?

Actions #15

Updated by Alexander Opitz almost 10 years ago

  • Status changed from Needs Feedback to New
Actions #16

Updated by Mathias Schreiber over 9 years ago

  • Assignee set to Mathias Schreiber
Actions #17

Updated by Susanne Moog over 8 years ago

  • Sprint Focus set to PRC
Actions #18

Updated by Mathias Schreiber over 8 years ago

Is there a particular reason you do not store your templating information in an extension?

Actions #19

Updated by d.ros no-lastname-given over 8 years ago

Quite simple: There must not be an extension.
A lot of people setup systems without any provider extensions for ts only.

Cheers

Actions #20

Updated by Björn Jacob over 8 years ago

Even if you use an extension for providing the whole site package it would still make sense to have such a feature. The constant could carry the extension name/ name of the site package and all the additional includes don't need any manipulation/ further changes and could be re-used.

The directory inclusion is IMHO not enough since you cannot tell the system the sort/ load order of the files, can you?

Actions #21

Updated by Mathias Schreiber over 8 years ago

phew... I gotta be honest here.
I never needed this in 15 years and yes, I have done tons of multi-tree sites.
Effectively doubling the rendering times of TS in the frontend just for this?
I have a hard time telling myself that punishing all users with a massive performance implication doesn't quite convince me yet.

I'm totally up for discussion, don't get me wrong but right now the pros don't outweigh the cons.

Actions #22

Updated by Björn Jacob over 8 years ago

I still like the idea from an integrator's point of view. But making the whole process significantly slower is not worth the effort. I don't get the use case for multi domain setups.

Actions #23

Updated by d.ros no-lastname-given over 8 years ago

The usecase is that if you setup multiple sites in one tree with completely differing setups you cannot have a preconfigured tree which can be setup by drag and drop plus adding a single constant to assign the paths for all relating files. You have to manipulate every regarding field manually. The related fields are userTS, TSsetup, and so on.

But in the end if this really twices the rendering the onthought solution isn't the best. Perhaps there's another possiblity to provide relative setting paths.

Actions #24

Updated by Mathias Schreiber over 8 years ago

d.ros no-lastname-given wrote:

multiple sites in one tree

Is this a typo?
Otherwise I need a lot more info on what you try to achieve :)

Actions #25

Updated by Riccardo De Contardi almost 6 years ago

  • Status changed from New to Closed
  • Assignee deleted (Mathias Schreiber)

Three years has passed without a real advancement on this issue; therefore I close this one for now.

TYPO3 team is working on a working towards an easier concept to create sites and their configuration from inside the backend, without the performance penalty of this solution; if it will be necessary, fresh issues will be opened about this topic.

If you think that this is the wrong decision, please ping me and I'll reopen it.

Actions #26

Updated by Benni Mack almost 4 years ago

  • Sprint Focus changed from PRC to Needs Decision
Actions

Also available in: Atom PDF