If the router did not resolve a SiteLanguage for the current Site, the call of $site->getRouter()->matchRequest($request, $previousResult); in \B13\JustInCase\Middleware\LowerCaseUri::process will cause a TypeError in \TYPO3\CMS\Core\Routing\PageRouter::matchRequest in TYPO3 11.5.30.

How to reproduce

Have a site with one or more langage, but no language has an empty, or just a slash, as slug as entry. Similar to this site config:

base: 'https://my.site/'

languages:
  - title: English
    languageId: 0
    base: /en
    # ....
  - title: Italian
    languageId: 1
    base: /it
    # ...

Now call an URL without any of those prefixes, eg. https://my.site/not/existing/site.

The expected behaviour would be a 404 page, instead a 503 error and message is shown.

Possible fix

When changing the lines

$site->getRouter()->matchRequest($request, $previousResult);
return $handler->handle($request);

in \B13\JustInCase\Middleware\LowerCaseUri::process to

if ($previousResult->getLanguage()) {
    $site->getRouter()->matchRequest($request, $previousResult);
}

return $handler->handle($request);

It works as expected. Also the lowercase redirects work for URLs with a prefix.

Hi there,

when updating to the latest TYPO3 10.4.36 version (for obvious security reasons), one of our customers site broke.

This is our site configuration. The expected behaviour (as it was before and how it works if we disable justincase) is that on access to / you'll get redirected to /en/:

base: '/'
disableStaticFileCache: false
errorHandling:
 -
   errorCode: '404'
   errorHandler: Page
   errorContentSource: 't3://page?uid=87'
languages:
 -
   languageId: '0'
   title: English
   navigationTitle: en
   base: /en/
   locale: en_GB.UTF-8
   iso-639-1: en
   hreflang: en-GB
   direction: ltr
   typo3Language: default
   flag: en-us-gb
   enabled: true
   websiteTitle: ''
   fallbackType: strict
   fallbacks: ''
 -
   languageId: '1'
   title: Deutsch
   navigationTitle: de
   base: /de/
   locale: de_CH.UTF-8
   iso-639-1: de
   hreflang: de-CH
   direction: ltr
   typo3Language: de
   flag: de
   enabled: true
   websiteTitle: ''
   fallbackType: strict
   fallbacks: ''
 -
   languageId: '2'
   title: Francais
   navigationTitle: fr
   base: /fr/
   locale: fr_CH.UTF-8
   iso-639-1: fr
   hreflang: fr-CH
   direction: ltr
   typo3Language: fr
   flag: fr
   enabled: true
   websiteTitle: ''
   fallbackType: strict
   fallbacks: ''
rootPageId: 1
websiteTitle: 'Customers page'
imports:
 -
   resource: ../global/route-enhancers.yaml

routeEnhancers:
  PageTypeSuffix:
    type: PageType
    default: ''
    index: ''
    map:
      .html: 0
      rss.xml: 10
      sitemap.xml: 1533906435

1. Something has changed in TYPO3 10.4.36 (or probably earlier => I was able to confirm that this has to with the latest change in TYPO3 10.4.36) that disallows "null" als LanguageObject (or maybe this was already the case before but the way the information is usually gathered changed).
2. Nothing more... :-/

I don't like to create tickets without having an idea on how to fix this but I was sadly unable to find the reason why this happens :-( I hope you are luckier.

Best Regards
Tizian

A PHP Warning is generated on every page if you don't have a "settings" section in your site config (PHP 8.1). To fix, change line 45 of LowerCaseUri.php from:

$doRedirect = (bool)$site->getConfiguration()['settings']['redirectOnUpperCase'] ?? false;

to

$doRedirect = (bool)($site->getConfiguration()['settings']['redirectOnUpperCase'] ?? false);

What are your plans here?

As your middleware sets the incoming urls to lowercase, all sys_redirect-records do not match, if they are not written in lowercase.

Perhaps you can add a notice for this to your Readme.

This query helps solving this topic for existing records:
UPDATE sys_redirect set source_path = LOWER(source_path);

https://github.com/b13/justincase/blob/master/src/Middleware/LowerCaseUri.php#L50

The http status code is hardcoded. It would be nice if we can change the status code via settings.

Hi there,
I found out the hard way that justincase breaks the links generated by ext:secure_downloads

Thanks to the other issue, i hotfixed it like this:
insert here src/Middleware/LowerCaseUri.php at line 36

        // TODO: if securedl is installed, get securedl prefix
	    if (str_contains($path, 'securedl')) {
		    return $handler->handle($request);
	    }

No matter what case your URL is, we'll hit it.

I have encountered a situation, where ext:justincase makes the opposite: it makes originally matching/working URLs suddenly not matching anymore.

Something is mentioned in the README already - but is misleading:

Caveats
If specific route enhancers check on camel-case (e.g. {order}/paymentForm/) this might lead to unexpected behaviours and 404 pages.

It fails even if the route-enhancer routePath casing is correct. Any route-argument which is not fully lowercase makes it break (404 exception).

See for more information: https://forge.typo3.org/issues/92565

Hi,

Line 45 in /typo3conf/ext/justincase/src/Middleware/LowerCaseUri.php generates a PHP Warning in Typo3.11.5.16 and PHP 8: Undefined array key.
$doRedirect = (bool)$site->getConfiguration()['settings']['redirectOnUpperCase'] ?? false;
should be:
$doRedirect = (bool)($site->getConfiguration()['settings']['redirectOnUpperCase'] ?? false);

Kind regards

Tomas

https://github.com/b13/justincase/blob/master/src/Middleware/LowerCaseUri.php#L35

Should we perhaps change strtolower to multibyte? I have a similar solution here and unfortunately also umlauts, so that was necessary.

PS: I didn't know about your extension until now, otherwise I would have used this ;-)

Maybe its something not for this; but I had to manually do this in my own environment and wanted to mention it here:

I have a middleware handling 'secured' files to find the files and serve the file to the browser. As this is processed through middleware the justincase extension lowercased the filepath too; resolving into unknown files.

I fixed this with the following code before the lowerstring check is executed:

       // Safe check that no direct file is requested
        $absolutePath = GeneralUtility::sanitizeLocalUrl(Environment::getPublicPath() . $path);
        if (file_exists($absolutePath)) {
            return $handler->handle($request);
        }

Do you think this should be added for possible other conflicts too?