Check Elgg Version .php

@All - I have some PHP code syntax parser routines (built for some other pupose) which can be enhanced to scan a plugin's scripts to match against a given Elgg version for matching and can therefore determine which version the PlugIn will be supported in. I'll publish the modified code later when finished.

BustItElggVers.php - Just got done testing the first cut of the highest priority PHP language parser to detect Elgg version support for PlugIns.

Told it to scan Followers PlugIn for 1.8  start.php against 1.7.8 and he said 'noperz" - you're making 2 function calls that doan existing in 1.7.8, So "no go!"

If y'all interested I cud load this up to Server so can test other PlugIns for Elgg vers compat.

mm.. I ran Tom Rice's "everyone-friends.php"  on BustItEkggVers and it passed the v1.7.8 validation checking ! SO ? where is the incompatiblity ? I read thru the code inside - no version problems, but there was hardcoded db table reference "elggentity_relationships" rather than {$prefix}entity_relationships. I guess this means BustItEkggVers doing his job quite oki so far. Any takers ?

23 hours ago
Uploaded the Elgg version checker here.
Go ahead and check it out ;-) Watch for bugs or inconsistencies and report please. I coded this BETA in a real hurry;-oOxX


I wonder... how easily the logic of can be adatpted to actually do a dynamic conversion of older PlugIns and upgrade to v1.8. ? After all - the basic lexical anaylsis and the syntax recongnizer already works abt 98% ;-oO How about that ? automatic PlugIn upgrades from older versions to v1.8 ! I likes that idea...;-o

3 June 2011 @ 7:31am

@Dhrup: is there a way to test the complete code of a plugin, i.e. the whole directory structure of a plugin with all files? I've tried it with the code of a single php file and it seems to run okay. But it reports all the functions defined in other files of the plugin as missing. So it's a but hard to see what is a blocker for 1.8 compatibility.


  • @IIonly -

    Yes, the version checker code is still kinda "beta". I was aware of that problem you mention about missing it's own functions ;-)

    I do plan to expand the Checker to allow uploading of a whole PlugIn's files folder - and then scanning as well to fetch the new functions all those files. Then we can do a better, more accurate whole directory scan against Elgg version 1.6., 1.7.8, 1.8b1 and the new PlugIn's functions to determine version compatibility.

  • Thanks Dhrup. I'm looking forward to it.

  • http://YaeXGen.enSci.US/

    [ Yet Another Extensible Xref Generator

    ( is the current raw Elgg Vers Checker )

    I will be setting up all the Parser routines in here. There are other language types (IBM zOS stuff) handled there that can be ignored for Elgg usage. Only the TYPE:>ELG option is relevant for Elgg PlugIns -- unless you want play around with the MainFrame stuff ;-) JCL, PROCs, COBOL.. ;-P

    The code to upload PlugIn Zips and to scan those unzipped folders for Elgg versions Compats - I will be adding later soon.

  • - I've made some changes to the selection logic here. The upload of whole plugins and subsequent validation using that as well will be coded later as I get more spare time...

  • @Dhrup why don't you make this into a community plugin? Would be quite useful.

  • @Andras,

    "Community PlugIn" ? meaning what ? Are you asking that this oughtta be uploaded as a Std PlugIn ?

    I reckon that ideally - such logic should be incorporated into the Community PlugIn Utility itself - so that as PlugIns are uploaded - they can be "scanned" to auto-detect the Elgg API calls and the version can then be determined - no fooling around with people having to input what versions they believe their code will run with.

    So far I have seen 1.0E-2 level of interest from the Elgg Core Team in this Elgg PlugIn parser for version compatibilty. Actually.. it seems that my posty on this CheckElggVers.php seem to have been not even "noticed". Not even  a little "hey.. that might sound interesting..." from them ;-) "there's none so blind as those who will not see.." ('s+none+so+blind+as+those+who+will+not+see)

    Have you yourself tried out ? Any critique, comments, suggestions ?;-)

    And so and (my original low-level scanner, tokenizer, parser, compiler, code generator for zOS languages) are out there for anyone interested to check, test, play with, comment, report bugs, ask for features & power or to simply say "that's neat";)

    A small but very important point that many people miss out is "FeedBack".. Developers who have created so many PlugIns and released see such a pitifully low-level of comments and recommendations e.g. 1000's of downloads but <10 or so recommendations ? I'm surprised that PlugIns keep been churned out despite the high level oif apathy ! Developers code and publish PlugIns either for name/ fame, culliing $paid projects, P.R. and so on. While people continue to download and walk away, smany times without even a small "thank you" ;-P

    Apathy has a price tag that goes with the attitude... People gotta learn to stand up and be counted or else they become counted out. Apathy is a big problem but who cares ?? I mean like hey ;) I created 90KB of version tables and php code to scan PlugIns and auto-detectwhich Elgg version that will run with, but who cares ?? LOLZ ;-X

    deja-vu ?;-oX "lack of interest" ;-X viz - that super-duper PlugIns index from circa 2008 that existed on EnSci.US/elgg/ for so long and yet I saw very few hits on the access log.

    " That's interesting angle ;) I used to have my home-grown publically available index of all elgg plugins abt 1.5 yrs ago but took it down b/c of total lack of interest. that index was search-friendly, sortable by various cols, and had 1-click download button to your pc's defined folder if running on xampp "

    ELGG PLUGINS 2011 06 04 @17 45

      37 Private_River Removes the ALL tab from members river view. Admin still has ALL Friends & Mine tabs Steve Aquila 3 days ago 2 June 2011 @ 4:09am ⅀ DL   
    2 104 eComments (real-time Likes and Comments) Fully AJAX'ed replacement for Elgg comments ihayredinov 3 days ago 1 June 2011 @ 7:40pm ⅀ DL   
  • Made some code changes to

    Filtering out more and more non-essentials tokens

    Got the fetch in line function decls stored so these do not report as "not-found"

    Kinda partly coded

    • PlugIn Uploader
    • Oploader UID & PWD checking

    And the subsequent directory scanner to lift all the PlugIn's files to scan for Elgg Vers Check.

    Stay tuned and show some interest ;-)

    Which is the same as saying "use it or lose it..;-) "



  • @Drhup, yes feedback is very important, however IMO we rather need to encourage and educate community members about this, than sulking and pulling our plugins back. As Cash suggested, there should be some incetive that will encourage community members to leave feedbacks and  recommendations.

    The reason I didn't give you any feedback on BustItElggVers is that I haven't tried it yet, as simply I don't need that kind of functionality at the moment. Should the need arise, I will remember this tool and will of course give you feedback on how it works.

    As for this part: "So far I have seen 1.0E-2 level of interest from the Elgg Core Team in this Elgg PlugIn parser for version compatibilty." - you have a very easy solution. Go to github, fork the community_plugins plugin, incorporate your changes and issue a pull request. I'm sure you'll get proper feedback from the core team after that.

  • @Vazco|Mike: (FYI from that other post..)

    Some of the basic detect logic in there is now changing, since I grabbed a few more php built-in funcns to help. That first attempt was based on a xref table built of .e.g elgg.1.7.15's functions and 'deprecated.php' code listing - which gives a decent, almost 95% perfect basis to analyze. I has built my most of the xref tables  manually; then php's tokenizer would scan some new source code, parse out the relevant stuff and cross-check for a vers# compatibility.

    I have since then played with some of the (more powerful) php functions - reflection, and some open source real grammar parsers written in php itself to parse php syntax -- to see how far a real language parser's output can help detect/ change - with the (much simpler 'deprecated grammars' @) 'elgg' code (syntax &) styles as per changes.txt

    Major changes I plan to make in the logic are := (a) throw away my defunct manual elgg funcns xref list and auto-generate; (b) use (eg) lib\deprecated-1.8.php to build the deprected code table --

    Line: 8, Char: 13, ["0x00000288: elgg_deprecated_notice('ElggAccess::get_ignore_access() is deprecated by ElggAccess::getIgnoreAccess()', 1.8);"]
    Line: 47, Char: 13, ["0x00000DC9: elgg_deprecated_notice("register_action() was deprecated by elgg_register_action()", 1.8);"]

    These 2 areas basically gives 98% of the work basis needed ;-) the remainder is detecting quirky lower level details of deprected calling sequences/formats.

    I can email you the older analyzer php source, tho - it will be the revised logic that's gonna be far more interesting (less code!).


  • @Dhrup: FYI I'm not the same person as Mike, just the same company ;-)

    I'd gladly see your source code as a starting point. My address is: srokap at gmail
    I'd like to focus on automatic analysis of all community plugins and possibly creating some comatibility reports (in future automatic code upgrade/reorganizing). This way we could minimize amount of automatic work required to be done to bring back old plugins to life. As I mentioned elsewhere, I've successfully replaced lots of stuff with properly constructed RegExps, so plan mimimum would be to do such rewriting. We could think of recognition of more complex bad designs that happen often or at least signal possible problems.

    I'd like to make this system open source. My very early work will be put in, for now I just have all plugins crawled from community site and performed some very basic extraction to determine how many are actually plugins ;-) Around 1300 look good.