Merge pull request #4853 from WoltLab/wcfsetup-asset-cleanup

Clean up asset handling in WCFSetup

Use explicit null favicon in WCFSetup to prevent /favicon.ico requests

Technique taken from here: https://stackoverflow.com/a/38917888/782822

Remove Font Awesome from WCFSetup

WCFSetup does not use any icons, thus there is no need to load them.

Merge branch '5.5'

Merge branch '5.4' into 5.5

Release 5.4.19

Add `#[\SensitiveParameter]` attribute to a large number of parameters

see #4802

Merge pull request #4851 from WoltLab/request-cleanup

Clean up wcf\system\request\Request

Do not modify state in RequestHandler::buildRequest()

Improve typing in \wcf\system\request\Request

Make \wcf\system\request\Request externally immutable

Remove deprecated Request::isExecuted()

Merge branch '5.5'

Fix update instructions from 5.4

Release 5.5.0 RC 1

Updating minified JavaScript files

Add symfony/polyfill-php82 composer dependency

see #4802

Update composer dependencies

Merge branch '5.5'

Clear `AVAILABLE_UPGRADE_VERSION` for 5.5

see 15933d22a95b67d57ae794a88471098326911aba

Merge branch '5.4' into 5.5

Inconsistent behavior of text formatting on iPadOS

See https://www.woltlab.com/community/thread/295811-schriftfarbe-schriftart-oder-schriftgr%C3%B6%C3%9Fe-%C3%A4ndern-auf-ipad/

Missing comma

Broken auth dialog for package update servers

See https://www.woltlab.com/community/thread/295831-fehler-beim-update-beta-3-4/

Aborting a previously successful worker failed

See https://www.woltlab.com/community/thread/295857-schlie%C3%9Fen-des-dialogs-beim-anzeigen-aktualisieren-unterbricht-das-aktualisieren/

Merge pull request #4852 from WoltLab/upgrade-to-55

Enable the upgrade to WoltLab Suite 5.5

Incorrect URL for the upgrade instructions

Enable the upgrade to WoltLab Suite 5.5

Based on 41f100782ce6abe92f144810b719c15e53bf4849

Drop WebP check from PackageEnableUpgradeOverrideForm

Merge branch '5.5'

Sync update_com.woltlab.wcf_5.5_ensureInnoDbSearch.php with PackageEnableUpgradeOverrideForm

see 94607cf2b21854a52f2805ad4211b74d6d9cbe96

Merge branch '5.4' into 5.5

Merge pull request #4849 from WoltLab/package-override-55

Update checks in PackageEnableUpgradeOverrideForm for 5.5

Improve issue description in PackageEnableUpgradeOverrideForm

Fix PackageEnableUpgradeOverrideForm

The form differs from the update scripts by also having a title for each issue.

Merge branch '5.5'

Merge branch '5.4' into 5.5

Drop files_pre_check.tar from 5.4 -> 5.5 upgrade

Update checks in PackageEnableUpgradeOverrideForm for 5.5

- update_com.woltlab.wcf_5.5_ensureInnoDbSearch.php

Drop duplicate empty line in RequestHandler

Re-add search addon to CodeMirror

The browser search does not work well with CodeMirror, re-add the search addon
to make Ctrl+F work more or less as expected.

This got lost when CodeMirror was adjusted to make use of require.js in
480b6b11d0822015d4fe4515e7a72b495fe78a69.

Incorrect tracking of open page overlays

Calling this method (implicitly) while the dialog is still open causes the same dialog to be counted multiple times.

See https://www.woltlab.com/community/thread/295827-boxen-im-benutzerprofil/

Incorrect editor access from within a dialog

See https://www.woltlab.com/community/thread/295821-fehler-beim-einf%C3%BCgen-von-zitaten/

Merge branch '5.4' into 5.5

Fix update instructions from 5.4

Preset was lacking the inversion of permissions

See https://www.woltlab.com/community/thread/295793-box-kopieren-option-wird-nicht-%C3%BCbernommen/

Revert "Removed the upgrade instructions from 5.4.*"

This reverts commit a3f3064f44253cc761748f38742aae6027e4c2dd.

Force a refresh of CodeMirror on tab navigation

See https://www.woltlab.com/community/thread/295824-codemirror-gerne-mal-nicht-initialisiert/

Bad position of the mobile overflow indicator

See https://www.woltlab.com/community/thread/295832-men%C3%BCschatten-mobil/

Improved phrasing on the behavior of polling

See https://www.woltlab.com/community/thread/295788-fehlerhafte-sprachvariable-wcf-acp-option-enable-polling-description/

Merge pull request #4846 from WoltLab/i18n-landing-page

Fix handling of i18n landing pages

Remove the soft redirect for landing page i18n CMS pages

This is no longer required since the previous commit which ensured that i18n
CMS landing pages will *always* perform the redirect.

This likely should be improved in a follow up commit to perform the redirect in
RequestHandler / ControllerMap::lookupDefaultController(), instead of relying
on the URL canonicalization feature, as this allows for a more fine-grained
control over the redirect, e.g. allowing to set a `vary: accept-language`
response header.

Do not strip the controller in URLs for i18n landing pages

Previously using an i18n CMS page as the landing page caused very odd behavior
as described in commit 0c03edef97240baa6374ce59e986245fb8ffedec.

Landing pages naturally cannot contain a language specific custom controller as
they don't have a controller within the URL, thus requests to the landing page
URL need to be dispatched to one of the languages in
ControllerMap::lookupDefaultController().

It was decided to dispatch to the user's current language which certainly is
the best solution from the UX perspective.

However this dynamic dispatch is problematic, because for i18n landing pages
the variant with the default language was also proclaimed to be the default
controller in ControllerMap::isDefaultController(), thus stripping it from the
language specific custom controller.

Ultimately this overloaded accesses to the landing page to both mean “the
default language” and “whatever language the user uses” at the same time,
unpredictably returning either a HTTP 200 or a HTTP 307 when canonicalizing the
URL in CmsPage depending on the user's language, ultimately dropping the
landing page from the search index of common search engines when it is crawled
in a non-default language.

Fix this whole mess by not stripping the controller from the URL for i18n
pages, allowing every language, including the default language, to have a
stable URL that will always return a HTTP 200 no matter the user's language.
The landing page will then dynamically redirect to the user's language,
preserving the UX enhancement without any of the drawbacks.

Remove dead branch in ControllerMap::lookupDefaultController()

It was impossible to take this branch since
d10487d5b8f54ce86fa8d8f36649febd338dbae8, because since this commit i18n CMS
pages (which this branch was about) were unable to have an empty custom URL.

Since 1bfaae39040d6b56ed837b5c66aa7931ffaca9b5 it is entirely impossible for
any empty custom URLs to exist, making this branch completely dead.

Further it only ever supported the WCF landing page, not any application's
landing pages.

The original intent of this branch will be restored in a follow up commit.

Merge pull request #4847 from WoltLab/ci-controller-lookup

Remove reverse lookup for RoutingCacheBuilder::getCaseInsensitiveControllers()

Remove reverse lookup for RoutingCacheBuilder::getCaseInsensitiveControllers()

This reverse lookup is not used, drop it to simplify the logic.

Remove useless temporary in RoutingCacheBuilder::getCustomUrls()

Simplify RoutingCacheBuilder::getCustomUrls()

By creating the arrays for all known abbreviations early we can avoid checking
the existence of them over and over again.

Simplify `isset()` check in ControllerMap::lookup()

The first test was a prefix of the second, thus it is implicitly checked.

Simplify `isset()` check in ControllerMap::resolve()

The first test was a prefix of the second, thus it is implicitly checked.

Also run the `wcf` check in all cases, while this might check the same entry
twice for `$application == 'wcf'`, this will not have a relevant performance
impact and make the code much more readable.

Merge branch '5.5'

Merge branch '5.4' into 5.5

Create the initial user with a non-NULL signature

see #4845
see 8cf90dac71a2e42c56dafba6e23f0dd5a1c5d64c

Fix PHP 8.1 compatibility in UserRebuildDataWorker for NULL signatures

see #4845

Release 5.4.18

Adjust PHP versions in environment check for 5.5

see 598b72301a2cdcd0f3a0c1196f6fc1107e01650e

(cherry picked from commit c2ae090f6bf0a0eefd5eaf9796095a4ddd18c23a)

Merge pull request #4844 from WoltLab/custom-controller

Clean up handling of custom controllers

Remove now-unused $landingPages parameter from RoutingCacheBuilder::getCustomUrls()

Remove dead branch in ControllerMap::isDefaultController()

Since the previous changes it is impossible for an entry `''` to exist in the
custom URL mapping, causing this branch to never be taken.

This essentially reverts e6fac1cae9428760436179efc10cc7989c2d64b9.

Revert "Revert "Reject empty `controller` in ControllerMap::resolveCustomController()""

This check will now work correctly, since the custom URL for non-i18n pages is
no longer cleared since the previous commit.

This reverts commit bd46b32207b5784c481277f4c2a8c81deff49f9c.

Remove logic for the clearing of custom URLs for CMS pages from RoutingCacheBuilder

This is workaround is no longer required or useful since the previous commit,
since `ControllerMap::isDefaultController()` will correctly return `true` for
those CMS pages, leading to the route builder dropping the controller part in
the URL.

Updating minified JavaScript files

Release 5.4.17

Merge branch '5.3' into 5.4

Release 5.3.23

Merge branch '5.2' into 5.3

Skip page content without custom URL in RoutingCacheBuilder::getCustomUrls()

This select was missing this condition ever since it was added in commit
c2de61fb187cf357cd9653693a8fa7cad39ca6ef. It is not entirely clear, why this
condition is missing, but everything indicates that this is a bug:

The customURL for the page content can only ever be missing for pages backed by
an actual controller (i.e. non-CMS pages).

All those pages having the same empty controller will lead to conflicts in the
resulting mapping table, with some undefined entry "winning" and ending up in
the table. This specifically nullifies the effort of clearing the custom URL
for non-i18n CMS pages that are landing pages. However by chance this all ends
up working as intended, because the look up of the custom URL for those CMS
pages will then result in an empty string for the controller, which is then
completely ignored by the route building, skipping the logic in
ControllerMap::isDefaultController() which relies on the empty controller
pointing to the landing page instead of some random page.

Clean this up by properly ignoring page content without a custom URL.

Release 5.2.21

Reduced width of dropdown menus in mobile view

Merge branch '3.1' into 5.2

Release 3.1.29

Merge pull request #4842 from WoltLab/landing-page-cleanup

Remove Page::$isLandingPage

Update composer dependencies

Merge branch '5.5'

Update composer dependencies

Add database/update_com.woltlab.wcf_5.6.php

Simplify RoutingCacheBuilder::getLandingPage()

Reduce the amount of special handling required for the 'wcf' app.

Remove the Page::$isLandingPage property

This property is redundant with wcf1_application.landingPageID for the 'wcf'
app. Previously it needed to be kept in sync across both tables which didn't
really work well in all cases. Remove this property to gain a single source of
truth for the landing page.

Check the landing page against PageCache::getLandingPage() in PageLocationManager

The landing page returned by `PageCache` is the landing page as used everywhere
else. Use that one instead of checking the property for consistency.

Remove bogus `$menuItem->isLandingPage` check from acp/menuItemAdd.tpl

This property doesn't exist and even if it would exist, this change would only
be applied in the template, not in PHP. And even if the check would be applied
in PHP, it would not be required. It is perfectly supported to disable all menu
item, including the landing page's. It looks a bit odd, but does not cause
errors.

Revert "Reject empty `controller` in ControllerMap::resolveCustomController()"

The assumptions in the commit message are not currently valid: For a non-i18n
CMS page the RoutingCacheBuilder will clear out the custom URL.

This reverts commit 4a40217a1e5bfe9a2f7d9f4b7c485add6baa7213.

Merge pull request #4841 from WoltLab/routing-cleanup

Further cleanup of the routing logic

Add proper types to ControllerMap::isDefaultController()

Remove useless branch in ControllerMap::isDefaultController()

The previous change with `str_starts_with()` makes it pretty evident that this
condition is redundant with the regular expression above: The regular
expression also ensures that the `$controller` starts with `__WCF_CMS__` and at
the end of that branch the `$controller` will always be stripped of the
language ID suffix.

Use `str_starts_with()` in ControllerMap::isDefaultController()

This replacement is not semantically identical, because the previous version
effectively was a `str_contains()`. However the `__WCF_CMS__` marker always
appears at the start of the string, making the previous version a bug.

Remove useless use of `else` in ControllerMap::isDefaultController()

The “then” part always returns from the function, thus there is no need for an
explicit `else` here.

Simplify `isset()` check in ControllerMap::resolveCustomController()

The first test was a prefix of the second, thus it is implicitly checked.

Reject empty `controller` in ControllerMap::resolveCustomController()

Based on the current callers of this method it is impossible that an empty
string is passed in:

- In LookupRequestRoute the matched controller will always contain a non-slash
  character, unless the URL itself only consists of slashes, which is rejected
  early.
- In ControllerMap::lookupDefaultController() the method will only be called if
  the `routePart` of the landing page matches `__WCF_CMS__` which is only the
  case if the page does not have an controller assigned. In that case the invariant
  that a custom URL must be configured holds and `->lookupCmsPage()` will not
  return an empty controller value.

Simplify `isset()` check in ControllerMap::isDefaultController()

The first parameter was a prefix of the second, thus it is implicitly checked.

Merge branch '5.5'