-
TYPO3 is famously known for the "multi-site" functionality, allowing multiple websites running within one TYPO3 instance. However, configuring a multi-site had various downsides, mostly regarding to domain/entrypoint handling for a site, and if lots of languages were in place. Concepts like "absRefPrefix", "baseURL", various language related TypoScript settings, and the infamous "L" GET parameter can now be seen obsolete. Also, handling page-not-found or access-denied errors have never been easier, as every admin/integrator is able to configure this. What TYPO3 calls a "site" is a entrypoint / pagetree, and contains both configuration values relevant for Backend and Frontend. A site configuration has a unique (human-readable) "site identifier" and the following additional values: * Root page ID This is a page on the root level (pid=0) or having "is_siteroot" checked. * The base path / base URL This HTTP entry point e.g. https://www.mydomain.com/ ("Base URL" / HTTP entry point, like https://www.mydomain.com/) -- This allows to fully identify a pagetree with an entrypoint without having to guess during "runtime". * The definition of all available languages for this pagetree, including the default language for this specific pagetree. -- This includes both values for backend-related as well as information, previously only settable via TypoScript. This way, it is possible to have a TYPO3 installation with 20 languages, but only using 5 languages within one pagetree (site), using 15 different languages in another site, while also giving meaning for all records within one site. A site configuration can be added or edited within the TYPO3 Backend in a new backend module for admins, and is then persisted in "typo3conf/sites/site-identifier/config.yaml". The configuration format yaml is chosen as it minimizes the risk of doing hacks, but the concept of a SiteConfiguration can be adapted / exchanged to be overloaded or found in various other places in the future. Adding a site configuration for a project has various benefits: - Configuration is in one place, stored in the file system thus, is deployable. - Configuration can be done by an integrator/admin without any programming skills => in one place. - The necessity to query sys_language is only needed when configuring a site. - No need to configure TSconfig options like "previewDomains" and "defaultLanguageLabel" are gone. is - No need to configure any TypoScript conditions, or even TypoScript settings related to language handling. - It is possible to configure error handling on a per-site level, even language-dependant, without having to code or configure anything. However, if no site is configured for a pagetree, the previous behaviour is still in place, allowing to migrate slowly to the sites handling, as some key functionality like URL path handling for speaking URLs is not in place yet. It is important to understand that adding a site configuration comes with various restrictions: - "sys_domain" handling is not necessary anymore, as a page is resolved via the domain+base URL given in the configuration - Any previously configured TypoScript conditions based on L parameter do not apply anymore if a site is configured - This also applies to any config.*language* related TypoScript setting. - It is necessary to use a URI with scheme and path to configure a site, where as previously, TYPO3 would work without a base URL. - mod_rewrite or something similar is a requirement for sites to work properly. Further improvements not yet implemented: - Ensure backend modules like Web->Page, Web->View, Web->List and Web->Info only show records in the configured site languages. - Enable the possibility to handle "domain entry aliases", also for multi-server setups with different domain names. - Ensure the new Site module can handle "read-only" / deployable site configurations. - Allow to activate a language for a site to be editable in the Backend but not be available in the Frontend for everybody. - Handling "Storage Folder" on the top level with different language entries. - Improve URL generation in frontend to skip sys_domain resolving. - TypoScript conditions for [site = my-identifier] and [siteLanguage = dk]. - Improve proper caching for rootline resolving of pages without restrictions. - Improve resolving of siteLanguage from the current request. - Linking from one site to a page of a different site. - Centralizing access to sys_language and sys_domain. - Handle copying/moving of records to a different site with different languages and language settings. - Handle configuration change (like deleting a language in the configuration - what should happen to the translated records?) Next up for 9.3: - Adding "Routers" on top of sites for URL resolving of pages and records. - Handle Storage Folders on top level rootline - Handle Mount Points New API: - New Entity classes "Site" and "SiteLanguage" are resolved as part of a PSR-15 middleware and available for pages in FE and BE when possible. - A SiteFinder object is used to query Site and SiteLanguage objects and used in various places. - The new PageUriBuilder allows to create links to pages without any relation to the current request, and are already in use in Frontend links and Backend preview links. - A PageErrorHandlerInterface allows to custom error handlers to be introduced by extensions and configured on any site. Site handling is considered still "under development" until TYPO3 9 LTS, and implementation as well as the configuration format might change in the next sprint releases, in order to gather feedback on what is missing in the implementation. As a site configuration will be mandatory for TYPO3 v10.0, some changes regarding sys_language and sys_domain will follow. Beware: - Due to the definition of every record of default language (language=0), it might be possible to switch to locales for languages and get rid of the language ID. - sys_domain won't make it any much longer. Resolves: #84581 Releases: master Change-Id: Iabeeb6835a98c8f5a71d502379ed63a68dfad6dd Reviewed-on: https://review.typo3.org/56505 Tested-by:
TYPO3com <no-reply@typo3.com> Reviewed-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Tested-by:
Georg Ringer <georg.ringer@gmail.com> Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Tested-by:
0824e6e8
