Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-20469

Cannot have same custom URL alias for different content languages

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: High High
    • Resolution: Invalid
    • Affects Version/s: 4.7.0
    • Fix Version/s: Customer request
    • Component/s: Misc
    • Labels:
    • Environment:

      Database: MySQL 5.1.61
      OS: RHEL 63
      PHP: 5.3.3
      eZP: 4.4, 4.6

      Description

      It's currently not possible to create two custom URL alias with the same value, pointing to two different content languages, through the "Manage URL Alias" interface.

      Example scenario:

      • ContentA has two languages: Eng & Fre
      • User wishes to create individual URL aliases that will point to different languages of that object, and that are only available within that language, and none other.

      This will trigger an error message, since currently a duplicate URL alias (even if the language is not the same) is not accepted.

      Is this a deliberate limitation for URL aliases, or an issue that can be resolved?

        Issue Links

          Activity

          Hide
          Filipe Dobreira (Inactive) added a comment -

          To reproduce:

          1. Create an installation with two languages
          2. Create a content object in language A, and translate it to language B
          3. Use the "Manage URL Alias" view to create a URL alias (i.e: "/test") for the object's language A
          4. Attempt to create the same URL alias for language B, a message is displayed stating that you may not have two URL alias with the same value.
          5. Access "/test" through a siteaccess for language A, verify that you get redirected to the content object in language A
          6. Access "/test" through a siteaccess for language B, verify that you get redirected o the content object in language B (even though the URL alias was created for language A)

          Show
          Filipe Dobreira (Inactive) added a comment - To reproduce: 1. Create an installation with two languages 2. Create a content object in language A, and translate it to language B 3. Use the "Manage URL Alias" view to create a URL alias (i.e: "/test") for the object's language A 4. Attempt to create the same URL alias for language B, a message is displayed stating that you may not have two URL alias with the same value. 5. Access "/test" through a siteaccess for language A, verify that you get redirected to the content object in language A 6. Access "/test" through a siteaccess for language B, verify that you get redirected o the content object in language B (even though the URL alias was created for language A)
          Hide
          Patrick Allaert (Inactive) added a comment -

          Given:

          • a "fre" siteaccess showing content in French
          • an "eng" siteacces showing content in English
          • a content object available at /eng/company/contact (English) and /fre/companie/contact (French)

          the feature works this way:

          To create a redirection from /contact that works only in English-activated siteaccesses:

          • Go under Setup > URL translator.
          • Enter "contact" in "New URL alias".
          • Enter "/company/contact" in "Destination (path to existing functionality or resource)".
          • Select "English" in the Language box.
          • Ensure the "Include in other languages" is *NOT checked*.

          To create a redirection from /contact that works for all languages siteaccesses:

          • Go under Setup > URL translator.
          • Enter "contact" in "New URL alias".
          • Enter "/company/contact" in "Destination (path to existing functionality or resource)".
          • Ensure the "Include in other languages" *is checked*.

          Creating multiple times the same URL alias is not possible even with different languages. If a URL alias must exist in different languages under different siteaccesses, this is what the "Include in other languages" box is for.

          "Languages" is to be considered as a restriction filter. An alias is first fetched, then the related content is load and the language are compared, it they match or if the box has been selected, the content is displayed, otherwise a "module not found" error is generated.

          This behaviour can not be changed without introducing a serious BC break.

          Show
          Patrick Allaert (Inactive) added a comment - Given: a "fre" siteaccess showing content in French an "eng" siteacces showing content in English a content object available at /eng/company/contact (English) and /fre/companie/contact (French) the feature works this way: To create a redirection from /contact that works only in English-activated siteaccesses: Go under Setup > URL translator. Enter "contact" in "New URL alias". Enter "/company/contact" in "Destination (path to existing functionality or resource)". Select "English" in the Language box. Ensure the "Include in other languages" is * NOT checked *. To create a redirection from /contact that works for all languages siteaccesses: Go under Setup > URL translator. Enter "contact" in "New URL alias". Enter "/company/contact" in "Destination (path to existing functionality or resource)". Ensure the "Include in other languages" * is checked *. Creating multiple times the same URL alias is not possible even with different languages. If a URL alias must exist in different languages under different siteaccesses, this is what the "Include in other languages" box is for. "Languages" is to be considered as a restriction filter. An alias is first fetched, then the related content is load and the language are compared, it they match or if the box has been selected, the content is displayed, otherwise a "module not found" error is generated. This behaviour can not be changed without introducing a serious BC break.
          Hide
          Kaliop UK added a comment -

          Hi Patrick,

          Thank you for your response. We've reviewed the answer on https://jira.ez.no/browse/EZP-20469url. Although adding aliases via the URL translator seems to work for the given example where we have two languages, the solution is not generic enough. Let say we have three languages, then I can set up the same alias for either only one or all threee languages, but not for only two. In the real life issue we have four languages and the client wants to set up the same alias for only three. So the goal is to set up the same URL alias in more than one language, but not in all languages.

          Also, please have a look at the original issue that has been reported: http://project.issues.ez.no/IssueView.php?Id=10939url In the description field we've added a note: "We think that $linkID should be used at the end of the storePath method in kernel/classes/urlalaisml.php where it creates or updates the element." which hasn't been transferred to the EZP-20469 ticket. It seems there is an issue in that method. Let me add a bit more detail:

          The comment block above the storePath method says: "$linkID Numeric ID for link field, if it is set to false the entry will point to itself.", however it will always point to itself regardless the value. See lines 822-844 in version 4.4. The link attribute is set to null even if it is a new or an existing alias. This will eventually use $this->ID in the store() method later. We think $linkID should be passed instead of a null, therefore it won't try to create a new record for the new alias, but will update the existing one with the new language mask. What is your view on this?

          Furthermore, could you please give us more details what would be the serious BC break? We would like to understand why this functionality can not be fixed/changed.

          I would be grateful if can you re-open this issue in JIRA, as it is still un-resolved.

          Kind regards,
          Tamas

          Show
          Kaliop UK added a comment - Hi Patrick, Thank you for your response. We've reviewed the answer on https://jira.ez.no/browse/EZP-20469url . Although adding aliases via the URL translator seems to work for the given example where we have two languages, the solution is not generic enough. Let say we have three languages, then I can set up the same alias for either only one or all threee languages, but not for only two. In the real life issue we have four languages and the client wants to set up the same alias for only three. So the goal is to set up the same URL alias in more than one language, but not in all languages. Also, please have a look at the original issue that has been reported: http://project.issues.ez.no/IssueView.php?Id=10939url In the description field we've added a note: "We think that $linkID should be used at the end of the storePath method in kernel/classes/urlalaisml.php where it creates or updates the element." which hasn't been transferred to the EZP-20469 ticket. It seems there is an issue in that method. Let me add a bit more detail: The comment block above the storePath method says: "$linkID Numeric ID for link field, if it is set to false the entry will point to itself.", however it will always point to itself regardless the value. See lines 822-844 in version 4.4. The link attribute is set to null even if it is a new or an existing alias. This will eventually use $this->ID in the store() method later. We think $linkID should be passed instead of a null, therefore it won't try to create a new record for the new alias, but will update the existing one with the new language mask. What is your view on this? Furthermore, could you please give us more details what would be the serious BC break? We would like to understand why this functionality can not be fixed/changed. I would be grateful if can you re-open this issue in JIRA, as it is still un-resolved. Kind regards, Tamas

            People

            • Assignee:
              Unassigned
              Reporter:
              Filipe Dobreira (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Time Spent - 3 hours Remaining Estimate - 30 minutes
                30m
                Logged:
                Time Spent - 3 hours Remaining Estimate - 30 minutes
                3h