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.

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.

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/

Bad access the editor from within a dialog

See https://www.woltlab.com/community/thread/295640-%C3%BCber-medien-hinzugef%C3%BCgtes-bild-l%C3%A4sst-sich-nach-der-entfernung-nicht-direkt-erneu/

Merge pull request #4833 from WoltLab/mobile-right-sidebar

Show content of the right sidebar below the main content (mobile view)

Show content of the right sidebar below the main content (mobile view)

Remove obsolete upgrade workaround for AJAX* controllers

Merge pull request #4832 from WoltLab/route-handler-get-default-controller

Remove RouteHandler::getDefaultController()

Merge pull request #4831 from WoltLab/request-handler-in-rescue-mode

Deprecate RequestHandler::inRescueMode()

Merge pull request #4830 from WoltLab/landingPage

Remove magic numbers from RoutingCacheBuilder's landingPages data

Merge pull request #4829 from WoltLab/wcf-default-controller

Remove upgrade workarounds for default controller of `wcf`

Merge pull request #4828 from WoltLab/acp-login-redirect

Remove enforced redirect of `login` and `index` controller in ACP to the `wcf` application

Remove RouteHandler::getDefaultController()

This method was unused and returned questionable data as the administrator is
free to configure a differing landing page / default controller.

Require a `controller` for non-`wcf` links in ACP

Stop calling RequestHandler::inRescueMode()

Deprecate RequestHandler::inRescueMode()

This method was unable to return anything except true.

Remove magic numbers from RoutingCacheBuilder's landingPages data

Remove odd `\array_slice()` call in RoutingCacheBuilder::handleLandingPageWithOverriddenApplication()

This is a simple assignment with extra steps. It definitely is no longer
required since e9e0e45c728a24aa49c00b0d51679ede40ad43df and likely was not
required even before that.

Use INNER JOIN in RoutingCacheBuilder::getCustomUrls()

The FOREIGN KEY guarantees that the row in wcf1_page exists.

DRY up abbreviation retrieval in RoutingCacheBuilder::getCustomUrls()

Fix code style in RoutingCacheBuilder

DRY up the conversion of class name to controller name in RoutingCacheBuilder

Return updated data in RoutingCacheBuilder::handleLandingPageWithOverriddenApplication()

see 662b3c73f9cffedca8c9c88397313f4aec243a77

Replace `strpos()` by `str_starts_with()` in RoutingCacheBuilder

Shorten overly long line in RoutingCacheBuilder

Move `->isDefaultController()` check from `RequestHandler::handleDefaultController()` to `::buildRequest()`

This makes the data flow more clear, because `handleDefaultController()` will
only be called if we're actually dealing with the default controller.

Remove dead branch in RequestHandler::handleDefaultController()

`$data` is guaranteed to be non-null since the previous commit.

Remove dead branch in ControllerMap

The `wcf` application will have the landing page as its landing page.

Remove obsolete workaround for the 2.1 to 3.0 upgrade from RoutingCacheBuilder

Remove enforced redirect of `login` and `index` controller in ACP to the `wcf` application

It is not clear why this was added in d49006fac289699c925a6d5644f102b7ebfc972c,
but it does not appear to still be required. The login check in WCFACP
correctly redirects to the `wcf` app even if an application controller is
requested. The index controller redirect was cleaned up in the previous commit.