By Jerryvl on

I was looking around on the site, and did some searches, but I could not find any concrete road-map for the Drupal project. Does one exist? ... If so, where do I find it? ... If not, why not?

I believe it would be very helpful for all the developers (and potential developers!) on this site to be able to see what features are planned for next releases, which features are not explicitly planned short-term, and where the architecture is evolving to.

I would personally love to see information regarding the current and future architecture; i.e.: what direction is it evolving in. I am interested in contributing to this project because I love the way the product works, but I am having some trouble deciding which of my ideas fit with the "strategic direction" and where / how to discuss them.

Comments

moshe weitzman’s picture

moshe weitzman commented

no such roadmap exists. it would be nice, but noone has taken the exercise to poll the development community, and then produce a draft document for all to frown at. if someone wants to do this, i suggest working on this document publically via the Developer's Guide here on drupal.org.

dries’s picture

dries commented

I posted my Drupal 4.4.0 battle plan on the mailing list on November 2003. Some others have shared a battle plan as well.

Date: Tue, 4 Nov 2003
From: Dries Buytaert
To: Drupal developers mailing list
Subject: [drupal-devel] Battle plan

Here is an updated list of things _I_ (but not necessarily you) would like
to (help) work now Drupal 4.3.0 has been released.  This list can be best
summarized as "continue to strengthen our code base and remove some
cruftiness".

Additions:
----------

* File management: add file management functionality and use that to add,
for example, image support to other node modules.

* Configurable menus.

Improvements:
-------------

Part of this list won't come as a surprise as some of you helped identify
Drupal cruft.  I'm taking this serious so we can all feel confident about
the code, and the quality thereof.

* Menu system: remove '$type == "page"' links, add context sensitive help
to user pages, add breadcrumb navigation to all pages, remove custom
navigation menus (e.g. user information page), try to deprecate most of
the _page hook.  Remove the many "help" links and integrate them with the
context-sensitive help.

* Theme system: migrate away from the $theme object and streamline
theme.inc. Separate presentation from logic and content (eg. HTML around
the XML icons) and improve the CSS being emitted (eg. CSS tags around
blocks).  Make the core themes show off Drupal's theme capabilities (eg.
phpBB-style forum views).  Make theme_block() return its content rather
than print it and remove the output buffering from Xtemplate.

* Locale system: make it easier to maintain and share translations.

* Taxonomy: add a fine-grained permission system (ACLs) that is tied to
taxonomy and split the taxonomy module into taxonomy.inc and
taxonomy.module.

* Filter system: improve the filter system or better yet, the cache
system.  Consider permanently caching rendered node bodies, comment bodies
and node teasers.

* Search: rewrite the search module and rethink the search API.  Remove
the dependency on cron and update the search index on insert/update/delete
(?), use the new _content hook to prevent indexing of PHP code.
 
* Random usability improvements: make it possible to disable the comment
controls, make the watchdog module record more information (eg. the
contents of $_REQUEST), think of a better system to collect and show
status/warning/error messages, unify the "administer node" and "edit node"
pages, and so on.

For the old battle plan, see
http://lists.drupal.org/archives/drupal-devel/2003-07/msg00138.html.

To see what we actually did so far: read this post and this post.

Anyhow, what do you want to work on?

Jerryvl’s picture

Jerryvl commented

First of all, thanks for your battle-plan for 4.4.0 :) ... that's at least some information in the direction I was looking for. Even so, I believe setting up an actual road-map might be beneficial because it allows people to keep a clear view of long-term goals (i.e. beyond the next release).

One of the things *right now* that I could work on is general clean-up of some of the interesting add-on modules. Are there any "standards/guidelines" for modules that are not covered in the relevant sections of the handbook? When I clean things up I prefer going all the way and comply completely, rather than do multiple passes at cleaning up ;)

Some of the things that I'd like to think about / work towards for the longer term are maybe a bit vague still (even in my mind) and in some cases perhaps megalomaniacally ambitious. }:) Even so, here is the list of things I can remember thinking off the top of my head:

* There seems to be many different ways in which the contributed modules want to be installed into the system (i.e. the various INSTALL documents seem to have the same basics but vary in the details); I'd like to see an 'install' module, which is capable of using a standard 'module package' format, which has the installation instructions in a simple machine-readable and executable form, so that I can just add modules from within Drupal, and let the system figure out where all the contents need to go. :) Automation is our friend.

* If the above point were implemented, the next step would be to investigate a way to download additional modules straight from a register on the Drupal website, i.e. check the modules you would like and they are downloaded and installed immediately into your own system. 8)

* In addition, I think there need to be some more detailed standards for where module files go... currently the documentation recommends putting HTML resources (CSS files, JS files) in the 'misc' directory... it would be much better to use at least sub-directories so that the resources from individual module files can be distinguished (which will also avoid any potential name-clashes). It might even be a good idea to set uyp translation functions (like the theme functions), which translate 'resource()' into 'misc\\' to help ease/enforce proper usage.

* I don't know whether this has been mentioned by anyone before, but the 'module' format seems to contain quite a lot of unrelated hooks (i.e. some for nodes, some for filters, etc.). If modules are stored in a sub-directory instead, maybe this format could eventually be evolved to have separate files for individual '.node' and '.filter' definitions. This would leave less different methods to be implemented per file, and would make it easier to develop a module that contains multiple nodes or blocks or filters.

* I'd like to see more meta-data inside modules, some details about the author (to be displayed in the registration screen) would be good... I think it's safe to assume that most people thinking of developing a module do it for the recognition and would love to see their name appear somewhere... it could even be incentive to have more people develop modules. Beyond that it'd be a great idea to have version information, compatibility information with the Drupal engine and even inter-module dependencies available.

* I have seen some modules that implement fancier versions of standard widgets (i.e. I really like the HTMLArea Wysiwyg :D editor), it would be nice to have the ability to load sets of widgets (as part of)/(in addition to) the theme engine, so that the widgets to use can be configured from within the system, avoiding the need to patch the core system to use them. It'd need investigation what kinds of widgets should be part of this engine (i.e. text field only, or specialised fields for date entry / numeric entry?)

* It would be nice if widget selection (see point above) and filter application could be configured on a per-node-type or even per-control basis, maybe even including configuration for the order in which multiple filters should be applied to the input?

* It would be nice if the theme engine allowed for configuration screens just like modules, i.e. colour selection screens, logo upload, etc. so that themes can be made more (easily) customisable to individual needs without needing a coder to do so. I think there may already be a module out there that does something like this partially, but for it to be widely adopted it really should be part of the core system.

I think there are some more things that I cannot immediately remember, but this list is already long enough. :P As I said, some of these items are more 'long-term' than 'lets do that for the next release', and some will require careful thought.

For my background: I am a coder who doesn't mind writing documentation. I like Drupal (even though it might unjustly seem from the list that I think there are more things wrong than right with it), I know PHP well enough, and MySQL intimately, and I am not afraid to get my hands dirty to see some of this stuff happen, but some of this obviously requires wide support from the other developers, and most of it will need further discussion.

Jerry 8)

Jerryvl’s picture

Jerryvl commented

I was also wondering if there is an official 'Drupal mission statement' ... something nice and concise that sums up the guiding principles behind the project? Something like (my personal interpretation of what seems to be the Drupal mindset):

"The goal of Drupal is to provide a core CMS system that maximises customisability whilst minimising the complexity to participate in its use and development"

-----
Jerry 8)
Madness and genius are separated by a thin line... I flip a coin in the mornings

ax’s picture

ax commented

http://drupal.org/about (you guess ;)) (or http://drupal.org/node/view/1 or http://drupal.org/book/view/1, resp.)

as far as i can remember, this used to be a little different. see the thread starting here for the original discussion. here is the one that apparently replaced former.

(mailing list search is your friend ;))

Jerryvl’s picture

Jerryvl commented

Thanks for those links... the official link you sent doesn't really look much like a mission statement anymore to me ;) it's a bit too verbose. I reckon if it's too long people's eyes glaze over before they grasp the message :P

-----
Jerry 8)
Madness and genius are separated by a thin line... I flip a coin in the mornings

dries’s picture

dries commented

One of the things *right now* that I could work on is general clean-up of some of the interesting add-on modules.

As we are nearing a code freeze, this would probably mark the time to start updating and cleaning up some (contributed) modules.

I'd like to see an 'install' module, which is capable of using a standard 'module package' format ...

Adrian Rossouw is working on improving Drupal's update.php script so it can be used to (i) install and upgrade Drupal, (ii) install and upgrade contributed modules. I'm sure he'll step forward as soon he has something to show.

If modules are stored in a sub-directory instead, maybe this format could eventually be evolved to have separate files for individual '.node' and '.filter' definitions. This would leave less different methods to be implemented per file, and would make it easier to develop a module that contains multiple nodes or blocks or filters.

A module author can choose to split his module in multiple files, and you can already install each module in its own subdirectory.

Jerryvl’s picture

Jerryvl commented

Are there any particular modules that are more in need of additional clean-up help than others? i.e. which should I consider and in what order?

Regarding your comment on module split-up: are there any down-sides to splitting a module? ... if I am going to clean up any modules are there reasons to avoid split-up (beyond dependencies)?

How would Drupal react if there are multiple '.'s in module names, i.e. hypothetically if I split module 'widget.module' into 'widget_primary.node.module', 'widget_secondary.node.module' and 'widget.admin.module', would it recognise all these properly as modules?

-----
Jerry 8)
Madness and genius are separated by a thin line... I flip a coin in the mornings

dries’s picture

dries commented

Splitting modules into multiple files makes Drupal slower as it will take more (file) I/O to serve a page. Usually, there is no reason to split a module unless it grow too big and becomes hard to maintain.

Secondly, there is no order of importance but your own. Pick modules that you think are fun to work with/on.

Either way, there are many broken modules in the contributions CVS repository that need to get fixed. Grep/search for modules using the theme("header", ...), theme("footer", ...), status() and so on. See here for more details. You can also volunteer to become maintainer of an orphaned module or pick any of the active tasks or bugs.

hystrix’s picture

hystrix commented

I ran into something other day I didn't expect. Previously I had used several modules on a MySQL driven site, and assumed I would be able to use them in a work environment where only PostgreSQL was available. While I would imagine the differences would be slight, there were no .pgsql files offered.

Most used modules in this catagory that I have run into are:

I suppose it would be more appropriate for me to submit feature requests to each project.

adrian’s picture

adrian commented

i am the postgres maintainer, and i am looking into those modules for you quickly.

filestore i am hesitant to do, as it uses blob's to store the files and I am unsure about compatibility between db's re: blobs.

I also am not working on it, as the current HEAD has it's own file api , that supercedes anything on filestore.

project also requires a lot more testing than i really have time for at the moment.

feel free to contact me at adrian_at_removethis_dot_daemon_dot_co_za

I should also note that at this moment i am incredibly busy with a new install api for drupal, and postgres support is one of the major things i have taken into consideration while desiging it.

eap1935’s picture

eap1935 commented

Why do the developers of a CMS use email to distribute important documents like roadmaps?

bertboerland’s picture

bertboerland commented

Please dont bacome YACZ (Yet Another CMS Zealot).

People use mail to cummunicate. As they are using the telephone, instant messaging, portal communities (e.g. orkut), IRC and God forbids ... even face 2 face communication.

Developers, even CMS developers, are people as well

...

Ohhh, and they use drupal as well to communicate.

--
groets

bertb

--
groets
bert boerland