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.

  • Hi Gabriel, where are your from?...

    I am from Argentina, and my experience as Elgg developer, led me to explore all the engine Elgg and separate in parts for a specific proyect.

    Noy I thik that for some features, modify original features is better than add plugins that replace already preloaded code, making use of more memory than my method...

    Right now I am in proccess of rewritting features like as riverdashboard, river_comments and like plugins, that in my investments, these are too complex and make an exesive use of recursive ob functions call (through elgg_view call function)

    I am working with Elgg 1.7.6. I tryed use Elgg 1.8b but I found more bugs, and some plugins does not work in 1.8 verison.

    Since of work with plugins in 1.7.6 I decided modify some features because at time of html and css modelling, I found that somethings are too complex... At end... why I not use 1.8?? right, I dont know, but I thik better know full engine to make a most performance site...!!! What you think about it???

    In the next post, we talk in spanish, pease!!

    Regards. Salomón.

  • Hola Salomón.

    Soy de México, bueno escribo en ingles para compartir mas y no se quede todo en español :D.

    mmm bueno, no estoy seguro, pero dependiendo que funciones de estas funciones que mencionas es si de verdad mejoras el rendimiento del sitio. Por ejemplo, si dices que la maquetacion del html y del css es muy compleja, bueno estamos hablando de las vistas, si tu haces un pugin y en el plugin creas la misma ruta de por ejemplo, los archivos css, elgg va a sobreescribir el fichero original por el tuyo, siempre y cuando tenga mayor prioridad, y el codigo original no va a ser leido, siendo mas explicitos:

    Supongamos que quiero modificar, como ya dije, los widgets. Entonces en nuestro plugin creamos una vista en la misma ruta que la original, en <mod/tuplugin/views/default/css/elements/modules.php> entonces le damos a nuestro plugin una prioridad > a 500 (esto es por default) entonces lo que hace elgg es, cuando vaya a cargar el css, elgg ya tiene en la variable $CONFIG la ruta de las vistas del css, y en nuestro caso va a cargar <views/default/css/elements/core.php>,<views/default/css/elements/reset.php>, ... y bueno todas las vistas originales excepto la vista <views/default/css/elements/modules> la cual la va a cargar de <mod/tuplugin/views/default/css/elements/modules.php> ignorando el archivo original. Y va a hacer lo mismo con cada vista sobreescrita en tu plugin, asi que lo unico que consigues modificando la vista original en vez de hacer un plugin, es ahorrar un poco de espacio en disco, pero elgg no leera dos veces el archivo. Y si a esto le añadimos que activamos en advanced settings en el admin backend, la funcion elgg view filepath cache, vamos a ahorrarle el paso a elgg de registrar las vistas, y ya van a estar guardadas en el cache.

    Tu punto seria entonces en modificar funciones que no sean vistas, que esten por ejemplo en las classes o en las librerias, ahi si ahorrariamos recursos de CPU y RAM en servidor, pero serian cosas muy puntuales.

    Espero haber sido claro :D. Un Saludo desde México.

    Angel G.

  • @Salomon Extending the view is encourage rather than editing core files.

    I find developing themes for 1.8 not hard, but I'm really not into 1.8

    I tested deyan shell, a great plugin, well written. Congrats for that and I thanks for sharing your case.

  • Ok gracias por tu comentario, si bien conozco eso, actualmente he analizado que por ejemplo el plugin river_comments desaprovecha la vista original del comentario común, que modificando esta se logra la misma funcionalidad con menos código. (Recordá que las vistas tienen código php también), Y también he observado que hay vistas que se escriben sólo para ir a otra y de esa a otra y de esa a otra. Eso hace que el script en la vista del river, demore mucho por la cantidad de llamadas recursivas a elgg_view...

    Queda claro que lo más fácil es instalar un plugin y configurarlo, pero bueno, se ve que me gusta meter mano en las cosas.

    Un saludo desde Argentina...

    --- English:

    Ok, thanks for your comment, I known about view render engine. Right now I analyzed the river_comments plugin, and it leave much of orignal view code for comments, that modifying it you may get same feature using low code. ( Remember that views contains php logic code also ). In adittional I saw that more views are created to call other, then it call other, in recursive mode. It make slowly perfomance to render river view, because recursive use of elgg_view calls.

    Right, is too easy install plugins and setup it. Is a good way when you havent time to develop!! But, I like make something myself....

    Regards from Argentina..

  • @rjcalifornia, I arent against plugin develop method, but I am careful for manny practices about this engines. In my case, I am using original comments view and enhacing it for make a fast render method for river view with all best features: likes, comments, and others that may be added.

    An concrete example, river_comments and like plunins, each one performs 7 queries to database to known if must extend determintated views! You can see it in river_comments_setup() and likes_setup() functions of respectives start.php files. I repalced it with an array wich views to extend, an later loop it and extend. It means that I have hardcoded a views list to extend. I think that it is a better way in terms of html rendering performance, what think you about?

    Since, I thinked again it, then I am modifying wrapper river item view instead. Then in these place I added the array an ask for item view if is in array and call extender views. Less code, make more and more efficient way...

    My target is an standar Elgg instalation with more native features, less additional plugins. I take this way, since longer experience reading code and implementing Elgg plugins. I can see that some plugins add unnecesary features, that may be used or not. In last case, y like remove unneesary code...

    Excuse me for my english, and thanks for your time to read It...


  • El "root /" es observando cuidadosamente todos los ingenieros de software Genuis sudo en Elgg;-P
    Una gran obra que veo pasando;-)

  • @Salomon In my experience, well, I had bad experiences while editing core files, that's why I recommend extending the views. It depends on the developer's preference.

    The work you are doing seems very interesting, would love to see it here in the community.

  • ok, but core engine I arent modified.  I agree with you leave original core files intact! I just editing some original views. I am against some developed plugins, that viewing the code I think: My server must execute all it! horror!!

    I wanna share my version when I have finshed it. May be useful for any purposes..

  • @DhrupDeScoop, please excuseme,. what are you talking about when you say "root /"? (linux ?)



Feedback and Planning

Feedback and Planning

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