No redirect works with v4 (new and old, even after Upgrade wizard!) about my_redirects HOT 13 OPEN

Hi @foobar13372,

Thanks for you input. Is there any way for me to review your setup? I would love to see your instance to see why this is not working.

Kind regards,

ps. For reverting the upgrade script you can invoke the following command:

UPDATE tx_myredirects_domain_model_redirect SET pid = 0, root_page_domain = '';

from my_redirects.

I didn't do this on a live setup, but on a local clone. It's a system of a customer, so I sadly can't give out any details. The TYPO3 8 environment has around 300 domains, and a lot of redirects. 3.4 works perfectly fine, but 4.0 just does not work (silently fails as if it wasn't there at all), whether I do the upgrade script or not.

from my_redirects.

Does reverting query after the upgrade script fix your version 3.4?
Did found some bugs regarding rootpages with no domains. Will revalidate the workflow to be sure of it.

I haven't released this version on TER yet due to possible bugs. Thanks for your input!

from my_redirects.

Is it correct that your local clone domain is not available in the sys_domains?

from my_redirects.

I updated the pointer for tag 4.0.0. Can you please see if this fixes your problem for 4.0.0.

from my_redirects.

Thanks, I will test tomorow when I'm back at work.

My local clone domains are in sys_domain. My test system has all live domains in a scheme "actual.live.domain.localhost" (I get this by updating sys_domain, I simply append ".localhost" to all sys_domain.domainName). So, all uids and other domain configs stay exactly the same. This always worked for all relevant extension (even for ext:realurl where I build the configuration by an SQL select on sys_domain) - only for my_redirects v4 it suddenly stopped working.

Maybe the following was fixed already (I'll test tomorow), just wanted to note it:
I also noticed that the upgrade script did not upgrade all redirects properly - or that the select field in the edit mode of a redirect does not have all entries (no sure what of the two would be correct here). The select field in the backend module seems to have the correct value of "pages.uid-sys_domain.uid" for all redirects. So the upgrade script seems to work correctly as far as I can tell - also the page and domain are existing and working, I can visit them correctly in the frontend, but it still shows "value not allowed" for some of the redirects.
I'll test tomorow if it's still the case with the latest version.

from my_redirects.

Nope, redirects are still silently not working and many redirects have "value not allowed (pid-uid)" in the edit view in the domain drop down, even though I'm on the page where the domain sits in the page tree and am admin.

from my_redirects.

Hi @foobar13372,

The query of requesting all available domains is:

SELECT * FROM sys_domain WHERE redirectTo = "" ORDER BY sorting;

I think it's very strange for the value not allowed to display. That means that the page (pid) is deleted or that the domain record was already a domain redirect (redirectTo not empty).

Can you verify both cases?

Kind regards,

Benjamin

from my_redirects.

There's only one single domain that has redirectTo set (and for this domain no my_redirects redirect is configured).
There's not even a single domain where the pages.uid = sys_domain.pid does not exist and also not a single page that is deleted = 1 where a domain is listed.

from my_redirects.

What is the state on this? We experienced this non-functionality now also on a new/empty single-domain project that started with version 4. Had to revert to 3.4.

from my_redirects.

I don't have a status update. Due to issues with non-admin editors and rights privileges problems I need to create unit tests to make sure this will be tested and hopefully I can find your problem automatically with this.

However cause I can not recreate your problem, its almost impossible to fix your issue.

Sorry in advance.

from my_redirects.

When i delete the try-catch block in the function generateLink (Line 178) in my_redirects\Classes\Service\RedirectService.php the 404 redirect is gone and the redirectTo is working.

As soon as EidUtility::initializeTypoScriptFrontendController(ConfigurationUtility::getDefaultRootPageId($link)); is called in the try block, we are redirected to a 404 site on the calling domain.

Tested on a Windows XAMPP with PHP 7.2.

from my_redirects.

Hi,
If this is a problem, the rootpage ID is probably not configured correctly or retrieved.
Can you try and configure with the following 'fallback' and try again?;

$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['my_redirects'] = [
    // Define default root page
    'defaultRootPageId' => <<YOUR CORRECT ROOT PAGE ID>>,
];

The main problem is that the Core handler of error initialization can do an location header and die(). I don't like using register_shutdown_function due to possible conflicts.

Kind regards,

Benjamin Serfhos

from my_redirects.