Hi, Excerpts from rezlemic's message of 2011-02-24 18:19:38 +0100: [...] > I would like to ask you if you can help me with that. I would be glad > if you have something for me (develop a feature, finding and solving > bugs, solving any other issue). There is our bugtracker at http://bugs.dokuwiki.org/, but from a short look I couldn't find anything really useful for you. You can still try to find something that sounds suited for you. > My work must have been dome till 21.4.2011, so I am limited by the > time. I may spend approximately 20-30 hours of net time on project. Do > you think you have somethink for me? I have to finish my project till > 21.4.2011 and show my work to my lector, it must be a finished, > complete "feature". After passing my subject I can help you in the > future too. That sounds great. Thank you for your interest in DokuWiki! There are two ideas that come into my mind: 1- We are currently preparing our application for the Google Summer of Code. The not yet finished list of ideas can be found at http://www.dokuwiki.org/devel:gsoc#ideas. However they are aimed at GSOC and thus more for 12 weeks than for 20-30 hours. Nevertheless there is one idea that is still in the list but imho too small for GSOC: http://www.dokuwiki.org/devel:ideas:remote_api. I might be wrong, but I think this would fit into 20-30 hours. Have a look at lib/exe/xmlrpc.php: There is very little in that dokuwiki_xmlrpc_server class that is specific to XML-RPC: it's basically just that one call to serve() and the error class. My idea would be: Remove the parent class, pass it to the constructor and save it as attribute, then change all calls that are specific for that API to that attribute. The code should then of course be moved to a different location (e.g. inc/api.php). The error handling might be a bit tricky, as plugins that add their own handlers don't know about the API implementation attribute. A good idea might be to use a generic error class that is then translated into a specific error by the API implementation. This error could also be thrown as exception. Unfortunately error handling is still a bit tied to HTML in DokuWiki so we don't have anything like standard error exception classes (yet). There have been some efforts by Adrian Lang recently to change that a bit e.g. in the media handling, have a look at https://github.com/splitbrain/dokuwiki/commit/87229c84afbda98679146558235bc7212ea404ee and https://github.com/splitbrain/dokuwiki/commit/ffb291f214dd47aa34d4e84b166de6e62714307f . You don't need to make that perfect, it's just to give you an idea how we handle errors in DokuWiki. Another problem is also that the HTTP headers don't reflect errors, see this http://bugs.dokuwiki.org/index.php?do=details&task_id=2133 bug report for details on this problem. If you could solve this, too, this would be great, but again not necessary. There might be a bit additional work to do, but basically this should be a project that is clearly defined, doesn't involve a lot of DokuWiki code and still gives you a good start into DokuWiki development. 2- There is a jQuery rewrite in progress. However Pierre Spring who started that rewrite currently hasn't the time for finishing it. You can find his work at https://github.com/caillou/dokuwiki-jQuery (look at the commits to get an impression what he has changed and what this rewrite is about). There have been some changes to the JS code of DokuWiki in the meantime that need to be merged with his work (there is one file that is automatically merged that might need to be adapted and there are conflicts in lib/scripts/linkwiz.js and lib/scripts/media.js, but I don't think it's that problematic). So if you want to do this you should know jQuery (or at least know JS well) and for doing the merge you should be able to work with Git. If you can do just a part of that rewrite that's possible of course, too. Regards, Michael -- DokuWiki mailing list - more info at http://www.dokuwiki.org/mailinglist