Skip to content

GitLab

Switch branch/tag
This project is mirrored from https://git.typo3.org/typo3/typo3.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 25 Apr, 2018 2 commits
  3. 23 Apr, 2018 1 commit
  5. 21 Apr, 2018 1 commit
  7. 20 Apr, 2018 1 commit
  9. 19 Apr, 2018 1 commit
  11. 18 Apr, 2018 1 commit
  13. 17 Apr, 2018 4 commits
  15. 16 Apr, 2018 1 commit
  17. 14 Apr, 2018 1 commit
  19. 09 Apr, 2018 2 commits
  21. 08 Apr, 2018 1 commit
  23. 06 Apr, 2018 4 commits
    • Christian Kuhn's avatar
      [FEATURE] Introduce Site Handling · 0824e6e8
      Christian Kuhn authored and Andreas Fernandez's avatar Andreas Fernandez committed 
      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: default avatarTYPO3com <no-reply@typo3.com>
Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
Reviewed-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
Tested-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
Tested-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      0824e6e8
    • Susanne Moog's avatar
      [TASK] Decouple adminPanel from frontend · 1eeedc59
      Susanne Moog authored and Benni Mack's avatar Benni Mack committed 
      The admin panel has been extracted into an own extension. To enable
users to de-activate the admin panel completely, the hard coupling
between the extension and other parts of the core had to be resolved.

With this change, the initialization of both adminPanel and feedit
were moved into PSR-15 middlewares. Additionally all parameters
related to the adminPanel were removed from the FrontendBackend-
UserAuthentication.

As feedit is tigthly coupled with the adminPanel some changes had
to be made to its initialization, too.

The flow of the adminPanel initialization and rendering were
streamlined to allow modules to make use of the request object.

Due to these changes in the control flow of the application the
two existing tests were removed and new tests will be rewritten
once the API is declared as stable.

Releases: master
Resolves: #84641
Change-Id: I72beefde0d792d3f4295c45aa27204c817d2de7a
Reviewed-on: https://review.typo3.org/56558

Tested-by: default avatarTYPO3com <no-reply@typo3.com>
Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
Tested-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      1eeedc59
    • Andreas Fernandez's avatar
      [BUGFIX] Only apply language constraints for "Show hidden" checkbox if neccessary · 94acfea0
      Andreas Fernandez authored 
      The checkbox "Show hidden content elements" currently checks any selected
language. This is malfunctioning in case the language "Default" is
selected in the "Language" view, as it won't affect any translation.

The patch now changes the handling to add the language constraint only if
the view renders multiple languages and any language is selected, that is
not the default language.

Resolves: #84589
Resolves: #84573
Releases: master, 8.7
Change-Id: I572d594e5828d423e67a40481f44857df79ebae9
Reviewed-on: https://review.typo3.org/56532

Tested-by: default avatarTYPO3com <no-reply@typo3.com>
Tested-by: Sybille Peters's avatarSybille Peters <sypets@gmx.de>
Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
Reviewed-by: default avatarJoshua Westerheide <account@jdoubleu.de>
Tested-by: default avatarJoshua Westerheide <account@jdoubleu.de>
Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
Tested-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      94acfea0
    • Joshua Westerheide's avatar
      [BUGFIX] Correct wrong type annotation for drawItem_footer hook · b6fbbfcd
      Joshua Westerheide authored and Andreas Fernandez's avatar Andreas Fernandez committed 
      Change-Id: I10e4061dcb54dda3460d248bc7ae436ee12103a0
Resolves: #84636
Releases: master, 8.7
Reviewed-on: https://review.typo3.org/56575

Reviewed-by: Wouter Wolters's avatarWouter Wolters <typo3@wouterwolters.nl>
Tested-by: default avatarTYPO3com <no-reply@typo3.com>
Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
Reviewed-by: Jan Helke's avatarJan Helke <typo3@helke.de>
Tested-by: Jan Helke's avatarJan Helke <typo3@helke.de>
Reviewed-by: default avatarTim Schreiner <schreiner.tim@gmail.com>
Tested-by: default avatarTim Schreiner <schreiner.tim@gmail.com>
Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
Tested-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      b6fbbfcd
  25. 05 Apr, 2018 2 commits
  27. 04 Apr, 2018 2 commits
  29. 01 Apr, 2018 1 commit
  31. 30 Mar, 2018 1 commit
  33. 29 Mar, 2018 3 commits
  35. 22 Mar, 2018 1 commit
  37. 21 Mar, 2018 2 commits
  39. 18 Mar, 2018 4 commits
  41. 17 Mar, 2018 4 commits