Skip to content
Snippets Groups Projects
  1. Jul 07, 2023
  2. Jul 06, 2023
  3. Jul 05, 2023
  4. Jul 04, 2023
  5. Jul 03, 2023
    • Benni Mack's avatar
      [TASK] Re-introduce hreflang attribute of site language configuration · 7287107f
      Benni Mack authored
      The site language's configuration setting "hreflang" was
      deprecated with #99908, however, it still serves a valid purpose.
      
      If working with EXT:seo and the <link rel="alternate"> tags,
      it is still valid and possible to set a specific "hreflang" attribute.
      
      Example setups:
      * You have "German (Germany)" (which is using de-DE as locale)
        and "German (Austria)" (which is using de-AT as locale).
        here you want to set "de" as generic fallback in the "de-DE" locale
        when using hreflang attributes.
      * You want to explicitly set "x-default" for a specific language,
        which is clearly not a valid language key.
      
      This change does the following:
      * It re-adds the hreflang property to be managed by the UI, however
        it is empty by default and will fallback to the $locale->getName().
      * It is not used within the <html lang="..."> attribute anymore as this
        was a mis-use in the first place (and now properly using just the
        language key, see
        https://www.w3.org/International/questions/qa-html-language-declarations.en.html#attributes
      * The method "SiteLanguage->getHrefLang()" is not deprecated anymore.
      * The RST is adapted accordingly
      
      Still, the relevant information is: The site language configuration
      option "hreflang" is not relevant anymore for regular websites without
      rendering hreflang tags, but is now customizable, and has a proper
      fallback.
      
      Resolves: #101160
      Resolves: #95798
      Related: #99908
      Releases: main, 12.4
      Change-Id: Ifc5b5b10ba46b4da4abd5c504d4d69f240f2fd02
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/79545
      
      
      Reviewed-by: default avatarBenni Mack <benni@typo3.org>
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Tested-by: default avatarBenni Mack <benni@typo3.org>
      7287107f
  6. Jun 28, 2023
  7. Jun 26, 2023
  8. Jun 15, 2023
    • Stefan Bürk's avatar
      [BUGFIX] Avoid dirty `SilentConfigurationUpgradeServiceTest` test setup · 7cac1565
      Stefan Bürk authored
      With #100407 the `SilentConfigurationUpgradeServiceTest` has been
      promoted from a unit test to a functional test to avoid a mocking
      party.
      
      Tests in this test cases write "test configuration" to the test
      instances `LocalConfiguration.php` file. For this the update method
      `ConfigurationManager->updateLocalConfiguration` is used to set
      the test configuration upon the generated test-instance config.
      
      Secondly, the `SilentConfigurationUpgradeService` is used to check
      for changed configurations. This service also updates the config,
      even if not reloading it. Reload would be done for the next test.
      
      These two facts together leads to dirty LocalConfiguration.php for a
      test. Deterministic setup per test is not guaranteed, because the
      configuration is not properly cleaned up after a test.
      
      This change stores the functional test instances configuration
      in `setUp()` and restores it in `tearDown()`, using the
      write method `ConfigurationManager->writeLocalConfiguration()`.
      This resets `LocalConfiguration.php` to the state which has
      been created by the testing-framework.
      
      The correct expectation, that no change happened, is set for
      `versionNumberInFilenameSetToTrueStaysUntouched`.
      
      Resolves: #101075
      Related: #100407
      Releases: main, 12.4
      Change-Id: I18dd80fee04cc27cbb709cfb1c7494dc975edc42
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/79412
      
      
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Reviewed-by: default avatarOliver Klee <typo3-coding@oliverklee.de>
      Tested-by: default avatarNikita Hovratov <nikita.h@live.de>
      Reviewed-by: default avatarNikita Hovratov <nikita.h@live.de>
      Tested-by: default avatarOliver Klee <typo3-coding@oliverklee.de>
      7cac1565
  9. Jun 14, 2023
  10. Jun 13, 2023
  11. Jun 11, 2023
  12. Jun 10, 2023
    • Helmut Hummel's avatar
      [TASK] Use dedicated cache for schema information · 17f4346c
      Helmut Hummel authored
      Using the core cache for schema information comes with
      various drawbacks:
      
      1. There is no way to flush single core cache entries,
         thus the complete core cache needs to be flushed when
         changing the database schema.
      2. The PHP Frontend provides no benefit, when the to be cached
         information has to be serialized anyway.
      
      Therefore, a new cache is introduced that can be flushed
      individually after schema updates.
      
      Flushing the cache is now also moved altogether to SchemaMigrator,
      in order to avoid flushing the cache multiple times for multiple
      connections. For flushing the individual cache, the internal
      Bootstrap::createCache factory is used, which ensures a cache
      backend, which is not set to null backend, which happens
      with late boot methodology in install tool and replaces the
      previously used ClearCacheService, which is only meant to be
      used to flush all caches and boots the system for that.
      
      With doing so, the previously introduced argument to not
      boot the system can be removed again.
      
      As drive by change the SysLogChannel update is renovated
      a bit to not use deprecated Doctrine DBAL API.
      
      Releases: main, 12.4
      Resolves: #100925
      Change-Id: I0193501fec5d41edfcb65f07faefe30985629818
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/79220
      
      
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Tested-by: default avatarStefan Bürk <stefan@buerk.tech>
      Reviewed-by: default avatarStefan Bürk <stefan@buerk.tech>
      17f4346c
  13. Jun 01, 2023
  14. May 26, 2023
  15. May 17, 2023
  16. May 15, 2023
  17. May 11, 2023
    • Sybille Peters's avatar
      [BUGFIX] Only send test email if sender address configured · 14f82833
      Sybille Peters authored
      It is possible to send a test email in the Environment
      section of the Install Tool / Admin Tools.
      
      Previously, if the sender email was not configured via
      $GLOBALS['TYPO3_CONF_VARS']['MAIL']['defaultMailFromAddress']
      a default no-reply email address was used.
      
      Also, the sender email was not checked with GeneralUtility::validEmail.
      
      We now display a message in the dialog if the defaultMailFromAddress
      is not configured or is configured with an invalid email address.
      In this case, the form with input field and button is also not displayed.
      
      Sending with an invalid sender address is no longer possible
      in Test Mail Setup.
      
      The problem with the previous behavior was:
      
      - Not setting the value or setting it incorrectly is incomplete
        configuration. We should make the user aware of this. The point
        of sending a test mail is to test the configuration as well.
      - Emails with a sender address which does not exist or is not
        registered for the mail account might get rejected by the
        email server but the user gets no error message, so is kept
        in the dark.
      - Notifications from the mail server cannot be sent back if a
        no-reply email is used. If someone configures it that way,
        that is their responsibility, but we should not fall back
        to it.
      
      Resolves: #100084
      Releases: main, 12.4
      Change-Id: Ie9ad6eda320791ac27d81f109c4d253da63ace20
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/78978
      
      
      Tested-by: default avatarStefan Bürk <stefan@buerk.tech>
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Reviewed-by: default avatarStefan Bürk <stefan@buerk.tech>
      14f82833
    • Benni Mack's avatar
      [BUGFIX] Ensure SchemaMigrator does not re-apply ext_localconf.php · 753f8957
      Benni Mack authored
      SchemaMigrator / ConnectionMigrator calls
      ClearCacheService->clearAll(), which in turn
      just re-applies ext_localconf.php and ext_tables.php,
      which in turn could re-apply hooks which have been
      registered via
      
      $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_tcemain.php']['processDatamapClass'][] = MyHook::class;
      
      Thus, for such cases, it is important the ext_localconf.php
      is not loaded again.
      
      clearAll() now has an optional argument, to flush caches
      (due to configuration changes, or with DB upgrade in place) so
      they are completely emptied
      
      This is less "brutal" than the original "clearAll" method, as it does
      not re-load TYPO3_CONF_VARS.
      
      This problem comes from https://review.typo3.org/c/Packages/TYPO3.CMS/+/76553/20/typo3/sysext/core/Classes/Database/Schema/SchemaMigrator.php
      
      The solution can be found in the now corrected test in EXT:webhooks,
      which actually registers a hook like this.
      
      Resolves: #100840
      Related: #99062
      Releases: main, 12.4
      Change-Id: I9d53df80b119cfec37a5d8d40d5fbd881b14307f
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/78976
      
      
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Tested-by: default avatarStefan Bürk <stefan@buerk.tech>
      Reviewed-by: default avatarStefan Bürk <stefan@buerk.tech>
      753f8957
  18. May 09, 2023
  19. May 08, 2023
  20. Apr 28, 2023
  21. Apr 26, 2023
  22. Apr 25, 2023
  23. Apr 24, 2023
  24. Apr 20, 2023
  25. Apr 18, 2023
  26. Apr 17, 2023