realurl generates page paths for non existing translations

[robinson2]

Environment: TYPO3 CMS 7.6.11 realurl 2.1.4 sys_language_mode = strict hidePagesIfNotTranslatedByDefault = 1

If a multilingual website with a HMENU of type "special=language" ...

lib.langswitch = HMENU
lib.langswitch{
    special = language
    special.value = 0,1,2
    1 = TMENU
    1 {
        NO.wrapItemAndSub = |
        #Don't show links to languages without existing translation
        USERDEF1 = 1
        USERDEF1.doNotShowLink = 1
        USERDEF1.doNotLinkIt = 1
    }
}

... is opened, realurl will create entries in tx_realurl_pathdata and tx_realurl_urldata for each language, even if there is no translation available.

F.e. L=0 : "Über uns" -> Page path = ueber-uns L=1 : "About us" -> Page path = about-us L=2 : [translation does not exist]

When /ueber-uns/ is opened in FE (L=1), realurl will create a page path "ueber-uns" for L=2, while rendering the special-language-HMENU, even if no L=2 translation exists.

If L=2 will be translated and named to "Qui sommes-nous" afterwards, the page path will still stay "ueber-uns", until it is deleted manually via "Speaking URLs"-Module.

A solution could be to force an update of the path after creation of the translation – like it is done after renaming a page.

[dmitryd]

What would you expect? It looks to me that your menu code still asks realurl to create a link. Realurl will obey any request from the TYPO3 core. If there is no translation, it will use the default language.

If you disable realurl, I am sure you will see your menu linked. This is why realurl gets executed. You should disable linking if you do not want to get a link from realurl.

Realurl is not able to distinguish between modes and it cannot refuse to create links.

[robinson2]

No,there are no links to the non existing language in the FE:

USERDEF1.doNotShowLink = 1
USERDEF1.doNotLinkIt = 1

But it may be that the links are processed by TYPO3, although they are not shown in the FE? Is that a TYPO3 Bug?

When you rename a page in the backend the URL will be updated automatically by realurl. Could realurl do the same when you create a translation?

[dmitryd]

But it may be that the links are processed by TYPO3, although they are not shown in the FE? Is that a TYPO3 Bug?

It seems so. Here is where the link is generated: https://github.com/TYPO3/TYPO3.CMS/blob/master/typo3/sysext/frontend/Classes/ContentObject/Menu/TextMenuContentObject.php#L88 And doNotShowLink is processed after the link is generated: https://github.com/TYPO3/TYPO3.CMS/blob/master/typo3/sysext/frontend/Classes/ContentObject/Menu/TextMenuContentObject.php#L133

When you rename a page in the backend the URL will be updated automatically by realurl. Could realurl do the same when you create a translation?

This should work already: https://github.com/dmitryd/typo3-realurl/blob/development/Classes/Hooks/DataHandler.php#L168

[robinson2]

It only works after renaming the translation, not on creation.

if ($status !== 'new' && ...

I have just tested it: 1. I created a new page "Impressum" (L=0) and visited it in the FE. Realurl creates a page path "impressum" for L=1 and a Speaking URL "impressum/" for L=2&id=36.

I created a translation "Legal" for L=1. Realurl does not updated the page path for L=1. It stays "impressum" (should be "legal").

I renamed L=1 from "Legal" to "Imprint". Realurl sets an expire-date for the old path (impressum) and creates a new one (imprint).

An expire date in step 2 would be an improvement, but it would be perfect if realurl would delete (better than update) all existing page paths on creation of the translation. Since the translation is new we can assume that exsiting page pathes for this language are faulty.

P.S. I have created a ticket on forge for the TYPO3 Issue: https://forge.typo3.org/issues/78512

[dmitryd]

it would be perfect if realurl would delete (better than update) all existing page paths on creation of the translation.

No, it wouldn't because this would break existing URLs in Google and I will get new tickets about it...

It only works after renaming the translation, not on creation.

Thanks.

[dmitryd]

I hope it is ok now.

[robinson2]

Thanks for your commit! I tried it but unfortunately it does not seem to work. I compared both versions careful and documented it (v1 = before and v2 = after implementing your commit). I'm sorry that I can not make any php suggestions, but i hope that this may help. I'm guessing that the problem is in step 2 and 3, see my notes below.

1. Created a new page "Impressum" (L=0) and visit it in the FE.

v1+v2:

urldata:
impressum/ L=0$id=36 – 2
impressum/ L=1$id=36 – 2
pathdata:
impressum – – Default 2
impressum – – English 2

2. Created a translation "Legal" (L=1)

v1:

(no changes)

v2:

urldata:
impressum/ L=0$id=36 – 2
impressum/ L=1$id=36 – 2
pathdata:
impressum – 31.11.2016-17:56 Default 2 --> (expiration date has been set)
impressum – 31.11.2016-17:56 English 2  --> (expiration date has been set)

Notes/Problems: Why did urldata L=1$id=36 not get an expiration date? Why did pathdata "Default" get an expiration date?

3. Visited the page (L=0 with language menu) in the FE

I would have expected that v2 generates a new urldata and pathdata entry for "legal", but nothing happened.

4. Renamed the translation (L=1) from "Legal" to imprint

v1:

urldata:
impressum/ L=0$id=36 – 2
impressum/ L=1$id=36 31.11.2016-17:35 2 --> (expiration date has been set)
pathdata:
impressum – – Default 2
impressum – 31.11.2016-17:35 English 2 --> (expiration date has been set)

v2:

urldata:
impressum/ L=0$id=36 – 2
impressum/ L=1$id=36 31.11.2016-18:01 2  --> (expiration date has been updated)
pathdata:
impressum – 31.11.2016 17:56 Default 2
impressum – 31.11.2016 17:56 English 2

5. Visited the page in the FE

v1:

urldata:
impressum/ L=0$id=36 – 2
impressum/ L=1$id=36 31.11.2016-17:35 2
imprint/ L=1$id=36 – 2 --> (this entry is new)
pathdata:
impressum – – Default 2
imprint – – English 2 --> (this entry is new)
impressum – 31.11.2016-17:35 English 2

v2:

urldata:
impressum/ L=0$id=36 – 2
impressum/ L=1$id=36 31.11.2016-18:01 2
imprint/ L=1$id=36 – 2 --> (this entry is new)
pathdata:
impressum – 31.11.2016 17:56 Default 2
imprint – – English 2  --> (this entry is new)
impressum – 31.11.2016 17:56 English 2

[dmitryd]

I would have expected that v2 generates a new urldata and pathdata entry for "legal", but nothing happened.

Realurl is not called when you visit cached pages. Clear TYPO3 page cache, TYPO3 will regenerate page content and links.

[robinson2]

Caching was deactivated and I have also visited the FE-page with a browser that is not logged in to backend. I just tried it again, to be sure, with your current development branch version.

The following two issues at step 2 (at creation of translation) are the cause for the failure:

• The old urldata entry for the affected language should get an expiration date.
• For pathdata only the affected language should get an expiration date, not all entries.

I have also tested to change the affected entries manually in the database after step 2:

• set an expiration date for the urldata entry of the affected language
• unset all expiration dates to 0 of all not affected language entries

After that realurl successfully created entries for "legal" in step 3.

[dmitryd]

Just found & fixed the place where tables were incorrectly updated.

[dmitryd]

Btw, your analysis is excellent. I wish everybody could do it so well.

[robinson2]

Thank you very much! Now the url is updated automatically after creation of a translation 👍 But when i look at the database-entries, I'm unsure if all issues are solved:

Now the entries change from ...

urldata:
impressum/ L=0$id=36 – 2
impressum/ L=1$id=36 – 2
pathdata:
impressum – – Default 2
impressum – – English 2

... to ...

urldata:
impressum/ L=0$id=36 02.12.2016-12:15 2
impressum/ L=1$id=36 02.12.2016-12:15 2
pathdata:
impressum – – Default 2
impressum – – English 2

... after creation of the L=1 translation (before visiting the FE). Maybe this could lead to unpredictable issues like unwanted redirects for L=0. Shouldn't this better be ...

urldata:
impressum/ L=0$id=36 – 2 <-- don't set expire date here, because L=0 is not affected
impressum/ L=1$id=36 02.12.2016-12:15 2
pathdata:
impressum – – Default 2
impressum – 02.12.2016-12:15 English 2 <-- set expire date, because this has changed

... ?

This is exactly what already happens on renaming of a translation (pages_language_overlay), and I guess that it should be the same on creation.

[robinson2]

I wrote a little bugfix for the core-issue that doNotShowLink or doNotLinkIt items are processed as links and thus force realurl to generate unnecessary entries: https://forge.typo3.org/issues/78512 But as I'm not a developer, I can't commit it (and would not even know how to do it properly).

[dmitryd]

This may help: https://docs.typo3.org/typo3cms/ContributionWorkflowGuide/

[robinson2]

Thanks for the link to the "Contribution Workflow" – I'll have a look at it. But I don't think that i should contribute something since I'm not good enough with PHP do not understand the dependencies when changing something. About closing this issue – isn't https://github.com/dmitryd/typo3-realurl/issues/313#issuecomment-257544756 still open?

[dmitryd]

The issue is not closed yet. I checked the code and I do not see how the default language can get expiration date. Possibly there is another ext that modifies page record when you modify translation. That may cause expiration.

[robinson2]

In my case only realurl is installed – no other non-sysext. It was marked as closed one hour ago. If it helps i could set up a blank TYPO3 test environment and send you the access data. Just let me know.

[dmitryd]

I think I know why this happens. TYPO3 modifies the page (last updated time) when a record on the page is modified. I will need to make some workarounds :(