I'am currently trying to make a roadmap for the next ISPConfig relaeses and like to hear your suggestions, comments and where you are currently working on. I will split the roadmap in 2 parts, one for the ISPConfig 2.2.x stable releases and one for the ISPConfig 2.3.x dev releases (trunk in SVN). I think its time to get the current dev release to a point where we can make a new stable branch out of it. Here are my ideas: ISPConfig 2.2.x Just bugfixing and support for new versions of the current supported linux distributions without adding new features ISPConfig 2.3.x (Dev) There are many nice new features in the dev branch already, but there was no new dev release for some time because the new script for writing the postfix and sendmail configuration is not finished yet. I'am currently working on it. Here is a list of new features that I would like to see in the next 2.3.x releases or that are already implemented but not released in 2.3.1: - Enable / Disable FTP for every user individualy (till, finished). - Support for AWStats (jnsc, in progress). - Support for mailman mailing lists (jnsc, in progress). - Being able to select for which of the domains of a website a email address is created (till, Interface is finished, backend librarys are finished 60%). This is currently the main thing that has to be fixed to make a new dev release. And many many improvements and bugfixes and translations from other developers, please look at the SVN log for a full list. When you are currently working on new features, plesae post them. My Ideas for new features and improvements: - Selector for the type of apache rewrite rule ISPConfig uses for co-domains to create "real" subdomains where the URL does not change in the browser. - Support for FreeBSD - Improve the manuals and include the latest features. A "How to get started with ISPConfig" would be nice too. - Record sorting and paging for all "inline lists" like co-domains, users and DNS-A, MX and cname records. If this is implemeted once, it will apply to all of these lists automatically. - User prefix for usernames. - Creating maildirs with maildirmake when a user is created instead of letting postfix do it. Then a list of additional mail folders might be defined. - user cron-jobs - webdav - mod_mono and mod_python support - Add a check routine to the installer that makes sure that the libxml2 librarys are installed. - Translate all german comments in the code to english. In the early ISPConfig development, all developers where native german speakers and so there are many german comments in the code. This is a big problem now and I'am trying to translate them step by step to english, when I edit a file. It will be nice if german speaking developers might help me in translating comments to english when they are working on the files. This are just my ideas. Please comment and post your priorities and ideas. If you are alreday working on some functions or like to implement a new feature, please let me know so we can coordinate our efforts. I will try to make a official roadmap as result of this thread where we define our priorities for the next releases and get an overview who is implementing which feature. This will make it easier for new developers to get started with ISPConfig development.
Thank's for this roadmap, it's full of good ideas for the next Major release. For my part, the AWStats installer has been merged into SVN, but I still have to test a full install from a SVN checkout. For the Mailman feature, it is usable, but it still needs a lot of attention. Actually it's a patch against 2.2.9, it only works with postfix, and I only tested it on Debian. As I am just a human, it's also surely contains a lot of Bugs. I order to make it a stable feature it needs alot of testing. For me the most interesting feautures of your list are (but this is just my point of view): For the translation of comments as I speak german, I will try to help you whith this point. Regard's Jonas
It this the awstats with static pages? Cause I really want the dropdown box to be able to select previous months / years. That why I went with the "other" solution, though I know there no pkg of it.
Yes the static version. But with a little hack I am sure you can add a frame with a drop down list for the static version
I think ISPConfig interface is too dated. For example, several php scripts make intensive use of <font> tag or fixed width tables and cells, making css support of little use. I think tables should begin to desappear also from html templates, in favor of <div> tags. I think I can begun to work on the client part (is what matter most), but right now I have to finish a CMS project I'm developing from quite some time. I'll start, but it will be slow... main.htm template should look something like this: Code: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>{TITLE}</title> <meta http-equiv="Content-Type" content="text/html; charset={CHARSET}"> <link href="{SERVERURL}/design/default/style.css" rel="stylesheet" type="text/css"> </head> <body> <div id="content"> <h1>{WINDOWTITLE}</h1> {MAIN} </div> {WYSIWYG_LIB} </body> </html> And its far more mantainable to do things this way.... Cheers.
Of course, but that's really a lot of work. And as V3 of ISPConfig is already being developped, I don't know if it worth this effort. But as ussually this is only my point of view
I think a bit HTML cleanup would not be bad if you want do it. Its not looking nice when you look at the sources, but as long as all browsers display it correct can live with it
Another suggestion: Add a tick box to be able to skip generation of reverse DNS records. The datacenter does not allow me to manage my own IP addresses (yet) and I just noticed DirectAdmin has such a feature to disable rDNS.
I can write a "How to get started..." and improve the manual. For the first time in german and later I will translate it into english. Other languages I don´t know ;-) Just one question I have: Should the "How to get started..." comprehend a section with a HowTo Install or not ? (I think not - but if there someone have another opinion please let me know...)
I vote for "How to get started..." guide without included installation instructions We should consider putting the new guide and the current manuals in SVN under version control. What do you think?
Wikis have a problem: they get spammed very fast because everyone can change content there. We once had a wiki on HowtoForge and had to close it because of spammers.
Please drop frames, they are annoying Also may I suggest a very good BSD license menu generator: http://download.pear.php.net/package/HTML_TreeMenu-1.2.0.tgz http://pastebin.ca/raw/343396 renders a menu very much alike as ISPConfig does. Fast implementation and it can be styled with css also.
I guess this would be the best. Anyway I think it would be good that it be done in english inmediatly, so translation to other languages starts as soon as possible. Also, after the problem with updating doctype's definitions is resolved, I'll merge some code to let the admin define global error pages that dont get messed up with updates. Something similar to use "Individual Error Pages", but this are global and reside in a custom defined dir. Checkbox based... I have worked also in a "Execute custom script" option for creating webs. This would answer all request for people that were asking for a way to customize the creation of websites. You can define a custom script for hosting plans, or for individual sites. But I dont want this feature for resellers. What do you think?
I was thinking right now something. My design skills have grown a lot lately. I can develop a good lookin thing in a very short time. But ISPConfig is very difficult to mod with CSS. I would like to mod it. I dont want ISPConfig 2.X (dev branch) to die in favor of ISPConfig 3. I think there is a lot of things already done in ISPConfig 2.X . I saw some of the code of ISPConfig 3 (at least what was in the SVN repository at the time), and is not much. Not as complete as ISPConfig 2.X is. So my best proposal would be to enhance in all ways possible ISPConfig 2.X. 1) Drop frames, they are not necesary. They're annoying. We must let people know where they are. We can't hide the real url. Frames are evil, and are a extra level of complexity, that can be avoided. When I want to develop things for ISPConfig 2.X, or want to know a little more about data flow, I use "Show only this frame" in Firefox. 2) Regarding language definitions, I thinkg the best would be to discuss a simple directory structure, trying to avoid at the same time that language files get too big. I think a centralized language structure is a better idea. 3) Code style. Many times I wish that ISPConfig code was cleaner, more ordered. I think we should talk about code guidelines. For example, use two spaces for identation tabs, or whatever is decided. The best would be to change and adjust all code to what we decide. Big job, but it will benefit all of use, including new developers joining. I think the use of blank identation spaces if the worst problem here. Things like positioning { } are simply not that relevant for me. 4) As has been discused lately. Drop german in favor of English. Including $var names. I think this things can be done with a little (or big effort).
Thats not the intention (at least my). ISPConfig 2 is a fine controlpanel for single servers and my intention is to develop this project further even when ISPConfig 3 is relaesed. maybe we will switch to another naming scheme to make clear that the 2.x versions are not nescessarily older then the 3.x versions. A naming like singe server and multi server versions might be appropriate. If you have any ideas for a naming scheme, please post them Its currently just the mail and DNS module that are nearly finished. . It would be great if you want to start with this effort. I guess its very much work. Please let me know if you want to start on a redesign of the interface, I will make a branch in SVN for it, otherwise it might stop the complete development in the dev branch. The files are currently splitted per module. In my opinion they are not too big yet and the interface is loading fine. I'am not sure if its worth to put the work in splitting them in smaller parts. Anyone else has a thought on this? I'am aware of this problem too. I have always used tabs for the files, but it looks like some editors are converting them to spaces. I have reformatted some files from time to time but have given up Please opt if we shall use spaces or tabs, personally I configured my editor to display a tab as 4 spaces and tabs has on the pro side that everybody may configure the display width as he likes it. But the con side is that some editors seem to brake them. Does anybody knows how other large PHP projects are formatting their files? I guess changing the variable names is not that easy, at least when database column names are involved. But new variables should be named in english and the comments should be translated to english.
Great thing to know! Ok, I'll try to think about a good name then . Say no more, let's do it. My idea is in fact the oppossite. A centralized language repository. Maybe a common file for common definitions. And then split them by user type (admin, reseller, client), or modules like is right now. Same centralized place for all files. Like the centralized location for error pages, just like that. It would make the translation process a lot easier to do. Anyone could do it. Think about it, right now people must read a tutorial to translate files. I have done translations myself, and it is a real nigthmare to do so. Well, and about coding style. I code with 2 spaces for tabs, so I vote for that. Also, drpython, that is a python code editor has a neat feature to select some bunch of code and format it with tabs, so tabbing with shift would take all the selected code to the left, tab withouth shift to the right. So it is much easier than to do it by hand, line by line. I can try to reformat files in which I'll work from now on. The only problem I visualize is that the SVN blame feature and the diff from file to file will just break when reformatting a given file. But I think advantages are far more important than these specific problems. Daniel.
Code beautifiers are great for standardization of the layout, but still some more things need to be documented like Variable names: all lowercase, CamelCase, usage of - vs _, etc How to indent blocks, eg Code: if <expr> then { code } vs if <expr> then { } vs if <expr> then { } and lots more. It's perfectly oke to allow a transition period, as longs as we have set some coding guidelines to help us make readable code. The PHP team themselves (or more precises the PEAR team) have set an example for coding. Why not use that? It's documented at http://pear.php.net/manual/en/standards.php. I even found a small tool (but there are probably more) that check the code on following these guidelines: http://developer.spikesource.com/wiki/index.php?title=Projects:phpcheckstyleDocs
I Have lookaed at the PEAR coding guidelines and they look pretty nice. I've checked the code beautyfiers that jnsc mentioned, the one from waterproof is onyl available after registration so I will try the other one first which has become a PEAR package in the meantime http://pear.php.net/package/PHP_Beautifier The PEAR coding statndards are using 4 spaces instead of tabs, I hope that this can be configured in the PHP_Beautifier. Any comments on the proposal of establishing the pear coding guidelines for the ISPConfig code, with the exception of using tabs instaed of spaces if possible?
