Maybe implement a web service (command controller)?

We have a TYPO3 9.5 instance with a multi page tree setup and site handling enabled, so f.e.:

• Homepage EN for US
• Homepage EN for GB
• Homepage DE
• Homepage FR

All pages only have one language, the default.

I configured this extension like:

config.tx_locate = 1
config.tx_locate {
  dryRun = 0

  actions {
    redirectToPageDE {
      20 = Bitmotion\Locate\Action\Redirect
      20 {
        page = 30
        cookieHandling = 1
        overrideCookie = 1
      }
    }
    redirectToPageFR {
      20 = Bitmotion\Locate\Action\Redirect
      20 {
        page = 20
        cookieHandling = 1
        overrideCookie = 1
      }
    }
    redirectToPageGB {
      20 = Bitmotion\Locate\Action\Redirect
      20 {
        page = 10
        cookieHandling = 1
        overrideCookie = 1
      }
    }
    redirectToPageUS {
      20 = Bitmotion\Locate\Action\Redirect
      20 {
        page = 1
        cookieHandling = 1
        overrideCookie = 1
      }
    }
  }

  facts {
    browserAccepted = Bitmotion\Locate\FactProvider\BrowserAcceptedLanguage
  }

  judges {
    10 = Bitmotion\Locate\Judge\AndCondition
    10.action = redirectToPageDE
    10.matches (
      browserAccepted.locale = de_DE
      browserAccepted.lang = de
    )

    20 = Bitmotion\Locate\Judge\AndCondition
    20.action = redirectToPageFR
    20.matches (
      browserAccepted.locale = fr_FR
      browserAccepted.lang = fr
    )

    30 = Bitmotion\Locate\Judge\AndCondition
    30.action = redirectToPageGB
    30.matches (
      browserAccepted.locale = en_GB
    )

    40 = Bitmotion\Locate\Judge\AndCondition
    40.action = redirectToPageUS
    40.matches (
      browserAccepted.locale = en_US
    )

    999 = Bitmotion\Locate\Judge\Fixed
    999.action = redirectToPageUS
  }
}

With this configuration, on the first hit (without cookie) the redirect works as expected. Then the cookie is stored with the value "0" for the default language.

I would expect the the 2nd request on the domain would redirect the use to the previous calculated destination.

This doesn't happen, since all pages have the same language "id", the cookies does nothing and the redirect doesn't happen in the 2nd request.

Wouldn't it be better to store the target page UID in the cookie?

If my browser supports multiple languages (eg FR-DE-EN) and there is no dedicated condition for FR (but one for DE and the default one for EN), the default condition will be applied.

Hello,

I'm making an ajax request which get redirected by this plugin. The problem is that postdata is missing in the redirected call. Is that a known issue? Or am I missing something in my configuration?

It is possible to set a target page uid and a target sys_language in typoscript settings.

But in locate/Classes/Action/Redirect.php->redirectToPid() only one of them is executed.

We have a judge (based on AbstractJudge) that checks if some redirects should take place. If not it simply returns $this without setting a decision/verdict. In court.php that triggers:

No verdict should be delivered. This might be a problem in you configuration

That happens if decision is not set or if the verdict is not set. Imho it should be possible to take no decision. Otherwise we'd maybe need a "null-decision"?

Please Update the Documentary under
https://docs.typo3.org/p/leuchtfeuer/locate/main/en-us/Functions/AssignLanguage/Examples/Index.html

The value config.tx_locate.simulateIp is required

Hi,
I need the resolution of the client IP to the country for my extension.
So I installed locate and used the function LocateUtility::getCountryIso2FromIP.
Unfortunately, this does not return a country code for the client PI v6 (v4 works).
So I debugged and found that the typecast to integer in function getNumericIp line 49
return (int)base_convert(ltrim($binNum, '0'), 2, 10);
changes the decimal value so that it cannot be resolved in the database.
If you omit the typecast, then it works.

TYPO3: v10.4.17
locate: v10.0.2

Missing Dependency:
typo3-ter/static-info-tables

Error/Warning produced by Action (EXT:locate/Classes/Action/Redirect.php#240):
array_combine should be array_merge

No matter what I do the extension always picks the first judge, no matter the preferred language set in the browser. Because of this, the extension redirects to the Chinese page even though users do not have Chinese in their preferred languages!

I have the following languages on my website:

• German (Default)
• English
• Chinese
• Russian

For testing, I have the following preferred languages set in my browser (Chrome) in the following order (1 being the top priority)

1. Russian
2. German

The configuration of the verdicts and judges looks like this:

# TABLE: sys_language
#
# | uid | title     | flag | language_isocode |
# ---------------------------------------------
# |  1  | English   | en   | en               |
# |  2  | Chinese   | cn   | zh               |
# |  3  | Russisch  | ru   | ru               |
# |  4  | Arabisch  | sa   | ar               |
# |  5  | Deutsch   | de   | de               |


# verdicts
config.tx_locate {
    sessionHandling = 1
    overrideSessionValue = 1

    verdicts {
        # Redirect the user to the default language version of the current page
        redirectToPageEN = Leuchtfeuer\Locate\Verdict\Redirect
        redirectToPageEN {
            sys_language = 1
        }

        redirectToPageDE = Leuchtfeuer\Locate\Verdict\Redirect
        redirectToPageDE {
            sys_language = 5
        }

        redirectToPageCN = Leuchtfeuer\Locate\Verdict\Redirect
        redirectToPageCN {
            sys_language = 2
        }

        redirectToPageRU = Leuchtfeuer\Locate\Verdict\Redirect
        redirectToPageRU {
            sys_language = 3
        }

        redirectToPageDEFAULT = Leuchtfeuer\Locate\Verdict\Redirect
        redirectToPageDEFAULT {
            sys_language = 0
        }
    }
}

# judges
config.tx_locate.judges {    

    # chinese
    30 = Leuchtfeuer\Locate\Judge\Condition
    30 {
        verdict = redirectToPageCN
        fact = browserAcceptLanguage
        prosecution = cn
    }

    # russian
    40 = Leuchtfeuer\Locate\Judge\Condition
    40 {
        verdict = redirectToPageRU
        fact = browserAcceptLanguage
        prosecution = ru
    }

    # german
    100 = Leuchtfeuer\Locate\Judge\Condition
    100 {
        verdict = redirectToPageDE
        fact = browserAcceptLanguage
        prosecution = de
    }

    # english
    300 = Leuchtfeuer\Locate\Judge\Condition
    300 {
        verdict = redirectToPageEN
        fact = browserAcceptLanguage
        prosecution = en
    }

    # default language
    999999 = Leuchtfeuer\Locate\Judge\Fixed
    999999.verdict = redirectToPageDEFAULT
}

Describe the bug
To Reproduce
In a clean Typo3 11 installation I added the first the "static_info_tables"-Extension then locate.
I get an error 503. Same with a Typo3 10 installation.
After setting the "Configuration Presetsto" to "debug" I get the error:

Class "Leuchtfeuer\Locate\Domain\Repository\RegionRepository" not found
in [PATH_TO_DIRECTORY]/typo3conf/ext/locate/Configuration/TCA/Overrides/pages.php line 23

Further Information: Linux-System with PHP Version 8.0.22, the Typo3 system is installed with the symbolic link method. The extensions are added with the backend tool.

• httpResponseCode
• url

Drop support for:

• PHP 5.5
• PHP 5.6
• TYPO3 7 LTS

Versions

• locate 11.0.0-dev
• TYPO3 10.4.18

Description and reproduction of bug
Creating a new page via the context menu in the page tree results in the following error:

Expected behavior
Locate's version 10 works as expected and shows the page properties from the "Create new page" dialogue.

Additional information
The issue seems related to the introduced feature "access to pages based on the current country" in version 11 which extends the page properties.

In typoscript it is possible to set a "httpResponseCode"

This is saved to $config['settings']['responseCode'] here:
https://github.com/Leuchtfeuer/locate/blob/dev-10.0/Classes/Middleware/LanguageRedirectMiddleware.php#L54

But the locate/Classes/Action/Redirect.php->process() checks for the original name and casts it to (int) although it should be a string like "HTTP/1.1 301 Moved Permanently"

$this->httpStatus = $this->configuration['httpResponseCode'] ? (int)$this->configuration['httpResponseCode'] : HttpUtility::HTTP_STATUS_301;

We have Different Sites with different languages. But the languages are all sys_language_uid 0, because it's the default language for the site.

For example:


Every language is sys_language_uid 0

To reproduce this try to redirect from pages with the same sys_language_uid.

I have different verdicts:
redirectToPageFrance = Leuchtfeuer\Locate\Verdict\Redirect
redirectToPageFrance {
sys_language = 0
page = 12
}

redirectToPageBelgiqueFr = Leuchtfeuer\Locate\Verdict\Redirect
redirectToPageBelgiqueFr {
sys_language = 0
page = 11
}

redirectToPageDeutschland = Leuchtfeuer\Locate\Verdict\Redirect
redirectToPageDeutschland {
sys_language = 0
page = 1
}

The page is not redirected.

I did comment the line out:

But the redirect is not working, because the wrong site is called for the getRouter() function.

In the GLOBALS['TYPO3_REQUEST']->getAttribute('site') we get the current site. I don't know i it's possible to generate the right uri with the wrong $site variable.

the parameters are right, but the uri shows to the wrong site.

in the file:
typo3conf/ext/locate/Classes/Middleware/LanguageRedirectMiddleware.php

the line: $typoScript = $GLOBALS['TSFE']->tmpl->setup;
works only when the page is not cached. After the Page get chached, the $GLOBALS['TSFE']->tmpl->setup will return an empty array()

you should change it to:
if ($GLOBALS['TSFE']->tmpl === null || ($GLOBALS['TSFE']->tmpl && empty($GLOBALS['TSFE']->tmpl->setup))) {
$GLOBALS['TSFE']->forceTemplateParsing = true;
$GLOBALS['TSFE']->getConfigArray();
}
$typoScript = $GLOBALS['TSFE']->tmpl->setup;

in order to generate the typoscript array

Make the name and the lifetime of the cookie configurable

Are there any plans to upgrade the extension for TYPO3 12?

Either LCC or LCU

Remove the old Zend logging stuff and use TYPO3 logging instead

TYPO3 12
PHP8.1
Current Locate release

Composer Json suggests to use Static Info Tables:

The TCA file of the regions table returns an empty Array, if static info tables is not available

This is causing the following error, when creating a new record in the backend, if Static Info Tables is not installed:

(1/1) #1476107295 TYPO3\CMS\Core\Error\Exception

PHP Warning: Undefined array key "ctrl" in /var/www/html/vendor/typo3/cms-backend/Classes/Controller/NewRecordController.php line 603

Describe the bug
When using automatic language detection, it is no longer possible to manually change the language in the fronted using the language navigation. This is a problem if the user decides they prefer a language different from the automatically detected one.

Concrete example:
I have a website with multiple languages (German being the default language / fallback language of that TYPO3 website). My preferred language in the browser is set to english. Now, when I open a page in the frontend, the english version of that page is rendered (as it should, no problems so far with EXT:locate!). However, when I, as a user, now decide "but I want to view this website in German regardless of my preferred browser language" and proceed to choose "DE" from the language navigation, the english version of that page is being loaded again, which should not be the case as I intentionally selected "DE" from the language navigation!

With that being said, I am unsure if this bug is maybe only happening because I messed something up in the config!

To Reproduce
Steps to reproduce the behavior:

1. Install EXT:locate and run DB analyzer.
2. Activate automatic language detection via TS: config.tx_locate = 1
3. Write configuration in TS (setup):

# verdicts
config.tx_locate {
    sessionHandling = 1
    overrideSessionValue = 1

    verdicts {
        # Redirect the user to the default language version of the current page
        redirectToPageEN = Leuchtfeuer\Locate\Verdict\Redirect
        redirectToPageEN {
            sys_language = 1
        }

        redirectToPageDE = Leuchtfeuer\Locate\Verdict\Redirect
        redirectToPageDE {
            sys_language = 5
        }
    }
}

# judges
config.tx_locate.judges {    

    # english
    100 = Leuchtfeuer\Locate\Judge\Condition
    100 {
        verdict = redirectToPageEN
        fact = browserAcceptLanguage
        prosecution = en
    }

    # german; both for fixed and conditional judge (for good measure, as german is supposed to be the default language)
    200 = Leuchtfeuer\Locate\Judge\Condition
    200 {
        verdict = redirectToPageDE
        fact = browserAcceptLanguage
        prosecution = en
    }
    999999 = Leuchtfeuer\Locate\Judge\Fixed
    999999.verdict = redirectToPageDE
}

4. See error

Expected behavior

When I open a page in the frontend, the preferred language (set in browser) should be rendered. However when I intentionally decide to choose a different language from the website's language navigation, the page should be loaded in the language I just intentionally selected.

Desktop (please complete the following information):

• OS: 12.6.1
• Browser: all

Additional context:

• Version of locate: v12.0.3

--

Error occurs when defining a redirect action to a specific page like this:

plugin.tx_locate_pi1 = USER_INT
plugin.tx_locate_pi1 {
    userFunc = Bitmotion\Locate\Locate->main
    actions {
      redirectToPageDE {
            20 = \Bitmotion\Locate\Action\Redirect
            20.page = 25
            20.sys_language = 1
      }
      default {
            20 = \Bitmotion\Locate\Action\Redirect
            20.page = 25
            20.sys_language = 0
      }
    }

    ...
}

In this case you are not redirected to page 25 but you stay on the page where you are. The reason is, that the RedirectToPid method adds all URL parameters when trying to redirect, including the ID of the current page. The resulting redirect URL is something like this: www.example.com/index.php?id=25&L=0&id=1.

When adding the current URL parameters the parameter id should be left out if a specific page ID to redirect to has been defined.

Pull request: #4

System:

• TYPO3 12.4.14
• PHP 8.2.18
• Locate v12.0.2 (also testet with v12.0.0 and v12.0.1)

Hi there,

first of all, thanks for this extension. It is a very useful and versatile tool and I like it!

But, sorry to ask, are there any breaking changes from TYPO3 11 to TYPO3 12? I just upgraded a site and the custom FactProvider is not called anymore. I checked and double checked the typoscript configuration and I can't find any difference between the example_setup.typoscript and the custom implementation that could be the reason for this behaviour.

Is there anything one has to be aware of when upgrading from v11 to v12?

Regards
Mike

Call to undefined method Doctrine\DBAL\Driver\Mysqli\MysqliStatement::fetchOne() | Error thrown in file /var/www/html/typo3conf/ext/locate/Classes/Hook/OverrideIconOverlayHook.php in line 55

The reason is that MysqliStatement in 10.4.x does not (yet) have a function fetchOne(). But we could use fetch() instead, I guess?

Trusting on 'REMOTE_ADDR' is in (reverse) proxy setups not good enough. 'HTTP_CLIENT_IP' and 'HTTP_X_FORWARDED_FOR' should be taken into account here as well.

Describe the bug
The table static_countries is not up to date and needs to be updated.

To Reproduce

1. Set manually IP-Address to 217.91.35.16
2. When process function of IP2Country is called, no result is found

Expected behavior
Germany is found

Desktop (please complete the following information):

• OS: Ubuntu 16.04

If a user is accessing a page with a different language then current, he is being redirected to a correct language but without all get variables.

Describe the bug

• TYPO3 v12.4.14
• php 8.2
• locate

Leuchtfeuer\Locate\Middleware\LanguageRedirectMiddleware reads typoscript settings like this
$typoScript = $this->backendConfigurationManager->getTypoScriptSetup();

Reading typoscript frontend settings with the backendConfigurationManager results in unexpected behaviour with typoscript like this:

[traverse(page, "uid") in [968,967,202,965,969]]
    config.tx_locate = 0
[ELSE]
    config.tx_locate = 1
[GLOBAL]

The condition
if (isset($typoScript['config.']['tx_locate']) && (int)$typoScript['config.']['tx_locate'] === 1) {}
in LanguageRedirectMiddleware always returns true (config.tx_locate will always be 1), no matter what typoscript settings are configured. Maybe the reson is a changed behaviour in BackendConfigurationManager for TYPO3 v12. I did not dig deeper into this because there is a better, working solution:

If the typoscript setting will be read with the normal ConfigurationManager like this, it works just fine again:

/** @var ConfigurationManager $configurationManager */
$configurationManager = GeneralUtility::makeInstance(ConfigurationManager::class);
$typoScript = $configurationManager->getConfiguration(
ConfigurationManagerInterface::CONFIGURATION_TYPE_FULL_TYPOSCRIPT,
    'sitepackage'
);

As far as I see, the BackendConfigurationManager is not really supposed to read frontend typoscript code anyway. See comment at the start of the class:

/*
* Load TypoScript of a page in backend mode.
*
* Extbase Backend modules can be configured with Frontend TypoScript. This is of course a very
* bad thing, but it is how it is ^^ (we'll get rid of this at some point, promised!)
*/

To Reproduce
Steps to reproduce the behavior:
Try to read fronten typoscript settings with the BackendConfigurationManager in Leuchtfeuer\Locate\Middleware\LanguageRedirectMiddleware

I hope I did not miss anything an will create a pull request.

Regards and thanks for a great and usefull extension!!
Mike

After the Update to PHP 8.1 (TYPO3 11.5) the following errors are thrown:

1. PHP Warning: Undefined array key "tx_locate" in /html/typo3/typo3conf/ext/locate/Classes/Middleware/LanguageRedirectMiddleware.php line 34

2. PHP Warning: Attempt to read property "user" on null in /html/typo3/typo3conf/ext/locate/Classes/Middleware/PageUnavailableMiddleware.php line 39

Court.php assumes there is another array-hierarchy in the configuration of a judge. It might be that a custom judge knows everything needed without further configuration. Then the additional configuration is null instead of an array (in Court.php).