Hi,

are lines starting with one of these @-command really processed?

@isroot
@clear
@sitetitle "My site title only in constants available"

see https://github.com/CMSExperts/bolt/blob/master/Configuration/TypoScript/setup.typoscript

We came across a problem in our site.
Bolt load the TypoScript completely at the end of the chain, so any template added on a page can't override TypoScript defined...
Is that wished? I think bolt should load the TypoScript before the templates defined on a page... in first...
Now If I want to override something, I need a condition in the site TypoScript...

Thanks.

We are using bolt in a multisite project that have identical setups, thus we reference the same site package in multiple site configurations.

I also use the feature to load constants from a site configuration, that was added in TYPO3 10.4 https://docs.typo3.org/c/typo3/cms-core/master/en-us/Changelog/10.4/Feature-91080-SiteSettingsAsTsConstantsAndInTsConfig.html In there i store e.g. page ids for news, search etc. to use them in TsConfig and TypoScript.

While the backend works fine and replaces all constants properly, the frontend uses cache entries from the site that was opened first.

When the TS loader generates a fake row, the uid only has a dynamic part with the package key

In my site extension, I have this line in my Configuration/TypoScript/setup.typoscript:

@import './config.typoscript'

(I also have more lines like this both in my setup.typoscript as well as my constants.typoscript.)

Without Bolt, the TypoScript from config.typoscript gets loaded fine (as seen in the TS object browser).

With Bolt, the TypoScript from the relative imports does not get loaded, even though TypoScript from setup.typoscript and constants.typoscript does get loaded.

Adding the extension key to the import gets the inclusion to work again:

@import 'EXT:site_maschinenrichtlinie/Configuration/TypoScript/config.typoscript'

This works for me as a workaround. However, still being able to use relative imports still would improve my developer experience.

I would really like to discuss #15 again.

I fully understand that TS should not in the DB, that is why we use such TsConfig

TCEFORM {
    sys_template {
        sitetitle.disabled = 1
        constants.disabled = 1
        config.disabled = 1
        includeStaticAfterBasedOn.disabled = 1
        basedOn.disabled = 1
        static_file_mode.disabled = 1
        starttime.disabled = 1
        endtime.disabled = 1
        clear.disabled = 1
        root.disabled = 1
        description.disabled = 1
    }
}

which allows us to have sys_template records with just the include_static select field. This is nice as we don't need to fiddle around with conditions and page IDs which can be different on various environments and still have the option to have everything versioned.

It worked fine in v10 but not in v12 :(

In addition to Configuration/PageTs/main.tsconfig this package should also support Configuration/TSconfig/page.tsconfig. This is one of the options with the most votes in the decision about File Endings for TypoScript and TSconfig files.

Not sure about casing here ...

Due to the rewriting of function getTypoScriptSetup() in V12, this function no longer returns any Typoscript that is included using Bolt. Only when you use the constants or setup field in the TS template of the site, or include static templates directly, will you get any Typoscript.

Line

$tsConfig['uid_' . $pageRecord['uid']] .= LF . $fileContents;

Since v12.0 it is not possible anymore to disable submodules by pageTs:
https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.0/Breaking-97135-RemovedSupportForModuleHandlingBasedOnTBE_MODULES_EXT.html

Therefore your code stopped working

mod.web_ts.menu.function.tx_tstemplateceditor = 0
 mod.web_ts.menu.function.tx_tstemplateinfo = 0

The new way to hide submodules is by using UserTS in your ext_tables.php:

\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addUserTSConfig('
options.hideModules := addToList(web_typoscript_infomodify, web_typoscript_constanteditor)
');

This looks like such a useful extension and would love to consider using it.

Would you consider allowing the ability to customise the site_ prefix?

I understand why your conventions enforce that, but for plugging this into an existing site, it would be great if this could be customised (or, in my case, removed).

Thanks

It would be cool to set lib.contentElement.extbase.controllerExtensionName to name of site package

Hi,

You have to update the name of the functions from web_ts in ext_tables.php.

Before:

\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addPageTSConfig('
    mod.web_list.deniedNewTables := addToList(sys_template)
    mod.web_ts.menu.function.tx_tstemplateceditor = 0
    mod.web_ts.menu.function.tx_tstemplateinfo = 0
    TCEFORM.pages.TSconfig.disabled=1
');

After:

\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addPageTSConfig('
    mod.web_list.deniedNewTables := addToList(sys_template)
    mod.web_ts.menu.function.TYPO3\CMS\Tstemplate\Controller\TypoScriptTemplateConstantEditorModuleFunctionController = 0
    mod.web_ts.menu.function.TYPO3\CMS\Tstemplate\Controller\TypoScriptTemplateInformationModuleFunctionController = 0
    TCEFORM.pages.TSconfig.disabled=1
');

Thanks

I suggest that the default PackageHelper::getSiteListForSiteModule could be replaced by a extension configuration.

Reason

EXT:bolt requires extensions to have the prefix site_. In a current project, we use the concept of "layout" packages, that renders content. They are prefixed with a different prefix than site_.

Suggested solution

I have a POC at hand for this idea.

Via ext_conf_template.txt the strategy can be changed to a different class, implementing a single method, returning a collection of site packages that can be selected in the backend.

Hi,

we discovered a problem between EXT:bolt and EXT:form in TYPO3 v12.
For v11 we cannot test this.
I am not really sure this is a bolt issue or one from Core/FormFramework.

First Problem:
Opening the backend module gives the following exception. The complete module is not shown
(1/1) TypeError TYPO3\CMS\Form\Controller\AbstractBackendController::resolveResourcePaths(): Argument #1 ($resourcePaths) must be of type array, null given, called in /var/www/html/vendor/typo3/cms-form/Classes/Controller/FormManagerController.php on line 80

Second Problem:
In Plugin, there are no forms selectable. Only the default placeholder "please select" is there.

Cause of Problem:
After some research I could say, that the typoscript settings/configuration cannot be loaded.
Because of missing typoscript extension settings there is an exception thrown in module.
Because of missing Form YamlConfiguration there are now forms selectable in plugin.

Hacky workaround solution:
After adding a sys_template record directly via DB and including at least the static templates of EXT:fluid_styled_content and EXT:form makes the errors go away. Even if the sys_template records is set to hidden.
When I set the "deleted" flags, the errors are back again.

I very much would love to use this extension in a huge project with multiple websites. The particular use case is, that they all share the same sitepackage, because it's only a few site tree specific overrides (like TypoScript constants or PAGE_TSCONFIG_ID) per package. So far I stored those overrides in a specific sub-folder inside the sitepackage and included the file in the TypoScript Template Object record, e.g.
<INCLUDE_TYPOSCRIPT: source="FILE:EXT:my_sitepackage/Configuration/TypoScript/sites/website-a/constants.typoscript">

Unfortunately, the paths where bolt looks for configuration are fixed. So here's my question:

Is it possible to make them adjustable? Or, what would be a better way to handle this (except having a sitepackage per site tree, because I don't see a benefit in having 20 site packages with only some constant overrides inside)?

Thanks again for the great extensions - I'm currently looking into utilising this :) . I really like the idea of having non-database configuration, but with a hole bag of legacy sites we'd upgrade, I have a few questions.

This is more of a discussion than an issue - I hope you don't mind me asking here - happy to close this issue and ask somewhere else if it's more suited :)

With the inability to make the extension templates, what is the best way to achieve the following?

1. TypoScript include for a specific page - we sometimes create a new TypoScript file if a page has lots of overrides, would this be included in the main TypoScript with a page condition? I suppose this also extends to static includes for specific pages
2. Building on the last question, is there a way I can "clear" all TypoScript included for a specific page and then include a fresh file?
3. Where would you set the Website Title (SiteTitle)?

Sorry again if this is the wrong place. Thanks!