' interesting idea' ? i did some preliminary work in this area - http://community.elgg.org/discussion/view/729475/check-elgg-version-php - based off some pther laguange parsering rouies io had developed elsewhere. basically trying to detect language constructs for the the elgg api in particilar - to detect 'out-dated' elgg php code. 

@Dhrup: I remember this posting quite well. I even thought of mentioning it in my earlier posting. Have you made progress regarding the possibility to scan a whole plugin folder as opposed to a single file only?

scanning whole folders was never a problem - just a matter of spending spare time on the code; the real difficulty is maintaining a 'grammar' for the elgg API and functions.. ould have been nice to get some real techie help in this area, but apart from some snyde remarks about my not making the code gpl'eg, open source and available for everyone to test, play with - i never got any real offers from real Devs to actually *help code,  apart from not even knowing who might understand grammars and parsing ;-)

In theory, the developers would have been able to upgrade their plugins while Elgg 1.8 was in beta testing phase to release them just in time with the final release of Elgg 1.8. Obviously, this did not happen.

This was not due to the core devs by any means.  There were numerous previews/betas and release candidates before the official release of 1.8.

I tend to not update plugins based on betas because I assume things will change. Maybe if we switched to release candidates (where the API would be locked down), we might get more developers to update before the .0 release.

In response to Mike, the past tells me that plugin developers do not update their plugins until either something breaks or users start complaining about deprecation notices. Elgg 1.5 started spitting out deprecation notices to the log about action tokens and almost no plugins implemented them until Elgg 1.7 was released and required them. Wow, did people complain about that. We've learned to make the notices more annoying rather than having plugins break. The problem is that a lot of site admins don't understand the deprecation notices *only* display for admins but not for normal users. The current solution that will be in Elgg 1.8.7 is the following:

1. Things deprecated in the current version (in this case Elgg 1.8) will throw warnings that only display when the site is in debug mode.

2. Things deprecated in the previous version( Elgg 1.7) will throw the red system messages that only admins see.

This is a slighty toned version of what was in earlier versions of Elgg 1.8.

@Matt: That's exactly what I meant to say.

Cash, I think system you plan to implement will be very convenient for developers. Scanning for deprecated methods after enabling plugin and showing note to user is also a good idea. Developers would then be notified by plugin users that they need to update, while clients would not be so stressed that their website is broken.

In fact, in an ideal world we could register page handlers in a structure that could be scanned later and then, after plugin is enabled, we could test all pages by those pagehandlers and their parameters and do (limited) automatic tests for plugins, reporting all problems that appear on certain pages. We could have similar system for actions an their possible parameters. I guess this is a feature for the far future though :]

the problem was that -- site owners should not be bugged with those annoying messages. so - email out to code authors only & apache log for sites. other plugin conflict issues -- will need to look into some intelligent scannning - built like reflection but for elgg specific code, maybe some level of actual php code parsing where necessary to identify code areas - to aid fixing.and.. not quite 'far future..' the technology is available now to achieve this, as may be seen at my CheckEkggVers demo`s..

btw, iionly, you mentioned event_calendar is not updated to Elgg 1.8. Already 130 days ago we released completely rewritten version of event_calendar, compatible with Elgg 1.8, with all features that Kevin's plugin had back then. You can download it here (it's a free plugin). Please note that this version was not tested on Elgg 1.8.4 though, we can upload version tested on 1.8.4 (and with some new features) at Monday.

@ Cash "Scanning plugins for deprecated functions at upload is an interesting idea. l would also like to add that the seperate developer plugin could be created, example upgrade your plugins from 1.7 to 1.8 so that it will it will take as input the files of old plugins-check their views,startup.php,manifiext.xml and basic css structure changes such as the path defined for images and make it compatible with the existing version. It will reduce the development cycle and basic syntax errors and deprieciated functions will be less.The developer plugin can also give the alternatives for the depreciated functions.