New CKEditor Image Dialog

Development
#1

Hello all,

I am currently working on the design of a new CKEditor Image Dialog.

The main improvements of this rework of the CKEditor Image Dialog are:

  • Allowing users to select an image style, allowing images to have uniform styles across the wiki
  • Images selection:
    • images gallery when searching for images to ease the selection by previewing the images
    • images of the current document are presented at the top
    • images indexed using solr to make it possible to index the caption, OCR, and filenames of the images
  • Improved image upload: possibility to rename images on the fly

For me details please see the design page.

Architecture

The features of the Image Dialog depends on two new extensions:

  • the “Image Style Administration Application” : this extension allows admin to configure the available style, to map styles to CSS and to configure the settings that are allowed to be modified when the style is selected
  • the “Image Search Application”: provides the indexing and search endpoint for images

I propose to introduce two new modules inside XWiki Standard for them, respectively xwiki-platform-image-style below xwiki-platform-image and xwiki-platform-search-image below xwiki-platform-search.
Of course these two new modules will contains submodules for the ui, rest endpoints, etc.

Regarding the location of the new CKEditor plugin, I am less sure of the right location:
I see three options:

  • inside application-ckeditor-plugins
  • as a new contrib extension application-ckeditor-image-dialog
  • as a new XWiki Standard extension xwiki-platform-image-dialog

Transition strategy

I see two ways to transition to the new image dialog:

  • by directly replacing the existing image dialog
  • by offering a configuration option in the administration, allowing to choose between the “legacy” image dialog or the “new” one.

The second option add some complexity (for instance, maintaining an administration page that will disappear later) but could allow to propose the new image dialog before it covers at least the same features as the “legacy” one, allowing users to test it earlier.

WDYT?

#2

Note that since the file selection tabs (gallery, document tree, upload) will be injected modularily (using an UIXP) we can discussion the location of those sub-part too.

The identifier of the UIXP will depend on the location we choose for the plugin, but will need to be discussed too.

#3

You mean image selection I guess since this is not for all types of attachments, only images, right?

#4

For the future, yes.

#5

I guess we should also have this in the standard attachment upload to be consistent, if we implement it for the image dialog.

#6

Sounds good for xwiki-platform-image-style. For xwiki-platform-search-image, why do we need a module since we already have the ability to perform SOLR queries? Is it to offer a java typed API dedicated to image search? Is it to add a new specific REST endpoint for image search (rather than use the existing generic search endpoint)?

I’m hesitating with xwiki-platform-image-search (ie inside the image module). I think it would be more domain-oriented. What’s your idea for putting it inside the search module?

#7

That would be my preference to limit the amount of work but indeed it doesn’t allow to bundle the new dialog before it fully implements what existed before. Maybe just a config option in xwiki.properties (since that’s easy), that we would remove later once we remove the current image dialog?

#8

Indeed, the intent is to provide a High level Java API (+ Rest endpoints) to perform image specific search, possibly decoupled from the underlying solr implementation.
I’m fine with xwiki-platform-image-search and xwiki-platform-search-image, it depend if we want to emphasize on the search or on the image domain first.

@mflorea did you had a plan to modularize the search for your quick search proposal?

#9

+1