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

As a Developer I want HttpCache to handle RemoveTranslationSignal

    Details

    • Type: Story Story
    • Status: Closed
    • Priority: High High
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Caching
    • Labels:
      None

      Description

      EZP-27417 implemented removal of translation from all the Versions of a Content Object.

      HttpCache needs to support emitted RemoveTranslationSignal.

        Issue Links

          Activity

          Hide
          Andrzej Longosz added a comment -

          [~rui.silva@ez.no] I've reproduced your issues locally with your database dump and ezplatform.yml config you've posted above.

          I've just noticed that you're config has the entry:

          groups:
              site_group: [site, por]
          

          The default site_group config contains an entry

          languages: [eng-GB]

          which would make matching eng-GB also for the por SiteAccess (settings get inherited)

          When I changed config to

          groups:
              site_group: [site]
          

          I got 404 for /por/MyTestEn (using your database dump)

          I've missed completely that this line is different in setup I've tried to recreate.
          Note: mentioned earlier cache_pool_name setting seems to be default when not specified, so this shouldn't matter.

          Does this change solve this issue for you as well?

          Show
          Andrzej Longosz added a comment - [~rui.silva@ez.no] I've reproduced your issues locally with your database dump and ezplatform.yml config you've posted above. I've just noticed that you're config has the entry: groups: site_group: [site, por] The default site_group config contains an entry languages: [eng-GB] which would make matching eng-GB also for the por SiteAccess (settings get inherited) When I changed config to groups: site_group: [site] I got 404 for /por/MyTestEn (using your database dump) I've missed completely that this line is different in setup I've tried to recreate. Note: mentioned earlier cache_pool_name setting seems to be default when not specified, so this shouldn't matter. Does this change solve this issue for you as well?
          Hide
          Rui Silva (Inactive) added a comment -

          Andrzej Longosz, nope, changing that did not reflect any different results at all.
          Regardless, I don't quite understand what you mean with "settings get inherited" regarding the languages there, since I'm just assigning the siteaccess "por" to a group which per se does not itself have any language assigned (I commented that setting for the group), thus, I figured the individual siteaccess setting "languages" for one particular siteaccess only only would apply (which is por-PT).

          Show
          Rui Silva (Inactive) added a comment - Andrzej Longosz , nope, changing that did not reflect any different results at all. Regardless, I don't quite understand what you mean with "settings get inherited" regarding the languages there, since I'm just assigning the siteaccess "por" to a group which per se does not itself have any language assigned (I commented that setting for the group), thus, I figured the individual siteaccess setting "languages" for one particular siteaccess only only would apply (which is por-PT).
          Hide
          Andrzej Longosz added a comment -

          I don't quite understand what you mean with "settings get inherited" regarding the languages there, since I'm just assigning the siteaccess "por" to a group which per se does not itself have any language assigned (I commented that setting for the group), thus, I figured the individual siteaccess setting "languages" for one particular siteaccess only only would apply (which is por-PT).

          Ah, yes, I see that in posted config you've commented out site_group.languages. This is also correct setup.

          Hmm, I'm running out of ideas of why I can't reproduce this.
          I've just successfully tested this on Apache 2.4 and PHP 7.1.8 (via php7.1-fpm) with SYMFONY_ENV=prod and SYMFONY_DEBUG=false and immediately after executing attached testSystem:ezp27417:deleteTranslations command I got 404 for /por/MyTestEn.

          I tested this on both Content Types: Folder (disabling always available before creating content) and Article (which has always available disabled by default).

          Note:

          6. I created an article "MyTestEn" on eng-GB language then translated it to por-PT, keeping the same name;

          The DB dump you've sent me contains Folder of that name, not an Article, however Folder also has alwaysAvailable disabled there (which is not a default setup). The question is when did you disable it - before or after creating content?

          Show
          Andrzej Longosz added a comment - I don't quite understand what you mean with "settings get inherited" regarding the languages there, since I'm just assigning the siteaccess "por" to a group which per se does not itself have any language assigned (I commented that setting for the group), thus, I figured the individual siteaccess setting "languages" for one particular siteaccess only only would apply (which is por-PT). Ah, yes, I see that in posted config you've commented out site_group.languages . This is also correct setup. Hmm, I'm running out of ideas of why I can't reproduce this. I've just successfully tested this on Apache 2.4 and PHP 7.1.8 (via php7.1-fpm) with SYMFONY_ENV=prod and SYMFONY_DEBUG=false and immediately after executing attached testSystem:ezp27417:deleteTranslations command I got 404 for /por/MyTestEn . I tested this on both Content Types: Folder (disabling always available before creating content) and Article (which has always available disabled by default). Note: 6. I created an article "MyTestEn" on eng-GB language then translated it to por-PT, keeping the same name; The DB dump you've sent me contains Folder of that name, not an Article, however Folder also has alwaysAvailable disabled there (which is not a default setup). The question is when did you disable it - before or after creating content?
          Hide
          Rui Silva (Inactive) added a comment -

          Answering to your very last question: I might have sent you a database dump from a state of the database after having run my last test at that time, which was after you told me about the Article / Folder disparity and Always Available setting. However, nothing changed there, just used Folder instead of Article. And yes, I did change the setting for the Content Type before running the test itself included creation of respective Contents but after that test-run I've always tried again with Article thereon.
          I'm out of ideas for a while now about whatever might be different between our setups. Might some setting (regarding cache or not) on the Virtualhost configuration also affect this? I also re-generated by virtualhost recently so I'm pretty sure I do have the default virtualhost configuration for a master..

          Show
          Rui Silva (Inactive) added a comment - Answering to your very last question: I might have sent you a database dump from a state of the database after having run my last test at that time, which was after you told me about the Article / Folder disparity and Always Available setting. However, nothing changed there, just used Folder instead of Article. And yes, I did change the setting for the Content Type before running the test itself included creation of respective Contents but after that test-run I've always tried again with Article thereon. I'm out of ideas for a while now about whatever might be different between our setups. Might some setting (regarding cache or not) on the Virtualhost configuration also affect this? I also re-generated by virtualhost recently so I'm pretty sure I do have the default virtualhost configuration for a master..
          Hide
          Rui Silva (Inactive) added a comment -

          Tested and approved by QA for master.

          Show
          Rui Silva (Inactive) added a comment - Tested and approved by QA for master.

            People

            • Assignee:
              Unassigned
              Reporter:
              Andrzej Longosz
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 2 days, 4 hours
                2d 4h