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'

Update to setup-node@v3

Merge branch '5.4' into 5.5

Update to setup-node@v3

Merge branch '5.5'

Merge branch '5.4' into 5.5

Check the WCF_VERSION only if the result might have changed

Add workflow to check the WCF_VERSION

Missing update of the package version

Fix code style

see 598b72301a2cdcd0f3a0c1196f6fc1107e01650e

Move system environment check into a middleware

Adjust PHP versions in environment check for 5.6

see 598b72301a2cdcd0f3a0c1196f6fc1107e01650e

Merge branch '5.5'

Adjust PHP versions in environment check for 5.5

see 598b72301a2cdcd0f3a0c1196f6fc1107e01650e

Merge branch '5.4' into 5.5

Adjust PHP versions in environment check for 5.4

see 598b72301a2cdcd0f3a0c1196f6fc1107e01650e

Merge branch '5.3' into 5.4

Merge branch '5.2' into 5.3

Adjust PHP versions in environment check for 5.2

see 598b72301a2cdcd0f3a0c1196f6fc1107e01650e

Merge branch '3.1' into 5.2

Merge pull request #4840 from WoltLab/system-environment-check

Add basic check for the runtime environment

Add basic check for the runtime environment

Running WoltLab Suite in an unsupported environment might work for the
majority of requests, some requests might fail very visibly. But there
also is a third type: A request that *appear* to execute properly, but
that subtly behaves incorrectly, due to a change in PHP's behavior.

The latter type is dangerous, as those requests might introduce errors
into the dataset that are very hard to impossible to correct after the
fact because the necessary information to fix up the data is no longer
available.

Prevent this situation from occuring by performing a basic test of the
runtime environment and halting processing early if this test fails to
ensure that it processed as little as possible.

Enable HTML escaping of `->errorMessage` in packageUpdateServerList.tpl

This is not exploitable for a full-blown XSS attack, as any HTML tags are
stripped. Nonetheless the `"` character can cause issues, as the value is also
displayed in an HTML attribute and the error message contains uncontrolled
content.

Merge pull request #4839 from WoltLab/sessionhandler-language-ids

Deprecate SessionHandler::getLanguageIDs()

Remove useless calls to `->setAccessible()` for Reflection

These are no longer required as of PHP 8.1.

Remove incorrect use of `@` from WCFSetup templates

Most of these values appear in attributes where `"` must be escaped. While the
`"` cannot appear in some of the values, WCFSetup is not performance critical,
so simply remove them everywhere to save the developer from needing to think
about this.

Remove useless `isset()` check before calling `unset()` in LinkHandler::getLink()

Merge branch '5.5'

Release 5.5.0 Beta 4

Updating minified JavaScript files

Rebuild compiled JavaScript

see 616e644de7e6954572b09e01d38f907b82bcf778

Updating minified JavaScript files

Merge pull request #4838 from WoltLab/custom-color-picker

Custom color picker implementation

Simplified the code a bit

Co-authored-by: Tim Düsterhus <duesterhus@woltlab.com>

Deprecate SessionHandler::getLanguageIDs()

This method is currently unused and basically only wraps
User::getLanguageIDs().

As it is unused the WCFSetup workaround should no longer be required either.

Merge pull request #4837 from WoltLab/styleID-session

Remove styleID from SessionHandler

Fix SystemCheckPage

see 9870f6ffe5a52130e858777cec48f0576a625a4a

Incorrect calculation of the saturation

Clean-up of legacy files, FF workaround

Unified the phrases for the color picker

Do not use RequestHandler::redirect() for controller-less ACP requests

Specifically do not pass the unknown `$routeData` which might not be correct
for the IndexPage of `wcf`.

see ed55fc721676e3a5b7cf52995c2f2701a4902f1e

Overhauled color picker with RGBA and HSL

Support for RGB <-> HSL

Remove styleID from SessionHandler

See 094ee7c31ce505b293fc228d6831ecb4a42130cc for the majority of performed
changes.

Resolves #4835

Merge branch '5.5'

Re-deprecate SessionHandler's styleID functionality

see 094ee7c31ce505b293fc228d6831ecb4a42130cc

Revert "Prevent saving `styleID` in sessions for user"

The intention behind that change still is valid. However using the
`StyleAction::changeStyle()` method which internally uses
`UserAction::update()` internally is problematic, due to events firing. At the
point where `initStyle()` runs, the applications are not yet initialized and
thus the event listener classes of applications will not be found by the
autoloader.

With bb2430b495a4bfe7e8f205b97749f49ce4f59229 the handling of the `styleID`
parameter is already removed, thus ultimately solving the same problem, but
without the issues.

This reverts commit cc5207457ef1157b44ecad54db32ab7438a1158e.

Merge branch '5.5'

Use separate inputs for the RGB color channels

Search for author without search term was not possible

Removed an outdated webkit work-around

This was required in <= 5.4 to fix an issue caused by the `transform: translateX(-50%)` offset used in these versions. 5.5 uses a pixel-perfect positioning that no longer relies on this hack.

Missing removal of existing error messages

See https://www.woltlab.com/community/thread/295622-bitte-f%C3%BCllen-sie-dieses-eingabefeld-aus-doppelt-angezeigt/