Ghost fragments

Bugs
1

Enonic version: 6.6.2-SNAPSHOT
OS: Mac

So in our mysterious fragment-switcher we have a fragment selector like this:

<input name="relatedContent" type="ContentSelector">
    <label>Related fragments</label>
    <occurrences minimum="1" maximum="0"/>
    <config>
        <relationship>system:reference</relationship>
        <allowType>portal:fragment</allowType>
    </config>
</input>

Which works fine, until a previously added fragment, stays lingering around after its deletion.

Basically I can see the content id using content viewer plugin.
But it does not show up in the list of related content in content studio.
If I try to rearrange the order of the fragments in the list of related content, the order sorta gets randomized and the ghost fragment is still there in content viewer.

Would a reindex fix this?
I guess I could edit the blob directly (since this is happening on my laptop) but thats not a good solution for our production cluster (if it where ever to happen there…).

2

I found the deleted id in 19 blob files, so nope editing all those feels very wrong.

3

This did not help:
./toolbox.sh reindex -a su:password -r cms-repo -b draft,master -i
./toolbox.sh reindex -a su:password -r system-repo -b master -i

4

Workaround for now, simply skip and log ghosts :slight_smile:

function getRelatedFragments(fragIds, fragmentSwitcherIds) {
    let fragments = [];
    fragIds.forEach(id => {
        const content = libXpContentGet({ key: id });
        if(content) {
            fragments.push(getFragmentContent(content, fragmentSwitcherIds));
        } else {
            log.error('Ghost fragment id:%s', id);
        }
    });
    return fragments;
}

The old code was much nicer though…

function getRelatedFragments(fragIds, fragmentSwitcherIds) {
    return fragIds.map(id => getFragmentContent(libXpContentGet({ key: id }), fragmentSwitcherIds));
}
5

That still does not solve the issue with ordering the content selector list.

I could reset the part, but since it has many input, that could take a while.

Perhaps resetting individual inputs would be a nice feature.

6

I tried exporting, removing the line I didn’t want:

<reference name="relatedContent">df075416-4864-4b3d-a610-de72cdc0b9ab</reference>

But when I try to import I get the following importErrors:
Could not import node in folder Node already exist
com.enonic.xp.node.NodeIdExistsException: Node already exist

I could not find any force flag in the doc:
http://xp.readthedocs.io/en/stable/reference/toolbox/import.html?highlight=force

7

This worked:

  1. A full dump
  2. Edit file in both draft and master
  3. Load the full dump
8 
function getRelatedFragments(fragIds, fragmentSwitcherIds) {
  fragIds
    .map(key => getFragmentContent(libXpContentGet({ key }), fragmentSwitcherIds))
    .filter(c => c);
}

will do the filtering a bit prettier :wink:

9

You will be happy to know we have polished the contentSelectors to handle “ghost” items better in 6.7 - so hopefully this will never be a problem again!

2 Likes
10

I have the same problem on my local machine

11

Sometimes we are unable to move, or delete parts. When we reset the part, we get an empty part with the same problem, It cannot be moved nor deleted.