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
          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?
          Hide
          Tomasz Madeyski added a comment -
          Show
          Tomasz Madeyski added a comment - A follow up PR: https://github.com/ezsystems/ezpublish-legacy/pull/1310
          Show
          André Rømcke added a comment - Merged: https://github.com/ezsystems/ezpublish-legacy/commit/6a56c8d002528fd38c8d4c68c17a2918b0e30864
          Hide
          Eduardo Fernandes added a comment -

          QA Tested and approved

          Show
          Eduardo Fernandes added a comment - QA Tested and approved

            People

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

              Dates

              • Created:
                Updated:
                Resolved: