Defining the Core

Last updated by Joss Comments (7)

Elgg, like many other current web applications, relies on a core or engine which defines a structure upon which smaller applications (plugins) can be developed. Reading posts on the Elgg site from those more at home with the development of Elgg you can see the separation of the core from the functionality that the plugins supply.

Much to my surprise when installing Elgg, that separation was very unclear. Plugins that effect core functionality such as roles sit side by side with plugins that are intended as standalone apps such as forums or forms. As an administrator it is useful be able to have the admin broken up into four areas:
An area of the site that deals with all the core functions such as roles, permissions, registration systems, accessibility, access, database, maintenance and so on An area that deals with presentation issues such as templating An area that deals with the additional applications An area that deals with user and moderation. Separating these areas allows for an instant and clear understanding of how the entire system works and is managed and also allows for a separation of roles to manage the separate areas - one administrator that is tasked with approving users and sitewide/networkwide moderating  of content may not be the person who should have access to the core settings of the site.

I have been a little confused and frustrated that for some application settings I go to a link on the left admin menu, while for a core setting, I may have to scroll down through a list of plugins - and vice versa.

A careful redesign of the administration area, allowing for more complex roles, would be a major benefit not only to users but to developers who would be able to see more clearly how a proposed function may fit into the application hierarchy.

  • Separating plugins based on type of functionality:

    Elgg 1.8 is introducing some division of plugins (advanced versus simple). The idea being that the plugins that more commonly need to be adjusted go on the simple plugin page and the others go to the advanced page. The interface for this still needs some work and this only just touches on what you are talking about here.

    Here is a link to a plugin manifest file:

    An additional field could be added for plugin type ('application' like blog, pages, photo gallery, 'administrative' like user validation, 'customization') and this field could be used to drive the organization of the plugins. There is the question of does Elgg define the categories (and if so, what should they be) or do we allow plugin authors to create new categories.

    Perhaps one of the best things that Elgg could do is develop a guide for plugin authors on how to add settings. The original developers of Elgg probably assumed the settings link on the plugin box was enough for plugins but we have seen many add their own pages using their own styles. This is all very confusing for new administrators of Elgg.

    Here is a screenshot of the new admin area for Elgg 1.8:  It is still a work in progress and now is a great time to get feedback about it.

  • Interesting point about categories - any division needs to be logical both visually and techinically.

    One of the main benefits of categorisation is that in the future a superadmin could limit who had access to which category in the administration back end.

    To pick up your point about allowing additional categories, I do not see why not, though I would think this would be for the site administrator rather than the plugin developer. So, on install, Elgg could define say three really obvious categories - core funtions (libraries and so on), Template/Layout (everything from a nice menu to a full blown theme) and User Tools (blogs, forums, and so on).

    The developer would choose one of these three during developent (and coincidently, they could be displayed like that on your plug in repository, maybe) then after install, the site super-admin can move them where he likes unless it is core functionality, perhaps so they dont do something really stupid.

    If we were to limit access to administration of a specific plugin by role (super admin only, or super admin and template admin, or whatever), would that need yet another field for the plugin, or would limitting access by category be enough?  I prefer limiting by category; if you have 50 plugins that can be a lot of permission setting! If you can drag and drop them into categories that you have set access permissions for, that is much easier.

    By the way, the new admin panel is beginning to look more logical. I should really download 1.8 - is it available somewhere yet?

  • There are nightly dumps of the development version here:

    This is not an alpha or beta version and is being actively developed so features may come and go and it may not be stable every day. I've found the menu system odd and we've been discussing building a better version.

  • Okay, had a quick look at the nightly branch.

    Initially, the layout of the admin site is much cleaner and looks more serious - and that is good.

    I also think the right menu will be useable - it is more a case of what is in it. I suspect that if the administration gets very much more detailed, then each major page might need a sub menu within its frame (visually speaking).  Or, maybe use a mixture of top menu bar and right menu. Currently, the menu may get a bit daunting.

    I am unsure at the real difference between Simple and advanced - the difference seems more one of layout than anything else, just a different way of doing things.  I think when it comes to enabling or disabling, you can combine the pages so that on the one page you can enable singularly with a small link/button, or bulk enable using checkboxes, or have a select all if you want to do the lot - similar to how Wordpress does it. That should be labelled "Plugin Management."

    I think settings should be removed from this page entirely - having to scroll down a long list of plugins to make a setting change is very cumbersom - joomla has a similar problem when you wade through pages of plugins just to change one thing.

    I think what you said about categories may well be the answer - and I notice the filter which helps and the plugin settings on the right.

    You could list the categories in the right menu under Plugins. That may be quicker still.

    I suppose a really clever approach would be some sort of prioritisation (this is a bit off the top of my head here). But if the system knew what was the most accessed plugin (from the setting point of view) in any given category, it could put that one at the top of the list. We would need a way to switch off that function for people who hated it, of course - it depends how you like thinking through lists which varies from person to person.

    I need to play more ...

  • I have added a new article detailing my evolving thoughts about the administration system and in particular the menu:

  • I dug around more in the plugins and see that some do have categorization like this one:

    I haven't been working on the plugin management side of things so I don't know how those categories are being used besides as a filter.

    One of the big challenges that you touched on a little is that you have two classes of users:

    • New admins/implementors that are unfamiliar with Elgg (and perhaps new web admin of sites altogether)
    • Power users who have admined sites that use Drupal, Joomla, Elgg, etc. before

    I believe the simple/advanced division is an attempt to help with that. A new admin would only work with the simple menus/pages so as to not be overwhelmed. One problem with that is plugin developers will want their plugins on the simple pages to get more exposure. A second is that if new admins want to enable a plugin, do they go to the simple page or the advanced page. 

    Because Elgg is so plugin driven, most sites have a lot of plugins (more than on a WordPress site for example). There has to be a way to divide them up. Simple/advanced is one option. Core/third party is another. Divisions by functionality/category is another.

    The first time you enable a plugin, it is convienent to have a link there to its settings. After that, I would want to use a different interface to get to its settings.

    Your priority idea sounds like what Microsoft does with their menus in Office 2003 where menu options do not appear if they are not being used. You would have to learn those preferences on an individual user by user basis. In the beginning it would be disconcerting to have the order of the menu change after each use. Over time it would converge.

    I think I would rather have a "favorites" menu area. Let me choose what menu items go there and have control over their order. That allows me to pick and choose across categories.

    I also saw your new "Administrative Menu" page. Hopefully I'll get time later today to comment on that.

  • I like the idea of plugin developers jockying for position on a plugin list! Bribery jumps to mind as a solution.

    Although Elgg does seem to have a lot of plugins, really that is only because you have decided to call more or less all functionality (blogs, themes, additional fields) a plugin. If you look at Joomla and combined all the components, plugins and modules, you would probably pass out trying to sort it all.

    So, I wouldn't worry about how many you have, but rather how to sort them.

    I think that the Administrative Menu page that I have written may address at least some of your thoughts.

    I am very interested in the difference between someone new to this type of product and someone who, like me, has been through a lot of them. I think it is a very strong point, but you miss a third group - which covers me better:

    • An admin that has used so many products that they can't find their way around because things are not where they are guessing they are (it is the old RTFM problem)

    On that principle, it seems the best solution is the simplest - just make the whole administration area idiot proof and logical.

    There was a joke back when I was a sound engineer that you could tell the newby engineers as they were the ones that spent hours creating their own presets on the latest echo unit. The old boys (me) just used the factory presets and got on with the job.

    That is actually what is behind my idea of Configuration Templates that you can use during install (See under Choose a Community Site on the page Artists Impression of a Future Elgg Installation) - It gets you going really fast whether you are a complete beginner or an old time hack.