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

Internal cache must be updated after restoration of trashed node

    Details

      Description

      Please check EZP-25240 for full insight of the bug.

      Background

      We had content item A that relied on an object relation to content item B. The target of the relation (content item B) got put in the trash.
      When content item B got put in the trash, the display of the content item A crashed. This was expected because we needed to handle an exception in that case. However, we then followed these steps:

      1. Edit content item A to remove the relation. Display of content item A restored
      2. Restore content item B to original location. Display of content item A is still fine as expected.
      3. Edit content item A and add content item B to the object relation field. Display of content item A crashes again. This is not expected.
      4. Clear memcache: telnet localhost 11211; flush_all; quit. Display of content item A is restored.

      Controller test suggestion

      Here's a quick way to test: presuming your object relation field is called "single_relation", try to access the main location ID of content item B like this:

      $location = $repository->getLocationService()->loadLocation( $locationId );
      $content = $repository->getContentService()->loadContentByContentInfo( $location->getContentInfo() );
       
      $relatedContentId = $content->getFieldValue( 'single_relation' )->destinationContentId;
      $relatedContent = $repository->getContentService()->loadContent( $relatedContentId );
      var_dump( $relatedContent->contentInfo->mainLocationId );

      On a standalone install, the same test must be executed twice.

      The first time on your step 8, it was still showing null (even though the object relation was still there and there was a real location ID). On steps 9/10 it actually did update properly, although it's a problem that on step 8 it was still showing NULL.

      The second time on both step 8 and steps 9/10 it was showing the old, no longer valid location ID.

      Steps to reproduce

      All tests are against the observed result of this var_dump in the "Controller test suggestion":

      var_dump( $relatedContent->contentInfo->mainLocationId );

      1. Created new class with an "object relation" (singular) attribute;
      2. Created 2 Contents for the new class, "5239 Item A" and "5239 Item B";
      3. Edited "5239 Item A" and related it with "5239 Item B" using the existing "object relation" field;
      4. Visualized "5239 Item A" on an existing new stack frontend siteaccess, made sure related "5239 Item B" was displayed properly. var_dump shows, say, 147
      5. Deleted "5239 Item B" into trash. While this is operation is still happening, load item A repeatedly in your browser.
      6. Visualized "5239 Item A" on frontend. var_dump shows the old location ID. This is not expected. You would expect to see NULL.
      7. Restore "5239 Item B" from trash to its original location. Item A still shows the old location ID.
      8. Edited "5239 Item A" and removed the "5239 Item B" relation; Visualized Item A on the front-end. At this point Item A actually crashes since you've tried to load a non-existent object and node. This is expected.
      9. Edited "5239 Item A" again and re-established relation to "5239 Item B".
      1. 5239-1.0-1.ezpkg
        2 kB
        Nuno Oliveira
      2. RelationsVTwoCommand.php
        2 kB
        Nuno Oliveira

        Issue Links

          Activity

          Hide
          Tomasz Madeyski added a comment - - edited

          I tried to reproduce step number 7 from Nuno Oliveira description here. What I did is doing item removal and item restoration running admin panel in dev and in prod mode (node being removed and restored is object of relation - ItemB).

          • Running admin panel on dev mode / ItemB removal
              ItemB exists ItemB in trash
            ezpublish/console nuno:test:relationsvtwo 123 --env=dev int(124) NULL
            ezpublish/console nuno:test:relationsvtwo 123 --env=prod int(124) int(124)
          • Running admin panel on dev mode / ItemB restoration
              ItemB in trash ItemB exists
            ezpublish/console nuno:test:relationsvtwo 123 --env=dev NULL NULL
            ezpublish/console nuno:test:relationsvtwo 123 --env=prod NULL NULL
          • Running admin panel on prod mode / ItemB removal
              ItemB exists ItemB in trash
            ezpublish/console nuno:test:relationsvtwo 123 --env=dev int(124) int(124)
            ezpublish/console nuno:test:relationsvtwo 123 --env=prod int(124) NULL
          • Running admin panel on prod mode / ItemB restoration
              ItemB in trash ItemB exists
            ezpublish/console nuno:test:relationsvtwo 123 --env=dev NULL NULL
            ezpublish/console nuno:test:relationsvtwo 123 --env=prod NULL NULL

          So I believe what we have here is two separate issues:
          1. While removing item cache is cleared only for environment in which admin panel was run and removing operation was done. I'm not sure if we should consider this as a bug?
          2. While restoring item cache is not cleared in neither of environments

          Show
          Tomasz Madeyski added a comment - - edited I tried to reproduce step number 7 from Nuno Oliveira description here . What I did is doing item removal and item restoration running admin panel in dev and in prod mode (node being removed and restored is object of relation - ItemB ). Running admin panel on dev mode / ItemB removal   ItemB exists ItemB in trash ezpublish/console nuno:test:relationsvtwo 123 --env=dev int(124) NULL ezpublish/console nuno:test:relationsvtwo 123 --env=prod int(124) int(124) Running admin panel on dev mode / ItemB restoration   ItemB in trash ItemB exists ezpublish/console nuno:test:relationsvtwo 123 --env=dev NULL NULL ezpublish/console nuno:test:relationsvtwo 123 --env=prod NULL NULL Running admin panel on prod mode / ItemB removal   ItemB exists ItemB in trash ezpublish/console nuno:test:relationsvtwo 123 --env=dev int(124) int(124) ezpublish/console nuno:test:relationsvtwo 123 --env=prod int(124) NULL Running admin panel on prod mode / ItemB restoration   ItemB in trash ItemB exists ezpublish/console nuno:test:relationsvtwo 123 --env=dev NULL NULL ezpublish/console nuno:test:relationsvtwo 123 --env=prod NULL NULL So I believe what we have here is two separate issues: 1. While removing item cache is cleared only for environment in which admin panel was run and removing operation was done. I'm not sure if we should consider this as a bug? 2. While restoring item cache is not cleared in neither of environments
          Hide
          Tomasz Madeyski added a comment - - edited
          Show
          Tomasz Madeyski added a comment - - edited A PR with possible solution https://github.com/ezsystems/ezpublish-legacy/pull/1306
          Hide
          Bertrand Dunogier added a comment -

          Did we verify if this happens on eZ Platform as well ?

          Show
          Bertrand Dunogier added a comment - Did we verify if this happens on eZ Platform as well ?
          Hide
          André Rømcke added a comment - - edited

          > 1. While removing item cache is cleared only for environment in which admin panel was run and removing operation was done. I'm not sure if we should consider this as a bug?

          No, this is by design. What we could do is add more documentation on it, but afaik customer did not have this problem so unless they did it's a separate doc improvment where we can expand on how to reconfigure the cache to be placed in a common folder (hence shared).

          Show
          André Rømcke added a comment - - edited > 1. While removing item cache is cleared only for environment in which admin panel was run and removing operation was done. I'm not sure if we should consider this as a bug? No, this is by design. What we could do is add more documentation on it, but afaik customer did not have this problem so unless they did it's a separate doc improvment where we can expand on how to reconfigure the cache to be placed in a common folder (hence shared) .
          Hide
          Tomasz Madeyski added a comment -

          I tested it on 1.7 version and:

          1. While removing item cache is cleared only for environment in which admin panel was run and removing operation was done. I'm not sure if we should consider this as a bug?

          This one still occurs, but again, I'm not sure this is really a bug?

          2. While restoring item cache is not cleared in neither of environments

          Restoration works well when environments match (restoring in dev and running command to check relation in dev). So assuming that we don't consider issue related to env mismatch as a bug we are all good.

          Show
          Tomasz Madeyski added a comment - I tested it on 1.7 version and: 1. While removing item cache is cleared only for environment in which admin panel was run and removing operation was done. I'm not sure if we should consider this as a bug? This one still occurs, but again, I'm not sure this is really a bug? 2. While restoring item cache is not cleared in neither of environments Restoration works well when environments match (restoring in dev and running command to check relation in dev). So assuming that we don't consider issue related to env mismatch as a bug we are all good.
          Show
          André Rømcke added a comment - Merged: https://github.com/ezsystems/ezpublish-legacy/commit/cb9cfeb21d8e828e1daaa86637e4046ba04cefe9
          Hide
          Tomasz Madeyski added a comment -

          Rui Silva Eduardo Fernandes
          That's odd: I see that my changes are commited into Github already and you should have commit before fixReverseRelations https://github.com/ezsystems/ezpublish-legacy/blob/master/kernel/content/restore.php#L166

          If commit is after fixReverseRelations it will not work as this was the source of a bug.

          I'm not (yet) very familiar with updating 5.4 version but I guess it should be ok unless ezpublish-legacy-ee repository, 5.4 branch is updated and it is:
          https://github.com/ezsystems/ezpublish-legacy-ee/blob/5.4/kernel/content/restore.php#L166

          Any ideas why you don't get version from github?

          Show
          Tomasz Madeyski added a comment - Rui Silva Eduardo Fernandes That's odd: I see that my changes are commited into Github already and you should have commit before fixReverseRelations https://github.com/ezsystems/ezpublish-legacy/blob/master/kernel/content/restore.php#L166 If commit is after fixReverseRelations it will not work as this was the source of a bug. I'm not (yet) very familiar with updating 5.4 version but I guess it should be ok unless ezpublish-legacy-ee repository, 5.4 branch is updated and it is: https://github.com/ezsystems/ezpublish-legacy-ee/blob/5.4/kernel/content/restore.php#L166 Any ideas why you don't get version from github?
          Hide
          Rui Silva added a comment -

          Tomasz Madeyski, it is not odd at all, since even if you merge it, installing an updated 5.4 according to the (customer-consistent) procedures does not automatically get me the latest merges.
          Let me explain more thoroughly:
          Only when a new release for 5.4 is out, will the latest merges be included in it, by which one has to follow the updated update procedures from https://doc.ez.no/display/EZP/5.4.x+Update+Instructions
          in order to get the latest fixes.
          These update procedures are updated on the doc (which the customers follow) at the time of the release distribution.
          We at QA apply the patches manually, as customers do on their end, on an installation from the official tarball followed by the up-to-date update procedures.

          And, after doing so for this issue, I can say I get fine results, even though every now and then running the var_dump again still shows me outdated results, which a

          ezpublish/console cache:clear
          

          will solve.

          Show
          Rui Silva added a comment - Tomasz Madeyski , it is not odd at all, since even if you merge it, installing an updated 5.4 according to the (customer-consistent) procedures does not automatically get me the latest merges. Let me explain more thoroughly: Only when a new release for 5.4 is out, will the latest merges be included in it, by which one has to follow the updated update procedures from https://doc.ez.no/display/EZP/5.4.x+Update+Instructions in order to get the latest fixes. These update procedures are updated on the doc (which the customers follow) at the time of the release distribution. We at QA apply the patches manually, as customers do on their end, on an installation from the official tarball followed by the up-to-date update procedures. And, after doing so for this issue, I can say I get fine results, even though every now and then running the var_dump again still shows me outdated results, which a ezpublish/console cache:clear will solve.
          Hide
          Rui Silva added a comment -

          Tomasz Madeyski, only now I noticed that part of the testing of this requires testing the scenario twice and not once (as described on the jira description). By doing so, results are still not very clear to me. First time, everything happens fine: rRelated content displays on relator content when it's there and does not when it is not on relation: var_dump shows correct location id or null on the respective expected cases. I'm testing this only on prod.
          However running the same scenario a scond time in a row, removing the related object does not update to "No relation" on viewing the relator content on frontend siteaccess, neither does the var_dump show the new location id for related content after restoring it from trash (keeps showing NULL).
          However, after clearing caches manually, it shows all fine again. Is this to be expected or should the fix have corrected this behaviour as well?

          Show
          Rui Silva added a comment - Tomasz Madeyski , only now I noticed that part of the testing of this requires testing the scenario twice and not once (as described on the jira description). By doing so, results are still not very clear to me. First time, everything happens fine: rRelated content displays on relator content when it's there and does not when it is not on relation: var_dump shows correct location id or null on the respective expected cases. I'm testing this only on prod. However running the same scenario a scond time in a row, removing the related object does not update to "No relation" on viewing the relator content on frontend siteaccess, neither does the var_dump show the new location id for related content after restoring it from trash (keeps showing NULL). However, after clearing caches manually, it shows all fine again. Is this to be expected or should the fix have corrected this behaviour as well?

            People

            • Assignee:
              Unassigned
              Reporter:
              Eduardo Fernandes
            • Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated: