Implemented in 4.3

store is accessible via the AdminCentral

Module store

For 4.3 the goal is to to provide at least a listing of existing modules integrated into AdminCentral, with links for manual download. It may just be an iframe that loads a page from magnolia-cms.com. We may want to pass information about the installation that acesses the module store, e.g. installed modules and version info. A nice/cheap addon could be a page that lists currently installed modules (this one generated directly by Magnolia).

This is an idea of how it could look:


The first page will be a simple listing of modules, a cleaned up version of the matrix on the wiki.
For each module we will display:

  • icon
  • name
  • description
  • author
  • update date
  • version
  • status (installed, not installed, upgradable)
  • license (probably it's enough to display this in the detail page?)

Clicking on a module will bring to a detail page:

Here we should have a screenshot, long description, licensing/price info, link to download and to original website.

What we could skip for this first release (note that everything can be upgraded "server side" in the following months, but we just have to have a good status to include the menu and launcher soon in 4.3):

  • user rating/commenting
  • categorization
  • sorting? (do we sort alphabetically?)
  • compatibiliy matrix/versions: since this will only we available for 4.3 we can just add only modules wich works with magnolia 4.3. Before the next release (if any, before 5.0) we will have to implement a compatibility matrix (see the atlassian plugin studio as an example)

The server-side part will obviously be implemented as a set of magnolia templates, for the first run the list of modules will have to be centrally managed, we could ask people who added their plugin to the wiki for details.

Questions:

  • do we lists only real *modules* or also other tools/libraries (for example the "Magnolia criteria query" lib)?
  • do we lists enterprise modules too, with a link to the "purchase enterprise" instead than a download? It could really be useful to make more clear what users can get by upgrading to enterprise

Menu and pages configuration

A new magnolia module "modulestore", adding a menu item "Module store" in the magnolia admin interface.
The module provides two freemarker pages:

  • all modules list: displays all available modules (loaded from a url set in module's configuration);
  • installed modules list: displays only modules installed in the current application.

All modules page

Selecting the "Module store" menu item shows the all modules page; the module list is requested to the remote server (magnolia-cms.com):

 Current application's data is posted as a json-encoded parameter:

All modules page layout

Clicking on a module shows a details page:

Installed modules page

Selecting the "Installed modules" sub-menu item shows the list of installed modules.

Module definitions are retrieved from the ModuleRegistry.

Available modules

The details on available modules are maintained server-side, in the form of editorial content:

The "module-list" page aggregates module informations, and handles requests made by "All modules" page of the "Module store" menu.

Each subpage stores details on a single module:

The "Module details" button opens the dialog:

  • No labels

13 Comments

  1. Magnolia International

    All module info maintained on the server could be deduced from the module itself (i.e module descriptor and/or pom). But we could maybe start with maintaining manually. I see advantages in being to fix/change some of that information after the fact (i.e after a release), but I also see that it might induce a lot of discrepancies.

    There's also something missing altogether here - dependencies. The module's data must say what it needs (so it can be grayed out or hidden if it's not installable on the target system), and ideally, you'll want some form of warning if you look at a module X that has a dependency on module Y, if you don't have Y (and you still want to display X in the store, otherwise noone will ever know about said module)

    Can the whole module store (menus, pages, etc) be a separate module rather than meshed into admincentral ?

    1. Boris Kraft

      You are right, we need dependency management and I also suggest to reuse descriptors if we can.

      Instead of greying out a module, we should instead download all dependencies (display the list when someone wants to download).

  2. Boris Kraft

    I'd like to see the modules defined in the data module (or its own workspace), not directly in the website tree if possible. Since the module descriptions are well-structured data, this seems the more logical place.

    Each module version should have its own entry with version specific info. For instance, one "module" could contain n versions, each with version specific download links, screenshots, description, price & license info. A module should also have the information for which version(s) of Magnolia it can be used. This way we can then easily display the correct entry matching the installed Magnolia.

    The status message of the Module Store could also display something like "you need to upgrade to Magnolia 4.3 to use this module" if the module in question is only available for a higher version than what is installed. This way we can show modules that are not available for the installed Magnolia version and hopefully inspire people to upgrade to a more recent version of Magnolia to get the benefit of newer/additional modules.

  3. Manuel Molaschi

    On the main screen it could be useful to have a filter for (all / installed / not installed / upgradable). In this scenario, the sub-view Installed modules has not sense anymore.

  4. Fabrizio Giustina

    well, dependencies and more could be great for the future, but for 4.3 I think we should keep it simple... till when there is no automatic downloading or similar it's not so useful (and it still misses non-module dependencies, so you anyway have to check instruction and download a zip...). The download link should point to a zip or to a page, just like for modules listed now on the wiki.

    We agreed that module store will only be available in 4.3 so for the moment we will not deal with other magnolia versions. Only 4.3 compatible module will be published.

    Reusing the module descriptor doesn't give much at the moment, it's too poor for reusing it directly. It only has name, description and version. We need author, a longer (formatted) description, license, icon, links, etc.

    1. Philipp Bärfuss

      I back this. Lets focus on what we have planed for 4.3 (editorial content only).

  5. Fabrizio Giustina

    > I'd like to see the modules defined in the data module (or its own workspace), not directly in the website tree if possible. Since the module descriptions are well-structured data, this seems the more logical place.

    at the moment it's 1 module -> 1 page and it could be useful having a page where you can add more content paragraphs. I can't see any advandage in using the data module now... maybe when we will start keeping references to module versions, with a compatbility matrix for each?

    1. Philipp Bärfuss

      Unless we already know where we are going to in the future, I think the page approach is alright. First the data can be moved to the data module easily, second one could want to have a bit more content soon (screenshot,...) where the page approach fits much better

      This is a temporary solution (maybe we will use the pom files, module descriptors, ...) and so we should not overdo it.

      In my opinion this will be a single independent instance (modules.magnolia-cms.com) which can be replaced by anything.

      1. Magnolia International

        Re-reading and re-thinking in terms of 4.3-focus, I completely agree with the above, and the fact that dependencies are not a concern for now. We just dumbly list modules we have, with a description and download link, which was what was originally intended.

        I also agree this should be running in a completely independent Magnolia instance. (and host - so we can move it around wherever we like without concerns about links)

        TBH, I originally thought we'd just have a static file on the server somewhere - which would also make future migrations a lot easier. (whatever URLs are used in 4.3-client will have to be maintained long after we have a "real" module downloader mechanism in Magnolia)

  6. Fabrizio Giustina

    the scheleton is done, we are currently working to graphic proposals, they will be attached here

  7. Boris Kraft

    I must have the module list on the Magnolia (www) site as well. This is one of the core points for me. So the content must be reusable, as the design on the Magnolia site needs to be independent of the design for the AdminCentral iFrame.

    1. Magnolia International

      The data shown in the mockups above is also what we need on docu (and currently maintain manually in an unstructured way).

      Wishful thinking and post-4.3 suggestions:
      Wouldn't it force us to update the modules' documentation (would be a good thing) if we maintained this data on the documentation instance? (if not everything can be deduced from module descriptors/pom)

      From there we could publish it to a minimal "store" instance, or even as a plain text file, using a custom activation mechanism, because I'm sure by then we'll finally have refactored the subcriber/Syndication API (wink)

  8. Boris Kraft

    why is the "installed modules" a separate page/menu entry? Given that we send that info to the server, we should probably stick to just one menu point (the main one) and provide tabs within the one page to switch between different information, including "installed modules".

    Down the road, the module store will have tabs or filter functions e.g. new modules, best rated, most downloaded, updates (for you), & installed modules. In the light of this, we should not add a second menu entry just for the installed modules. Doing so would imply we also add entries for all other filters which is not what we want.

    I therefore suggest to only use one main menu point (and send the installed mods when the main entry is clicked).