There is 1 comment.
 
 
Prism.js Macro / cid:jira-generated-image-avatar-56e23b4e-f813-4106-92f0-924d825c9144 XPRISMJS-13 Open

Uninstalling Prism.js Code Macro Replacement doesn't restore the standard Code Macro until XWiki is restarted

 
View issue   ยท   Add comment
 

1 comment

 
cid:jira-generated-image-avatar-44deabc3-f262-4355-866d-550f654b967d Vincent Massol on 20/Oct/26 19:48
 

I've checked on a fresh XWiki 18.8.0 (prismjs-code 1.3 installed on the farm through the Extension Manager REST API), and XCOMMONS-85 is not what causes the behavior described here, although it's involved:

  • After the uninstall, prismjs-code is really uninstalled, but the root component manager still returns PrismCodeMacro (priority 500) for the code macro, loaded from the old extension class loader. So the Prism.js output after uninstall is real: the component is never unregistered.
  • The reason is XCOMMONS-3845: ComponentAnnotationLoader#unregister() ignores the priority declared in components.txt (500:), so the descriptor it asks to unregister (roleHintPriority 1000) isn't equals() to the registered one (500), and EmbeddableComponentManager#unregisterComponent(ComponentDescriptor) silently does nothing.
  • XCOMMONS-85 comes next: after removing the stale component by hand, code became an unknown macro, because the standard Code Macro was dropped from the root component manager when the Prism.js one was registered. So even with XCOMMONS-3845 fixed, uninstalling would break the code macro until a restart, instead of restoring the standard one.

So both issues are needed to fix this one, and restarting XWiki after uninstalling remains the workaround.