"Sergey Chernyshev" <[email protected]> wrote in message
news:[email protected]...
>
> There is probably a solution that can be done within the code - something
> that makes all included PHP files override the version if it's later then
> in
> main file - something like this in main file:
>
[Code snipped]
This is basically what I do in my WikiDB extension [1]. There is a
WikiDB_RegisterRevision() function, and all files in the extension call this
function using WikiDB_RegisterRevision('$Rev: 114 $'), where the 114 will be
automatically substituted using svn:keyword expansion. Check the files [2]
to see it in situ.
[1] http://www.kennel17.co.uk/testwiki/WikiDB
[2] http://www.kennel17.co.uk/testwiki/WikiDB/Files
>
> Still, it's only a convention and not a universal solution, more over
> it'll
> only work if revision updated at least one PHP file. Also if extension
> doesn't include all it's files or uses AutoLoader, then it will not be
> reliable.
All true. In my case, I don't use auto-loading, all files are loaded on
startup and I do not have any non-PHP files, so it works for me. However
this is far from best practice and won't give terribly good performance on
busy wikis, I suspect.
Perhaps we should add a "GetCredits" hook, to be called on Special:Version
in order to get the credits info for the extension? If the hook is not
found, or returns false, then the info in $wgExtensionCredits for that
extension is used, otherwise the array returned from the function (which is
in th same format) will be used instead. This would mean that the extension
could use this function to include() all available files in order to get the
revision number, but wouldn't need to include them on normal pages (thus
avoiding the performance hit). Wouldn't solve the problem of non-PHP files
being updated, but would solve the rest.
- Mark Clements (HappyDog).
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
