-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FIX Unpublising parent pages should include child pages #89
FIX Unpublising parent pages should include child pages #89
Conversation
9c67c32
to
737945e
Compare
foreach ($page->AllChildren() as $record) { | ||
$document = DataObjectDocument::create($record); | ||
$docs[$document->getIdentifier()] = $document; | ||
$docs = array_merge($docs, $document->getDependentDocuments()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can calling getDependentDocuments()
here ever result in an infinite loop?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If my theory is correct, then the CMS will prevent us from this happening especially on a SiteTree
which I used as a guide.
https://github.com/silverstripe/silverstripe-cms/blob/668744e728154818873bc24cb0b8d45f73728b95/code/Model/SiteTree.php#L1752
The delete method on each child page executes on before delete as well which is kind of the same thing which is to recursively call the delete function.
My initial change was to account only the immediate children (SiteTree
) of a certain page but @michalkleiner made a valid point to account other relationships on each child pages hence made the changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Am thinking of asking other vendors to stress test this implementation since this issue came from them since they have more content.
Issue [silverstripe#88](silverstripe#88) Uses `SiteTree::enforce_strict_hierarchy` config in getting the dependent documents for indexing child pages.
737945e
to
188f6bd
Compare
I don't have enough context into this module (let alone a way to test it) to feel comfortable approving it, I was only looking at it 'cause Max asked me to. But from what I can tell, it looks okay. |
If you are keen, we can have a catch-up to set-up Elastic Search on your local. |
45775e0
to
0f9e26c
Compare
0f9e26c
to
4109616
Compare
@blueo Ready for another look. Added a few more tests cases and comments where I find interesting to know and for future reference. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested this locally - it works as expected. All descendents of the page being unpublished (and that page itself) are removed from the index.
No pages which should not be removed are removed.
I'll leave it to bernie to merge (or to comment if he has any requested changes)
P.S. loving your DDEV addon, Marco. It makes testing this so easy
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
great changes - particularly the test coverage. I have a couple of questions around where the sitetree logic should go and the way we're getting 'removed' objects
|
||
// Taking into account that this queued job has a reference of existing child pages | ||
// We need to make sure that we are able to send these pages to ElasticSearch etc. for removal | ||
$oldRecord = $doc->getDataObject(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
__unserialise does this a bit differently by getting the 'latest' version - do we want to do that to be consistent? I"m assuming this is about getting documents that have been removed (ie were not picked up by the previous condition because of stage=Live)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have tested your __unserialize
PR on top of this and your fix works as expected. As discussed, this job only checks for relationships between dataobjects and not their contents. Sending the live data is what the other PR has resolved a seemingly module wide issue which this PR also needs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good to know they work together - I was thinking though - should these two code blocks work the same way?
- From this Job
$oldRecord = $doc->getDataObject();
if ($oldRecord->isArchived() || $oldRecord->isOnDraft()) {
$document = DataObjectDocument::create($oldRecord);
$carry[$document->getIdentifier()] = $document;
}
- from the unserialise function
if (!$dataObject && DataObject::has_extension($data['className'], Versioned::class) && $data['fallback']) {
// get the latest version - usually this is an object that has been deleted
$dataObject = Versioned::get_latest_version(
$data['className'],
$data['id']
);
}
eg your one does a check for isArchived + isOnDraft if there is no DataObject - where the unserialize does a Versioned::get_latest_version call. OR does it not matter and we get the same result in the end anyway?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as discussed - the __unserialize function will look after returning a draft/deleted version of the dataobject - so we don't need this check $oldRecord->isArchived() || $oldRecord->isOnDraft()
- we can simply add the current dataobject - the job will then look after either indexing or removing it from the index
@@ -16,7 +17,7 @@ | |||
class RemoveDataObjectJobTest extends SearchServiceTest | |||
{ | |||
|
|||
protected static $fixture_file = '../fixtures.yml'; // phpcs:ignore | |||
protected static $fixture_file = '../fixtures.yml'; // @phpcs:ignore |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK you shouldn't need the @
- ideally just ignore a specific error
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was torn in between following commenting out a specific error since it makes the line of code looks rather long and unpleasant to the eyes. I just felt that this error is not really an error for a Silverstripe developer and should be an acceptable convention rather than following 3rd-party conventions that does not care about Silverstripe.
@@ -76,11 +97,25 @@ public function testJob(): void | |||
|
|||
$resultTitles = []; | |||
|
|||
// This determines whether the document should be added or removed from from the index |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
great additions
Co-authored-by: Bernard Hamlin <[email protected]>
00384eb
to
de17f14
Compare
… indexing the document
Extract to extension for SiteTree related documents
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work @ssmarco . I think this is ready to go now.
Issue #88
Uses
SiteTree::enforce_strict_hierarchy
config in getting the dependent documents for indexing child pages.