Inject not yet installed macros in the WYSIWYG macro picker

Hi everyone,

I’m currently working on the idea to make easy for an admin to insert a macro which is not yet installed but available in one of the compatible available extensions right in the macro picker.

First, a disclaimer regarding an important limitation of this kind of macro: the only info we have about them if their ID and the extension which provide them. The reason is that everything else about the macro is dynamic, so we cannot access it unless we install the extension.

So here is a proposal (with the help of @mflorea) of how it could look like:

  1. The general idea is to list “extension macros” along with the regular ones (but at the end in my current proposal).


  1. All those macros would be part of the “Extensions” virtual category


  1. To avoid problems, I propose to list only macros from extensions which:
  • are compatible with the current context (compatible with current wiki or root namespace when on the main wiki)
  • the current user is allowed to install it in the current context (that means only admins will see them and only users with PR in the case of JAR extensions)

Since we don’t actually have the macro name and description, my proposal is to “emulate” them with information of the extension: the macro id plus the name and version of the extension to make clear this macro is special and the extension summary as description (which, sometime, might not have that much to do with the macro itself but hard to do much better).

When you select one of those macros you get an “Install” button instead of the usual “Select” one:


When you click install you get to the second step which install the extension and then show you the usual macro form. This second step is already designed to wait, so for a first version I was planning to not pollute the user with new UI for now and simply run the installation in non-interactive mode as part of the already existing wait, which would simply be a slightly longer wait most of the time. Of course, it could be a much longer wait if the extension has a huge number of dependencies, but I don’t think we have the case currently.

Here are some possible variations ideas:

  1. have two clearly separated lists instead of a single one containing the two kinds of macros ?
  2. use the extension category instead of grouping all those macros in the same “Extensions” category ? Some other name better expressing the subtleties of “macros located in not yet installed extensions” ?
  3. show all macros, but disable the install button when selecting one you are not allowed to install ?


Is there any way to actually display a dedicated icon to quickly spot those macros are not yet installed? Or maybe to add a horizontal line to split between the installed one and the others?

Another idea: it could be good IMO to have the “Installed macros” and “Not yet installed macros” along with the “All macros” categories.

Cool proposal :slight_smile:

I like the idea of having the installed process directly in the main UI, one way or another. I think it’s better for discoverability.

+1 as long as the user has an explanation for why the action is greyed out.

Ideally I’d make the installation a separate step in the UI, but I’m ok with having that in a second time.

Most macros (if not all), come from extensions so I’m not sure what the Extensions category means. I’d prefer to have Not Installed category instead.

It would also be nice when displaying the macros to show some indicator that the macro is not installed. One idea would be to display the categories next to the macro name, in a rounded box (can’t recall the official name for this ;)).

I wouldn’t display the version as I don’t see what it brings. Or if you think it’s needed, then display it but in small and not as part of the macro name, possibly using the same L&F as for displaying the categories (see above).

I think the Not Installed category could be enough.

Yes, I think it would be a good idea to list all macros but when you don’t have the permission to install them, to display some message explaining it and to tell the user to contact an administrator or someone with the permission required to install them.

I guess, for XAR macros, we could extract and index more information like the macro name, description and more. It’s more work for sure and might not be needed in the first version.

The rest sounds good, it’s nice that we’re making progress on this!

I prefer the solution suggested by @vmassol to show the category in a badge, after the macro name, of course, only when “All Macros” category is selected (otherwise if all macros are from the same category it’s redundant).

I don’t see the need for a “Installed macros” category. Having a category for not installed macros is enough IMO. I agree with @vmassol that naming the category “Not Installed” (rather than “Extensions”) is better. We could also show this category at the end in the drop down, after a separator, to emphasize that it’s different than the others.

The idea is not to show the Extension Manager UI but to perform a quick non-interactive install, using default settings. So no install plan, no merge conflicts, no logs, no questions. For this just a simple loading animation or progress bar on the macro parameters step is enough. If you want more control then you need to install through the Extension Manager UI.

+1. I would also place this category at the end of the drop down, separated from the rest, to emphasize that it’s different from the rest.

+1 for a category badge after the macro name, but I’d show this only when All Macros category is selected, otherwise the badge is redundant (if all shown macros are from the same, selected, category).

I guess Thomas wanted the administrator to see what version of that extension is going to be installed. Using a badge as for the category would emphasize it too much IMO. I would either remove it or keep it as is (in the extension name).

I would make the Install button disabled and show a tooltip on hover.


So what the UI would be showing if a decision needs to be taken by the user (e.g. in case of conflicts)? Just an error specifying that the macro cannot be installed?

Non-interactive mode just apply the proposed resolution (what you get when you just click Continue).

Thanks everyone for all the suggestions, here are some updates based on them:


Category renamed to “Not installed” and separated from the others.


I customized a bit the display of not installed macros:

  • no more automatic uppercasing, to make it more accurate (it’s the id here and not some display name)
  • special style for the extension (I’m actually not fully happy with it, but honestly don’t count on me to do much better, if someone have a complete css suggestion I can just copy/paste don’t hesitate :slight_smile: )
  • a new badge to emphasize the fact that this macro is not installed yet, I just used the badge class which looks nice, but I’m wondering if it would be better to use a different color

Regarding what happen after you click “Install”, I honestly think it does not worth it to complexify the UI with a new dedicated step and progress. As @mflorea indicated, it’s not like it was the only way to install an extension.

Of course, even if we only list compatibles and authorized extensions it’s still possible that something fail the installation in which case we still need to do something: so I plan to show an error “step” instead of the macro form.

Looks good to me.

It’s now pushed and will be part of XWiki 14.4.

I totally forgot to implement the suggestion to show all macros but disable those the current user is not allowed to install. I created [CKEDITOR-447] Show all compatible macros but disable those you are not allowed to install - JIRA for it.