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

Doc: Urlalias history removed for an existing translation when updating content

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Medium Medium
    • Resolution: Fixed
    • Affects Version/s: 4.4.0, 4.5.0, 4.6.0, 4.7.0, 5.0, 5.1, 5.2, 5.3
    • Fix Version/s: Customer request
    • Component/s: Documentation
    • Labels:
      None
    • Sprint:
      Castor Core S1, Castor Core S2, Castor Core S3

      Description

      When updating the object's alias for a content translation that already existed, the alias history no longer refers to that translation.
      This results in the history url not being available for any siteacces that does not use other languages.

      Steps to reproduce:
      1. For test purposes, make sure there is an 'eng' (default) and 'fre' language / siteaccess
      2. Verify the following [RegionalSettings] for the 'fre' siteaccess:

        ShowUntranslatedObjects=disabled
        SiteLanguageList[]
        SiteLanguageList[]=fre-FR
        

      3. Create an article 'Article1' in Eng,
      4. Add a new translation, 'Article1' in Fre
      5. Update the Fre translation to 'Article2'
      6. On the frontend, using the 'fre' siteaccess, verify that the old 'Article1' alias (history) is not reachable.
      Expected Result:

      The old url alias should be kept, referring to the new 'Fre' content translation
      (see https://doc.ez.no/eZ-Publish/Technical-manual/4.x/Features/Multi-language-support-for-URL-aliases , "URL history entries" )

      Other notes:

      In the ezurlalias_ml table, the language mask for the alias history is updated and the code for 'Fre' translation is removed.
      Before:

      +------------+-----+-----------+-------------+
      | action     | id  | lang_mask | text        |
      +------------+-----+-----------+-------------+
      | eznode:119 | 106 |         4 | Article1    |
      +------------+-----+-----------+-------------+
      

      After:

      +------------+-----+-----------+-------------+
      | action     | id  | lang_mask | text        |
      +------------+-----+-----------+-------------+
      | eznode:119 | 106 |         2 | Article1    |
      | eznode:119 | 106 |         4 | Article2    |
      +------------+-----+-----------+-------------+
      

        Issue Links

          Activity

          Hide
          Roland Benedetti added a comment -

          Hello,

          We are actually having this very problem on ez.no.
          I think it's a real bug and "avoiding the steps to reproduce" is not a great answer.
          We should think about fixing this in future version, may be in the new kernel? It seems clear though that it's not simple.

          In any case, a possible workaround is "use upfront external redirection, at the vhost level to override eZ Publish behavior".
          It is not ideal but at least will solve the 404 problem.

          Roland

          Show
          Roland Benedetti added a comment - Hello, We are actually having this very problem on ez.no. I think it's a real bug and "avoiding the steps to reproduce" is not a great answer. We should think about fixing this in future version, may be in the new kernel? It seems clear though that it's not simple. In any case, a possible workaround is "use upfront external redirection, at the vhost level to override eZ Publish behavior". It is not ideal but at least will solve the 404 problem. Roland
          Hide
          Roland Benedetti added a comment -

          Gunnstein, I totally agree. I was thinking beyond Legacy.
          It would not be smart to spend energy on this kind of issue in legacy.
          It is still very very rare situation.

          this said, we should mention in the documentation the last option as a work around > vhost upfront redirection even if it is very dirty!

          Show
          Roland Benedetti added a comment - Gunnstein, I totally agree. I was thinking beyond Legacy. It would not be smart to spend energy on this kind of issue in legacy. It is still very very rare situation. this said, we should mention in the documentation the last option as a work around > vhost upfront redirection even if it is very dirty!
          Hide
          Gunnstein Lye added a comment -

          Reopen for more doc.

          Show
          Gunnstein Lye added a comment - Reopen for more doc.
          Hide
          Gunnstein Lye added a comment -

          Doc team: Please add Roland's suggestion to the doc, as a workaround solution: Using external redirection at the vhost level, to override eZ Publish behaviour. For example, a rewrite rule in Apache.

          Show
          Gunnstein Lye added a comment - Doc team: Please add Roland's suggestion to the doc, as a workaround solution: Using external redirection at the vhost level, to override eZ Publish behaviour. For example, a rewrite rule in Apache.
          Hide
          Paulo Nunes (Inactive) added a comment -

          QA Approved

          Show
          Paulo Nunes (Inactive) added a comment - QA Approved

            People

            • Assignee:
              Unassigned
              Reporter:
              Joao Inacio (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 1 day, 4 hours Original Estimate - 1 day, 4 hours
                1d 4h
                Remaining:
                Time Spent - 1 day, 5 hours, 45 minutes Remaining Estimate - 1 day, 3 hours, 15 minutes
                1d 3h 15m
                Logged:
                Time Spent - 1 day, 5 hours, 45 minutes Remaining Estimate - 1 day, 3 hours, 15 minutes
                1d 5h 45m

                  Agile