TYPO3 Core

You are right Andreas, template files from my personal are not empty but one (all?) of them causes trouble. Thanks for pointing that.

The specific error there is caused by one of two things:

1. trying to render a statically or dynamically named section from a template that has no sections (excluding f:render calls to partials, when fluid standalone gets used as base, also excluding f:render calls to render sections from layouts when section does not exist and "optional" flag is set)
2. trying to render a statically or dynamically named section from a template using a precomposed view that enables "renderSection" (this will become possible directly from any view when fluid standalone becomes the base)

Now, Flux-based features will try to read a specific section from any templates that are detected - that's quite true - but no such loading should ever occur in the install tool, for the following reasons:

1. Flux does contain some features that could cause this, but they are registered through ext_* files which are not loaded in the install tool. And I must assume you don't override the "install" extension with one that replaces the view class ;)
2. The features that do get registered and might trigger this template reading (for example, fluidcontent scanning for available files after caches are cleared) should at this time (assuming you use the most recent versions of all fluidtypo3 extensions) be protected by checks so they don't run in the install tool specifically.

There could be an explanation for this (I haven't checked the actual templates of the "install" extension) in some use of dynamic section names where the name of a section was incorrectly passed or has case sensitivity problems. But it could of course also be that we (fluidtypo3) missed some triggered feature that touches templates and gets fired in the install tool unintentionally. To track that down further, please add:

1. A full stack trace so I can check if the Flux view class is involved
2. The precise list (as many as you know) of views in the install tool which fail with that error
3. Whether or not this happens after you clear system caches (this will help me further track down the problem)

If we can identify fluidtypo3 as the cause I can fix it. If we can eliminate it I can probably find out exactly why this happens and what to do to prevent it.

Thanks Alexis, that helped :)

This line seems to explain the problem:

// ext_localconf, db and ext_tables must be loaded for the updates

So it appears this only affects upgrades (schema).

Fluidcontent may be to blame for this. It registers some hooks in ext_localconf.php - to be honest, I assumed the install tool simply wouldn't use those hooks (being a safe context and all). So I think protecting these hooks as well from running in the install tool should fix it.

If you don't mind, please report this to the fluidcontent issue tracker.

And then this one can be closed, I think :)