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

Internal cache must be updated after restoration of trashed node

    XMLWordPrintable

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".

      Attachments

        Activity

          People

            Unassigned Unassigned
            eduardo.fernandes-obsolete@ez.no Eduardo Fernandes (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: