My experience in theming elgg 1.8

Well, first, and before anything, sorry for my english, i don't speak english as a native language, my native language is spanish, but i'll do my best.

I'm here posting my experience in theming elgg 1.8, as Brett asked to me, because i developed a plugin called "Deyan Shell" (you can found it here in the community).

I started this shell as a theme for my web wich is running with elgg 1.7, but i noticed that a new major version of elgg are coming, and when the 1.8b1 was released, i decided to do my plugin for the next version, and idownloaded it.

The first thing i did, was testing the new version, and read every new function added to the engine, after that i started testing with my own plugin, because the best way to modifique an elgg site is trought plugins i think, and here was the first major change to elgg: creating a manifet file.

To create a manifest file i read another core plugin's manifest and copy-paste it. Then i modified the values, and also i tested the feature of dependencies, and versions, and i did another blank plugin that must need deyan shell to be activated, and the version numbers worked well, so if the plugin needs a deyan shell version > 1.1.0 and deyan shel version was 1.0.90, it will not be able to activate, no matter how many points. Also it works with the elgg version.

When manifest.xml was complete, i did the start.php file, and here nothing was changed (i think) from elgg 1.7, you must register your plugin's init function normaly and the control is yours! :D.

From here i tested a lot of new functions, one new feature that i think is one of the most important in theming is the new menu system. But i found a little big issue in menu's system thath conflicts my shell idea: i tried to include a complete module in topbar menu (dropdown login form) and i inserted the view of that module in the menu's text (where normally you put the icon/text) and the module works fine, in the topbar appeared the dropdown login form and i logged in normally without issues, but when i was logged in and then i clicked the messages page or friends page, elgg goes crazy, and redirected to the dashboard (or the main page). So after many experiments/test i decided to do my own topbar system, and here was born the panel idea :D. In the panel we got a couple of views: <panel/left> & <panel/right>. And then the functions to manipulating panel were developed too. So i did two modules containing a start menu and a user menu, and those are using the new elgg's menu system. But there is one thing important here: (im not sure if this was in elgg 1.7) there is a useful way to use views like input, output & forms. I will explain the forms & input view later, but for the panel i used an output view, wich is the output/url and also i used the function <elgg_view_module> to show a link and a module.

For themes, first i only change the core views of css <css/elements> wich, in the same way as elgg 1.7, contains the css classes, but now all the css were divided into smaller files, but also those files only handle a specific style, like modules, typography, menus, etc. Just reading a bit the file <views/default/css/elgg.php> you can have an idea of wich classes does those files handle. So if you want to modifique, I.E, the widgets, you must edit the file modules.php and there you can found the classes for widgets, wich are elgg-module-widgets * here i found a trouble, i want to change the icons for widgets, and after a bit research reading the widget's files, i found that the icons was handles by a function called: elgg_view_icon() and it only returns a <span> tag with css style, and those style was in <css/elements/icons.php> so the only thing i did was change the style of the icons and done!.

Well i am tired of writing :p may be tomorrow i'll continue this post, and if you have a cuestion please do it i'll answer it in my posibilities, even if it's about my shell or how to do a theme for it or a general cuestion.

Thank for reading, have a nice day! :D.

Angel G.

  • @salomon i'm with you, and i think that every developer was, if you say that if you modifique your elgg system to meet your specification, and trow away the innecesary code, will be better for your performance, but as you ask to core developers to include more features as a default, without making them a plugin, i'm not with you. Because someone else that are trying to do a network, webpage, social app, or whatever, will not need the same features as you, and i think that elgg does good in being more modulated by default, i mean, the elgg core will only bring to users (those who wants to install elgg) the base functions/features to meet everyone, or at least most of all, goals. So if they (the core team) put views that only has a function pointing to another view, it's because they want to standarize a view, so if another 3rd party developer want's to extend this view, it will be so easy to do, than rewrite all the view with the same code, or doing a similar view adding their changes. I don't know if i explained myself. I recommend that you should read the file "CODING.txt" that is in the root of elgg1.8. It's a good iniciative of how to forward the standars in elgg.

  • ok, I understand, what is the elgg pupose. Make a social modulable and scalable platform...

    You can see that Elgg1.8 have a native better river view. You can take it and add ajax functions to make most usable this feature. My case is similar.

    I can enumerate some features added with plugins that may be better if are added to native views:

    • TinyMCE (extends input/longtext) In my case i added an input/richtext, then I can use both views, and I found that it is better for some purposes. (I did this change for http://saloteca.saloweb.com.ar)
    • Profile Manager, replaces all view for profile and group profile. May be right, but I think better modify plugin profile to add specific fields. I understand that this plugin add other more features to site, I can evaluates that way is better....
    • Profile Manager and Event_Calendar. Both includes own different calendar views. Unacceptable for me..! I added an input/calendar view, instead added into plugin views.
    • more... I dont remember..

    My target is develop for especific purposes making high performance sites. I wish remove excesive recursion of view calls to better time response.

  • I will be very interested to read some of the code directions you all are taking with respect to views and other areas of Elgg that you're interacting with. I hear some interesting comments on what you are doing. I feel that even without the Core Team needing to cater for some specific areas. We can still build slightly customized code to support extra features within Elgg.

    Carlos (Morgar) did some experimental work here :=

    http://community.elgg.org/pg/forum/topic/391104/a-proposal-for-an-extensible-object-oriented-way-for-the-page-controllers/

    in the area oif innovating Elgg.

  • @Salomón Interesting approach. Could be interesting seeing that kind of elgg release somewhere =)

Feedback and Planning

Feedback and Planning

Discussions about the past, present, and future of Elgg and this community site.