NeXgeN PlugIns & Themes for Elgg

Last updated by DhrupDeScoop Comments (31)

Seen enough of Logo, topBar, Header Content, this widget, that widget, here, there and everywhere customizations and Plugins to assist obfuscate and obliterate the presence of the name of the underlying (appreciated?) platform we all use.

But what does 'theming' (branding) really mean for web-site owners ? I have some few handfulls of ideas re: the direction and places that 'theming' should travel towards. Not just mere changing of color, backgrunds, kiddie CSS stuff and the 'code-oriented' design aspects.

I want to arrange, re-arrange *anything, anywhere and anyhow -- any part of the UI and maybe even the UX to create my own *personalized (and also for all my clients' non-duplicate-able web-site "looks.."

I am looking to develop some sort of a superior "theme-roller" - for Elgg-based sites -- one where I can define the "looks" using some smart-like point/ click/ drag/ drop/ type a few specifications and then have the theming *utility *generate all the necessary code - HTML, CSS, JS, PHP including required Elgg API/Function Interface calls. It gets so tiresome coding the *same sort of thigs over-and-over again and again.. Views. Actions, yadda, yadda...

It is all the same design "pattern" for coding with Elgg. So why not a Theme, Styling, Views, Actions *code-generator* ? Possible ? Yes ! Someone I was recently discussing such several approaches blithely called it 'making a Developer 'redundant' ;-) True - a point/ click. drag/ drop smarty interface for developing Themes, PlugIns will make a lot of 'developer' code-tasks;' redundant..

I worked with something quite very similar - years ago on a different, specific application system to manage 000,000`s of lines of PHP, HTML, CSS, JS code -- auto-generated and guaranteed to work out-of-the box. It's time to start with Elgg's "weaver' utilities... ;-P A little, somewhat very much along the lines of 'write once & plugiuns/themes everywhere..!' And with simple *GUI-manageable code-less Roles, Permissions built-in !

What might be 'requirements' then - for such 'theming capabilites from any others ? Is CSS stuff code-changing sufficient ? Or do we propel, with Elgg, towards some nether stratospheres ? Y'all r welcome to say what the 'populace desires...' A "PlugIn" to generate them all...!

 

  • that sounds awesome, wish i knew enough about coding to help with a project like that, but alas.........but i would be willing to kick in a little to help fund it.............


  • ThX for the suggested offer... *if you wanna buy me beers - PM me lolz;)

    However - I plan to first start with a ECML (Elgg MarkUp Language, which has the facility built-in into the Core @now, however little-used)  -- style of auto-code generate.

    For this - I will dissect the Blog PlugIn - start.php, views, actions, pages, classes, everything area of code -- to create a 'template' as the beginning of a 'design pattern' for Elgg PlugIns [There will be other and different plugin 'patterns' emerging.. later]. The Blog -Style Pattern can then be formulated into all the unique snippets of 'Elgg' code that is needed for such a styled PlugIn. Next we coalesce all the patterns to be driven via pure 'declaritives' - simpler, english or pseudo-code type of 'language' - where we can define what we want the generated to code to do. SOme examples most likely can be seen with the ECML part/s of the Core. Hoewver my intent is to define for the code-generator sonething much simpler, so that non-programmers can also 'create' elgg`ed code.

    So - for example - my code defs could say :=>

    PluginName = MyNewBlogs
    MyViewsFields =
    1) MyBlogName, 40 chars
    2) MyBlogType = 1 char (1=Blue,2=Red,3=YEllow,4=Green)
    3) MyBlogDescr = 32K chars
    4) MyBlogCategory = <UserSystemCategories>
    5) MyBlogExtraCategories = (1=Rock,2=Country,3=Ballad,4=Folk,5=Calssical)
    6) MyBlogAccess = (0=Priv,1=LoggedIn,-2=Friends)
    7) MyBlogComments = YES
    8) MyBlogEmbed = YES
    9) MyBlogGallery = YES
    10) MyBlogAdmin = (
        SaveDrafts = YES
        AllowComments = YES
        Allow Images = YES
        CategorizeImagesIntoMyBlogGallery = YES
        )
    So using this list as the base -
    I now want the Auto-Coder to generate for me *all the Elgg
    code necessary to compose the PlugIn as a whole -
    -- views, actions, pages, classes, admin settings, everything!

    So the Auto-Coder then nees to go off and write all that (Standard Elgg Stuff)
    code for me and the end-result = a Brand New PlugIn that behaves like Blogs PlugIn,
    but different name, different data storage, every charateristic different ;-)

    And then - applying the same philosophy to the other different PlugIn patterns...
    We have... a no-developer, no-coding means for customizing Elgg any which way
    that we want to -- with no coding required! Of course ! - someone has to
    sit down and code all of that code-generator first...;-) And I kinda foolishly
    voted myself into that corner between the rock and the hard code-place.
    However.. past experience will be an able & willing ally.












  • The ongoing tales of NextGen Theming for Elgg:

    Elgg PlugIn Programming Language ;)

    Started looking more into how `PlugIn` should/might evolve to being written.
    And meanwhile, I happened to look back at something out of the hoary past 
    of programming - but still well and alive today and still performing program-code
    `miracles` in cartain areas  of comuputational application systems. 
    And that is Iverson`s APL - misnamed `A Programming Language` ;-O It should have 
    been called `THE Programming Language` ! It has been variously called 
    a `Beautiful Language` and `one of the greatest programming languages ever`.
     
    Let us take the typical Login Box (from Custom_Index), 
    where the code loooks like this in PHP :-
     
    <?php
    // Top box for login or welcome message
    if (elgg_is_logged_in()) {
        $top_box = "<h2>" . elgg_echo("welcome") . " ";
        $top_box .= elgg_get_logged_in_user_entity()->name;
        $top_box .= "</h2>";
    } else {
        $top_box = $vars['login'];
    }
    ?>
     
    Then we consider how, in our (presently imagined but planned)
    Elgg PlugIn Programming Language - this code should look like :-
     
    [?EPL
    [login_box]
    ?]
     
    And the block for featured groups in PHP :-
     
    <?php
    // groups
    if (elgg_is_active_plugin('groups')) {
        echo elgg_view_module('featured',  elgg_echo("custom:groups"), $vars['groups'],  $mod_params);
    }
    ?>
     
    And, then again - in EPL :-
     
    [?EPL
    [featured_groups x10]
    ?]
     
    Easy enough so far ??
     
    We all (at least us Devs) know exactly what PHP code, which 
    ELGG API calls, etc - are needed for building such pieces of 
    coding puzzles, and have most likely coded these a millions 
    times or more...!
     
    So.. => 
    We distill the code into something simpler
     
    NOT
     
    if (elgg_is_logged_in()) {
        $top_box = "<h2>" . elgg_echo("welcome") . " ";
        $top_box .= elgg_get_logged_in_user_entity()->name;
        $top_box .= "</h2>";
    } else {
        $top_box = $vars['login'];
    }
     
    BUT
     
    [login_box]
     
    and let's just be done with it ! Knowing that the darned generated code will just *work ;-P
    Such should life be and this is where we are headed...

  • Sounds like a lot of work... How can we help you there?

  • * reminder note for me * ==> embrache_emailthis

  • sounds like alot of work to get the code done so the rest of us dont have to code..........if you do get it going/done, the first round of beers is definately on me!

  • lots of work ? maybe so.. tho the aim is is to obliviate 'code-work' to create new(er)-plugins based on existing ones as pligin 'design patterns' l-) i've been looking up ECML (since Elgg.1.5 by Oliver Lillie) but the previous plugins have dispappeared - I think the core team idea/plan was to're-write' ECML for Elgg using some simpler programming - but, mind-ya - as @ 1.8 I do not see much | almost no core handling facilities for ECML processing (am I blind?) beyond cursory references to // ecml elgg_register_plugin_hook_handler('get_views', 'ecml', 'blog_ecml_views_hook'); -- but seems to be no more real processing provided.

    Anyway - think over what it will take behind the scenes to provide a code-generate means like "[login_box] " (imagine any other elgg widget stuff!)) to genn *all the code necessary ;-) f you gi thru other areas of code/ other plugins - there will be more 'patterns' found -- we need to just identify such blocks, develop the auto- code- gen logic and... 'he aqui!' - no moare php code writing to fix up new plugns and themes ! just code those [some`block`trigger`word] and you can create custom code for your clients as fast as the wind blows.. 'como viento sopla..' y no más competencia! because you can spit out Elgg code much much faster.

    I am studyng the Blog PlugIn to formalize it's' pattern for more 'blog-style' plugins - similar logical features, but differentm different plugins. I imagine that with the auto-gen tool/s in place - pone could spit out plugins using the same pattern as easy as several plugins in one day -oO and that is no joke.

    I already have the non-elgg version of this methodology powering my favourite client's (WIP to completion) eComerce site. So I know oretty much how this all works. Elgg-oriented auto-gen for plug-ins was a 1/2 after-thought.. Of course - do you really want all your prospestive clients to have this tool for themselves ? then - they not need your services lolz ;-P One shorter term alternative is to concentrate on only admin settings, views, actions, related actions - to allow the quickk ciding to supply plugins` mass-produced code... I hope you're getting the fuller picture here.

  • @dhrup If you need any help with this, let me know.

  • if y'all wanna 'help' learn up @ECML...;-oO

  • Guys... be serious... ! ;oO I've already written about several 000`s of words (almost a *picture) here to describe whatthis new tool is designed for and what it will do. anyone who wants to be 'involved..' -- just read-up above and try to follow the approches and techniques described . 'How can you help'? 'Let you know' ? I've already done that by merely posting. No need to ask how you`all can hekp ;-) Wanna 'help' propel this idea forward ? wanna see Elgg 'take over the world..'? ".. talk not, *do.." !

    I guess this (*no new at all!) approach will make the level of low-coding for (Elgg plugins) redundant and defunct -- simple = why code so much in php, css, mysql, htnl.. and all those other gobble-dee-gookz-hyroglyphics ? (Elgg) life was never not meant to be so convulated. Other terms to describe all this := 3GL.4GL.. (3rd, 4th generation languages). Such #GL concepts and *real implementations are nothing new. We already had 3GL, 4GL any GL in the mid-1970;s when I started in CompSci and.. Now @ 40 years onward., nothing has really changed much, except the level of power in programming languages and the *applications* of programming itself. the 'sliced bread' of CompSci was invented years ago.. Now - we merely try to improve quality of the slicing and the taste if that which is sliced.

    This 'ECML' style for creating (Elgg) PlugIns & Themes will make some cherished areas of (elgg) development redundant and defunct..;-)

    Wanna 'help' ? stop talking and start 'pushing'...

     

  • @dhrup, where is a good place to start reading/learning ecml, did a couple google searches and mostly come up with comments from elgg.  is there a wiki/docs or something to that effect?

  • *everything is a 'markup' language' ;-) htML, xML, ecML, fbML... sooo. even this new fangled HTML thang comes from SGML (@IBM [*my universe] - yep i worked w/SGML/GML/DCF @ long way bakk then cc 1960's) -- HTML is not such a 'modern' thingy after all ;-oO;X;P

     

  • Guess what I (re)found ? and it certaily does not ring any memory bells, tho makes me veryy curious-er -- ^*-;. StarGazers Elgg/ECML .;-*^  @  https://github.com/Elgg/ecml/stargazers LOLZ ???? Lawdy - what on earth was that.. ?

  • PS: y'all Elgg's 'ECML' is not too much like what I've been thinking of so far @here.. Elgg/ECML is mostly pretty much extension of power of 'Embed" PlugIn - to extrapolate on auto-genning static stuffs - not procedural code - which is the target here.

  • @Dhrup Could I work on some of the CSS. I am pretty good there.

  • Hello all.

    First off, I haven't used Elgg in years. Secondly I don't intend to offer any help other than below I'm afraid. I have far too much going on at the moment to be of any real assitance. I do NOT use this website nor get notifications of any messages sent to me in this community. I'm only here because Dhrup emailed me notifying me about this thread.

    I believe the original ECML plugin was taken down because it partially conflicted with functionality being offered in the core. I was contacted about 1.5 years ago by a member of the core dev team asking if they could included it, I said yes, however it seems it was too advanced in terms of what they wanted. Personaly I think it wasn't and "dumbing down" of ECML was a mistake.

    The main Elgg codebase behind the plugin no longer exists. However the PHP class that powered it is very much alive and I use it every day. It's called CustomTags and can be used in any PHP based website regardless of the content management system being used. And for those of you familar with Expression Engine templates it can be similarily used to offer advanced template customisations.

    The class allows embedding of custom html tags to pull in advanced functionality whilst keeping things simple for designers and junior devs. Each tag is configured by the supplied attributes. For example, a very simple demo for embedding a youtube video would look like this.

    <?php

    $current_dir = dirname(__FILE__).DIRECTORY_SEPARATOR;
    require_once dirname($current_dir).DIRECTORY_SEPARATOR.'customtags.php';

    $ct = new CustomTags(array(
    'parse_on_shutdown' => true,
    'tag_directory' => $current_dir.'tags'.DIRECTORY_SEPARATOR,
    'sniff_for_buried_tags' => true
    ));

    ?><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd"&gt;

    <html lang="en">
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
       <title>untitled</title>
       <meta name="generator" content="TextMate http://macromates.com/"&gt;
       <meta name="author" content="Oliver Lillie">
    </head>
    <body>

       <ct:youtube id="wfI0Z6YJhL0" />

    </body>
    </html>

    The callback php in the callbacl file would look like this

    function ct_youtube($tag)
    {
        return '<object id="'.$tag['attributes']->id.'" value="http://www.youtube.com/v/'.$tag['attributes']->id.'" /><param ......>';
    }

    The resulting output would be:

    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd"&gt;

    <html lang="en">
    <head>
       <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
       <title>untitled</title>
       <meta name="generator" content="TextMate http://macromates.com/"&gt;
       <meta name="author" content="Oliver Lillie">
    </head>
    <body>

       <object id="wfI0Z6YJhL0" value="http://www.youtube.com/v/wfI0Z6YJhL0" /><param ......>

    </body>
    </html>

    The class also supports inline replacement tags. For example:

    <ct:example some="attribute">
    This is an in line template. <br />
    This is a #{tag} that can be accessed by the callback function
    </ct:example>

    The interior content of the custom tag and the found replacement tokens are all passed along to the related callback function.

    There are a load of other examples in the download: http://buggedcom.co.uk/projects/CustomTags.zip

    Once again I do not intend to offer any help at the moment (from today 2012-08-22 to 2012-10-31), paid or otherwise as I have too much on. Dhrup, on the other hand if you need any feedback or pointers please feel free to email but I am not promising anything.

     

     

  • Oki..
    Deciding.. Deciding.... and
    Decided ! which area to code for using this `Incubator neXgeN Easy-Coder` utility,

    A very special - Custom Simple Profile Code-Generator, which will handle :-

    1    Totally automatic custom code management for easi(est)-of-use @lowest non-techie Admin levels
    2    Friendly GUI Admin Front-End to help Admins drive the Functionality and Features
    3    Site-Personalized Custom User Types
    4    User Roles (related @ EmbrachERoleZ PlugIn in tandem devel)
    5    User Perms (related @ EmbrachEPermZ PlugIn in tandem devel)
        but only certain portions from there will be required for here)
        [ I hope (and will try) to have all related PlugIns'
        code completed & readied for simultaneous releases ]
    6    Tabbed Profile Data
    7    (Tab)Grouped Access Permissions
    8    (maybe..) integrations with (existing plugins) external Federated login facilities
    9    Fully Admin control for Avatar/Image register/uploads and also *all other custom profile fields
    10    Handling for hugh basket of Data Types & input validations automatically managed
    11    (likely..) Event (including selected of Current Elgg 'Events') triggers for Profile data movements
    12    A *hardened *stingy meister scrooge grubbing ip-pinching cheapskate
        tightwad style for *controlled verifications for registrations
        (lessons learned from that golden old Fave SiteAccess!, and.. hookups with selected
        Spammer Tracker/ Control PlugIns & the added sugar of EmbrachE's home-grown additionals ;)


         Why doing all this freebie code development ?
        Simply because... it can be done !
        And.. Elgg-Life was meant to be much easier..;)
        
        Soy un desarrollador de código honesto
        De donde los vientos invernales más fríos soplan
        Y antes de morirme quiero
        Para compartir los versos GPL Elgg de mi alma.

        Cultivo código limpio puro
        En julio como en diciembre
        Para todos aquellos amigos sinceros Elgg
        ¿Quién me dará las manos honestas.

        Y para los más crueles
        que me arranca el corazón con que vivo
        Yo no cultivan ni ortigas cardos
        Cultivo código Elgg sencillo y directo

  • coming soon ;-oO =>
    embrache_nexgen_simple_permalink --
    enables your fave profiles as permalink;
    kinda similar to FB, Joomla, WP PermaLinks

    e.g.
    www.ElggSite.Com/SuperCoder
    - navigates to www.ElggSite.Com/profile/SomeUserId for some user who wants to be known externally as 'SuperCoder'

    www.ElggSite.Com/WiseWords
    - navigates to www.ElggSite.Com/blog/view/123456/YaddaYadda for some Blog that I want to be known externally as 'WiseWords'

    www.ElggSite.Com/Plumbing
    - navigates to www.ElggSite.Com/groups/profile/123456/PaddydPlumbing for some Group that Billiy wants to be known externally as 'Plumbing'

    An interesting twist would be :--
    Plumbing.ElggSite.Com
    - navigating as above, to the Group, Blogs, etc.




  • hi y'all:

    so i've been maybe 2 quiet on this NexGen PlugIns & Theming thangz ;( not rilley. just got tied up too much with every other job to keep the milk warm!

    and therefore - the first cute spot to target is = custom_index ! everyone's fave topic.. 'how do i do this, do that.. for my logged-out landing-page?' i've been coding the basic logic for creating a custom custom_index plugin - where you select your widgets and stuffs and the code spits out -> the whole plugin.

    other, non-standard widgets (3rd party plugins) will come in time...

    the 2nd step in this proof-of-concept --> to take care of registration form and login form blocks' customization and define whatever other content you may want to have in your site's register and your login pages. so - if you have your fave skunky jquery slideshow from css-tricks.com and you want that in your login/register page ? n/p NexGen PlguIn/Themer will let do that just that with a 'few clicks' ;-) isn't that just hilarious ? no coding ! but you get your customized index (landing) page anyways ;-oO including your own custom sliders ;" evil !!

    after that i may get to some type of register form fields customizations - extra fields, required fields.. the kinda tricks that now is only possible with some or other plugin that requires that you know what the heck 'metadata' means !;-( and what characters are legal or illegal for 'metadata names' !! like - do you rilley care to learn all that ?

    sooo.. stay tuned right @here folks. more later and... a chance to checkout the first cut of NexGen PlguIns and Theming.. coming soon to a site near near you.

    that's all for now.

     

  • Take a look at https://github.com/Elgg/ecml/pull/1 . ECML has fewer bugs and is more powerful (an ECML plugin can see/alter the entire token list, not just handle them one by one. Still there's the problem of view escaping/htmlawed filtering running before the ECML processing takes place.

  • I really want to see this, any ETA?

  • eta? one of these days.. when i stop coding ;) aiming for a design that facilitates not widgets, not 3-cols; but any-column layout canvas, 'blocks' which can be widgets or any other content you choose, lazy-loaded blocks so that every page loads f-a-s-t b/c only fetches what you see is all that it gets ;) 'custom-code' power helped via olver's style of ecml - the briefest, shortest, simplest 'quasi-code' to generate the real php/elgg/css/html - so maybe one little file of e.g. 50 lines of delcarations fpr customized-profile-register data generates the entire custom_index, profile, register forms and actions for you. not exactly tokking abt 'plugins', but a code generator that will generate the plugin for you as of a real develoepr coded it ;oO what more could elggsters want ? a plugin that codes for you ?! lolz;} that's why it is called 'nexgen', even though the technology is really q. quite old (for me it is!)

  • a veryy simplistic example plugin uploaded @
    http://community.elgg.org/plugins/1174374/01_8_12_2013_01_DD_%23B1/embrache-nexgen-userlinkx

    -- short, simple 'code' in the language file - used to generate the few lines ElggMenuItem() code - dynamically.. always controlled by the Admin; & works in any language;) if you can edit the language file;o}

    More...? to come laterrr.

  • This is nothing short of genius, would I be right in thinking that such a platform would also = faster page loading? I would love to help with this aswell, I am nowhere near as clever at coding as most of you guys but I do have several redundant live domains on my server. If I can help with testing or funding just let me know :)