Personal battle plans for Drupal 7

Though I am a rather small player in your Drupal world. I plan to make contributions in the areas of integrating existing features with the many different public APIs that are out there. I've started this effort by trying to tie the Event module with Google's Calendar API. I'm certain that what I learn from that process will help me better understand how to integrate other GData-based APIs with Drupal.

Integrating Google Notebook in particular would be a good idea if they had an API for that.

The work others have done with Feed API looks like it would be beneficial for this project. My next step is to find out where it can help me.

Time permitting I'll focus on helping other projects that are also trying to integrate public APIs. Good candidates are: Picasa Web album API, Google Maps API, Facebook, and eventually the MySpace API.

Personally I aim to get my own house in order (document and release stable versions of modules) then, at some point in the next couple of months, start prodding at the list of bug reports and feature requests for the forum module. Having just moved a reasonably sized forum over to Drupal, I have a vested interest in making forum.module better. Will start off small and see how far I get!

Having prodded and poked forum.module a bit I'm aiming to move my main development environment over to PostgreSQL as it supports standard SQL; then set things up so it's possible for me to test code in multiple environments. So--eventually--I'll be able to lend a hand with PostgreSQL testing too.

Is it alright to be vague about my battle plan? As I'm still finding my feet with a lot of things it would be silly to rush in and say: 'let me maintain the forum module!' or something daft like that. Am going to take baby steps instead, but where I can help out, I will.

----
Web Design, GNU/Linux and Drupal.

I only really got involved in core development during the second half of the D6 release cycle, so my first battle plan is to be right there as soon as work begins on D7.

I'm planning to concentrate patch reviews and massaging again since it's been an effective use of my time so far, and so much good code gets held up at that stage.

I want to finish off the great taxonomy usability cleanup, since there's plenty of scope for improvement both in the admin and user interface.

There were also a few patches that didn't quite make it into D6, mainly user interface and performance which I'll try to help get in as early as possible into D7. As well as that, making sure all the big exciting stuff that's on the horizon gets tested early and often - both in core and contrib.

Data API
If you asked me this a few months ago, I would've said that the Data API was my primary itch to scratch for Drupal 7, but with the advent of the Drupal Data Architecture Design Sprint and all the wicked smart kids involved with that, I'm confident that not only will that itch get scratched in Drupal 7, it'll be covered in a nice, soothing balm. ;) I'll still be following that progress though and attempting to help however I can.

Usability
A couple months ago, my wife wanted a blog, and naturally I installed Drupal for her. ;) Watching her struggle to make her way around the administration panel in Drupal was truly a mind-opening experience, since she is sharp and very Internet-savvy, and hammered home more than anything else has that we have a bit of a ways to go in that department. ;) Since I truly believe that Drupal will save the world, an important first step is making it usable by mere mortals.

At the end of February, I'll be attending the first-ever Drupal usability testing (in, like, a lab and everything!) at the University of Minnesota, along with a few others from the community. I intend to use this experience to frame a more concrete "battle plan" for usability in D7 and beyond.

Automated testing
Thorough patch reviewers such as catch are valued community treasures, and another big focus for me is making sure we treat their time as though it were measured in gold.

This means continuing work on SimpleTest module, as well as the automated testing stuff that Rok, Chad, and others are working on. My ultimate goal is for "patch (code needs review)" to mean exactly that: patches that make it to this stage a) don't break Drupal in some horrible way (at least that we know about yet ;)), and b) aren't so old that they don't even apply anymore. So reviewers can do actual /reviewing/ -- does the code make sense? is this the optimal way to go about this? as I was going through, did I discover some new failure point for which we don't have test coverage yet? etc.

General nit-picky webchick-esque things
The usual cleaning up APIs that make no sense, further refining our coding standards and improving tools like Coder to catch problems, obliterating messy, notice-generating code (perhaps even E_STRICT compliance), cleaning up goofy database anomalies that make no sense, and other stuff like that. You know, the stuff no one else cares about? ;)

There are 2 things that i want to work on before drupal 7 code freeze:

• First one is complete localization support including different calendar systems and other stuff. mooffie is working on holidays module which i guess can be a good starting point for supporting different calendar systems. http://drupal.org/node/205500
• Second one is i want to help Drupal i18n team to make Drupal i18n & i10n leader. The great things is lots of things has already implemented and some of them are now in core as of drupal 6 (Thanks to the community for making it happen), i think only few steps remain to having a full featured easy to use multilingual support in drupal

sina.salek.ws
Feel freedom with open source softwares

I've sworn up and down to get image handling in core. Implementing at the very least: a CCK field (CCK MUST become part of core, however), dynamic image manipulation and workflows (imagecache), and ownership of image files. If a WYSIWYG editor is put in core, I'll certainly contribute to integrating the image handling with the editor. The most important thing is to produce a consistent, flexible system that can bring together our splintered approach to image handling.

Improve the AHAH framework to pass through the FormsAPI on the receiving end. The API on the sending end is great and easy to setup, but on the receiving end we're checking $_POST and all sorts of nastiness. However, if we submit the page to the *same* URL, we can do full form submissions through an AHAH request. This opens the door to much more dynamic content, handled in a secure manner.

I intend to participate in the Modal dialogs patch which could greatly reshape the Drupal UI as we know it. Think about getting rid of all those confirmation pages (Are you sure you want to delete x?). They all could be replaced by modal dialogs that have the ability to load and submit any form. Very exciting.

Javascript patch reviews whenever possible, UI improvements in Taxonomy, and helping webchick whenever possible :)

Like catch, I got in late on the Drupal 6 development cycle. I intend to be there right from the beginning for D7.

Nathan Haug
_{creative graphic design        w: quicksketch.org
& software development       e: nate@quicksketch.org}

First of all, I'd like to come back to Drupal family again, uid=11 puts a certain responsibility on you. Even if you have be far away you always have your roots planted somewhere.

So, for D7 I try to approach Drupal design with fresh outsider eye (but still aware how it all came to be) and try to:

- simplify the UI as much as possible, cut/hide all unnecessary noise. Find a way to fight against "this is not a wordpress, this is drupal" syndrome, stress the importance of clear UI, smooth flow, intuitivness is universal goal, not only for novice users.
- help to set up UI pattern library - for core to implement, for module devs to follow
- help on D7 big UI challenges: CCK/Views light in core, Blocks/Panels overhaul, GAnalyticsified/Feedburnerified/Mintified stats ;)
- help to set Drupal icons/gfx language: it is really easy to mess up here, overpizazz it. Try to keep it as simple and generic possible, use smart (unicode?) tricks etc.
- not to be a theme coder any more (need to let old cranky Bluemarine and Chameleon go from the core).
- help to make drupal.org a taj-mahal.org

It's fun for me to finally participate in this thread. For the past 3 releases I watched these threads and thought to myself "well, I'd like to contribute something but just don't know what it will be." Finally I've come up with a few novel areas I'd like to focus on to make Drupal7 better. Who knows if I'll really have time for them - but I hope to finish at least some this round.

• Install profile for basic blog (the Wordpress killer) - basically add some default things: freetagging category, structured category, a sidebar block that links to terms in a vocabulary, an about page, some menu items, and perhaps a few other simple ideas based on gathering ideas from other systems (wordpress.org distribution) and testing it out. I think that an installation profile that created some common sense defaults would help people explore and get used to their site. I don't see this as a good idea in general since so many people would then have to go back and delete all of it. But for the first time user it would be an amazing help.
• Provide a "login to site" permission Once the user is authenticated, this permission is checked. If the user doesn't have it then they are logged out with a configurable message that tells them what is going on. This is something that I've dreamed of using every time that I migrate a site to a new host or setup a time-specific site which then needs to be put into a "publically visible but not alterable" mode until a future date. The use case is this: disable login to site for most users, make a database backup, install that on the new host, flip DNS, enable logins for most roles on the new host. It keeps the content visible but unedited as DNS propagates.
• Default Javascript to the footer for better performance WimLeers has also proposed this and is a better Javascripter than I, but this is something that makes a lot of sense to me. It helps everyone from "shared hosting" Drupal users right up to top-end-clustered-hosting users. We should do this by default.
• Path alias metadata. This is something that the XMLSitemaps project and the Pathauto project both struggle with and it makes our lives hard. The url_alias table should keep more information such as the type of object the alias is for, an identifier for the object (nid/uid/tid) and some information about who made the alias (Pathauto, Manual, Workflow-NG etc.) so that Pathauto can know whether or not to overwrite it.

None of these are really earth shattering, but I think across all of them they will make Drupal better for end users, site admins, sysadmins, and developers.

--
_{Open Prediction Markets | Drupal Dashboard | Learn more about Drupal - buy a Drupal Book}

Like catch and webchick, I have a few things I'd like to do (or see done) with the admin interface, specifically in the modules area, but I suspect most of this could be applied to the theme area, as well. In no particular order, they are:

• Quick access to the configuration area.

Usually, after I've installed a module (or theme), the first thing I want to do is check out what configuration options and access controls are available. That is usually a two or three click process (not counting the time it takes to re-find the module). If the module is one of those that puts its settings in a non-standard place, it's many more clicks ("Where is that page?"). Also, along this same vein, indicating that there are no configuration or access control settings, so I don't spend five minutes looking for the non-existent page.

• Update the module dependency checker to do a more complete job.

I first noticed and posted an issue about it here: http://drupal.org/node/109395. I hope I can pick up on this (probably w/chx's started code) and run with this to completion. As a sub-item of this, I would also like to see if I can come up with a way of disabling dependant modules, which can prove to be a much longer process than enabling dependant modules.

• Add an API (or multiple APIs) to allow modules to interact with the user during uninstall.

Right now I'm so clueless as to what this will take that I'm not even sure how difficult it would be to implement, but it is something that has bothered me for some time. I would like to ask the admin if s/he want s to remove this, that or the other thing, rather than assuming it and removing everything. Currently, I just don't remove whatever it is I am unsure of, making them have to do it manually.

There might have been a fourth item, but I can't remember it now. Considering the ambitiousness of at least two of the items above, with limited availability I have had in the past, I'll be doing good if I can accomplish those I can remember.

I've been scared off by the installer before (Drupal looks less neat that far outside the familiar modular structure), but I hope that with some effort I could improve the way the installer adds multisites.

Specifically, I would like the installer to specify and create a certain site folder on demand rather than requiring the folder to be pre-created, in an effort to make the addition of new sites to an existing multisite environment more convenient. (This would be an advanced option, naturally).

Much of the hard work is complete, however incompatibilities with existing drivers and PHP 5.2.5 have caused delay. Will hopefully present current progress with others at Drupalcon Boston.

Testing
I've been helping on the issue queue of D6 for a few months and I will continue to do it for D7.

Inside
I would like to help with core code, testing, patching or improving things, like adding constants to magic numbers (http://drupal.org/node/200572), RFC2822 for email accounts (http://drupal.org/node/214114) or working on localizing the parts the user see (http://drupal.org/node/211831, http://drupal.org/node/206337).

Out
I'm really impressed with the improvements on the user experience that jQuery (tabledrag, aha, teasers) has brought to Drupal. I've been working/building guis for some time and would like to collaborate on bringing some more desktop "advantages" to web frontend.

----------------------------------------------------------------
Your site will be assimilated. Resistance is futile

Most everyone here is far beyond my skill level with teh hacking, but then again the vast majority of people engaged with the Drupal project in some way are as well. I would like to remind myself to keep adding nuggets of documentation and useful responses to trouble threads. I am very interested in UI design and hope to help with making sure that the 'mental model' that end-users develop is logical and delivers what they think it will. Here are some items for the less advanced, like me, that I hope to take a stab at:

• Install a Drupal 6RC3 test site to see what it does, and try to get a sweet debugger that works
• Help my favorite lesser-known modules get up to D6 and test them.
• Add something - anything - to a documentation wiki
• Work with community activists to find new ways to deploy Drupal - this is happening a lot in the Twin Cities area due to tcopencircuit.org
• See if new translations (i.e. Hmong and Somali in this area) can be created on D6. Drupal Somalia should happen!
• Find out what can be done by combining the social networking tools, and add testing/feedback to the new proposed Drupit open source social networking install profile
• Only putting in bug reports that are detailed enough to be helpful
• Try to develop my own features instead of writing a request (UI mainly)
• Find & support other ways for Drupal-friendly people to contribute without coding
• Spec something useful for D7 user interface via nice looking mockups

Right now I am focused on finding ways to use JavaScript to make the Drupal admin UI more fun to interact with. My current obsession is Modal Dialogs. Like Nate said above, Ajax dialogs have the potential to really kick it up a notch. My battleplan is to catalyze the conversation over at the JavaScript Drupal group (http://groups.drupal.org/javascript); experiment with a Drupal 6 module (http://drupal.org/project/popups); gather feedback and collaborators between now and DrupalCon; present at DrupalCon (fingers crossed, http://boston2008.drupalcon.org/session/modal-dialogs-not-just-evil-anymore); and then work on converting the module into a Drupal 7 core patch at the code sprint.

You can see a screencast of what I am so excited about over at: http://www.citris-uc.org/blog/tao/drupal_modal_dialogs_and_cck

I will also continue to convert my modules to Drupal 6, help convert the modules I use regularly, and provide a steady stream of patches based on what I learn in that process.

Overall I am excited to get involved more deeply in Drupal 7. I helped out a bit with Drupal 6, but now I am starting to really understand the process.

This is my first time contributing to this thread series, though I've read each one. Up until recently, most of my contributions have been in the form of support and documentation. But now I've moved on to writing modules.

My biggest focus for this coming year will be improving the forums. There's a few of us that are getting together to make a big push to improve the core forum module for D7. In addition, I'll keep working on the advanced forum module in contrib so the D6 forums have more features. I'll keep a branch of the contrib module in synch with the core forum changes so we can release D7 with great forum possibilities between core and contrib.

On the user profiles front, I'll keep working to improve advanced profile in contrib, including porting it to 6 once panels 2 is ported. There's also some discussion between webchick and fago about taking the best features of bio and nodeprofile and creating a new, lighter module that could possibly be core worthy. I'd like to see that replace core profile in 7 or possibly 8.

Michelle

--------------------------------------
See my Drupal articles and tutorials or come check out life in the Coulee Region.

[Edited to flesh out the plans a little]

1. (contrib module) new method for translating 'user defined content'
2. project* service
3. eclipse mylyn connector

I am going to work on documentation for the modules that I use. There are lots of things to learn, and it would be nice to have some more low tech examples in the handbooks. Something a new drupal user like myself would appreciate.

Busting myths since 2008

I plan to contribute to documentation, including Panels 2 and Flexifilter, and perhaps one or two more. I will re-review the patches that were moved to the D7 issue queue, and learn how to reroll patches. I also want to help cwgordon7 with the DROP program... which may or may not be named DROP.

It is my hope that by the time Drupalcon comes around, I will be able to contribute in many more ways than I can now.

I am very new to Drupal, used phpbb, joomla heavily and i am a java coder.

By the way,

First, I can see nice themes but not killer ones as Joomla! community has.
I am working on themes, trying to beautify over all look of the site on my visitors eye.

Second one is forum.
This is a great plus for Drupal over Joomla, but i think it is a temporary great plus.
My belief is, phpbb (and others) will be easily integrated to any CMS in the future.

This will be the new age at OpenSource Web softwares,
because every nice and strong software will be more nicer and stronger
when they bridge each other efficiently, easily and securely.

I am working on understanding forum of drupal, and ways to make it prettier on last visitors eye.

Yeap, these are 2 things i am doing.

after having lots of fun thanks to this post:

http://heine.familiedeelstra.com/input-formats-beware

I will work to at least be able to have different default filters for roles 1 and 2, and to create a hook/setting so that filters (like PHP) can declare themselves to be never available for role 1.

My primary battle plan should be enhance Drupal cross database compatibility. I have involved in this topic for around a year, and I would like to keep it on going. To accomplish this target, I would like to complete the following tasks before D7 code freeze:

• Improve Database API for better abstraction

  Something should be done before any other targets, e.g. resolve reserved words conflict, split drivers into individual files for better management, indeed but simple abstraction for different database syntax, add INSERT/UPDATE/DELETE abstraction and enhance drupal_write_record() abstraction, etc. With a better common base for multiple database development, we will need much less time to study the differences between databases than that of before.

• Add PHP PDO supporting

  Shipping D7 with PHP PDO should be a spotlight topic, since it is now official package for PHP5.2.x, and legacy drivers will soon be removed in PHP6.x. We may need some cleanup in our core query syntax, in order to let PDO get works.

• Introduce more database backend

  Up to this point, I would like to introduce some other database backend for D7, e.g. Oracle, SQLite, IBM DB2 and also MSSQL. If we are able to support SQLite in D7, which also means we are going to standardize our core queries into SQL92 standard, the problem for maintain multiple database backend should no longer a critical problem; if we are able to support Oracle, the most complicated database I guess, this should no longer a problem for us to implement drivers for other databases.

I have summarize most of my personal battle targets in here. Most logic are proved as functioning, and they are all get set for the open of D7 public development. On the other hand, I would like to explore if this may integrate with other interest musings with Data API, so we will able get all stuff better in D7 ;-)

----------------------------------------
What do you hope from my personal blog??

Since Drupal is now at least 9% JavaScript according to Ohloh, I'd personally work more on Drupal's JavaScript-related stuff. Drupal is relatively new in the field of JavaScript (even though we do have JavaScript gurus amongst Drupalers), and its JavaScript code needs much love and improvement. Library and framework compatibility will be one of the many JavaScript things on my radar for Drupal 7.

Also, usability. Paraphrasing webchick, it shouldn't take mere mortals too much to simply use Drupal. I want to turn more mockups into tangible patches. Mockups. Eye candy. Graceful fallback. Drupal's somewhat less Ajax-y roots makes it an excellent basis for graceful fallback to happen. Sooner or later, drag-n-drop will be taken for granted and weights will disappear into oblivion, unless for some odd reason the user turns off JavaScript or is using Lynx. I believe with all the growing usability love, Drupal 7 will truly live up to the name of Web 2.0 with a better user experience.

More control from the super admin side from drupal core ui.

Examples.

There is no disable function in for rss.
Finer user control such as what they can edit and can't if you create extra fields for profiles.
Add more widely used modules into the core. Such as how update module was implemented into the core. CCK and Views come into my mind.

That's just some examples but there is alot more when you seach through drupal. Basically to control every aspect from the superadmin side as much as possible from the ui.

My personal mission will be to convert core modules into mostly glue code.
For example, the blog module will create a *alterable* content type in hook_install, and create a view to go along with it (if views gets into core, that is).

The same could happen with forum and poll - forum would be a content type, a taxonomy vocabulary, a view, and some CSS, and poll would be simply a new field type (assuming fields get into core).

Of corse, I would love to do other things, like new FAPI types (read: colorpicker, integer, decimal), help with popups, usability improvements, but we'll see how the time thing works out.

I am really new to Drupal after several years on Wordpress and Joomla. I think Drupal offers much more than the rest - mostly because of some core ideas such as Taxonomy. However first time round when I was trying to choose which way to go I left Drupal out (this was 4.x version) because while it looked powerful I just could not figure out documentation on the site. There are tutorials, snippets, howtos, slides, theme snippets and then a theme developer guide with more how to's and snippets there. It gives the idea that there is a lot there - but it is hard to find the definitive answer to problems. So you never know if what you are reading is still valid or not or if it is an accepted "best practice" of just something that someone did once and decided to post.

This is critical for Drupal because while the very same concepts that make it such a great solution are the ones that also make it hard for people to get over that initial learning curve and the variety of ways to solve a problem makes it hard for newcomers to know what is the best way. So leading up to Drupal 7 I would like to work with others to improve Documentation to create a base that can then be updated for Drupal 7 as that takes shape.

The documentation I would like to work is with a focus to developers rather than people that don' want to know about Drupal code (for which UI improvements would be more significant than a manual).

Here are some of the things I would like to focus on.

1. How The Drupal Engine Works in 10 minutes - An animated walk through for developers that know PHP, CSS, etc and need to figure out what is the series of function calls that Drupal executes to put a page on screen.

2. Forms explained - Forms Use Cases with code snippets

3. How Triggers/Actions Work - Use Cases with code snippets

4. How CCK Works - How to Add modules to CCK - Use Cases with code snippets

5. How Views Work - How to create views in code - Use cases with code snippets

I think the above in clear documentation coupled with an understanding of theming provide all the ingredients someone needs to be convinced that they can dedicate time and resources to Drupal.

Now - I would like to propose that the above be implemented in a site that makes uses voting to judge the quality of the documentation and the snippets. This way the best explanations/use cases would flow to the top. Would be happy to set up the website myself or to talk with others interested in how to do this. Or to be told that these things are not really needed :-)

Drupal is a very open framework for managing any sort of content, but I see it lacking in two main areas: forums and a wiki. While it seems like there are many people willing to improve forums, I think that's covered, but in terms of creating a type of wiki with Drupal, there aren't many options and non of them are complete. I'd like to work in this area and either develop a single module along the lines of Liquid (http://drupal.org/project/liquid) or to create something much more lightweight, such as just a filter, but one that supports more than Freelinking and Citation Filter.

I also want to work on an installation profile that would setup a development environment for Drupal. There is an entire book page dedicated to describing how to setup Drupal for a development environment, but unfortunately, no install profile and I think there should be.

Configurable workflow support in core.

The only thing I'm interested in is the Taxonomy system, that's the only reason Drupal is so good I will research on the specific problem in Taxonomy system. Include something to handle a huge amount of terms with multi-parents and no two terms have the same multi-parents. for example, "USA 2007" with parents "USA" and "2007", "China 2008" with parents "China" and "2008". Because if just tagging the item with "USA", "2008", "2007" and "China" can mislead user to think "USA" and "2008" are associated

bjaspan put it nicely in the DrupalCon 2008 and Services discussion:

Drupal is a powerful platform for building web sites but is currently not well designed for developing web services. This session will be an open discussion for what and how Drupal needs to change to support web services development. Some obvious candidates include:

* Re-factor core (and hopefully contrib) to be API-driven, not form-submit driven.
* Create the ability to render all output in multiple formats (misc XML DTDs, JSON, PDF, ...), not just HTML.
* Create the ability to treat external content the same as internal content instead of requiring everything to be imported as a node.

This is going to my personal battle plan with Drupal 7. Making Drupal act as a web service platform.

• WYSIWYG Editor - finish nicedit and refactor so that the administration/configuration is reusable by all editors giving us a a core extensible editor.
• Input Filters - create filter options based on CSS attributes, not just HTML tags (see #205160) which I believe is needed for the WYSIWYG editor.
• Search - refactor search node_rank with hook_node_rank scoring factors (see #145242).
• Secure Password Hashes - phpass is a fully implemented system, but would work better with a hook or two in core. I'm not sure quite where these hooks belong yet, but something that will allow us to create modules like this in a more re-usable similar fashion. (see also #29706)
• Column Theming - add column theming to core (see #theme Form Elements into tables).
• Coder - create a 7.x upgrade review, and other enhancements to support review metrics (see #215368) and CVS ci and d.o.
• Pager API - Refactor pager query to create a more re-usable pager API (see #173037).

Improve Usability/User Experience of Drupal

Main goals are

• An easy to use Admin Theme (Initial Work)
• Wireframe a more intuitive installation process (Using the reports of the UMN testing labs as a reference)

Supplementary Goals

• Improve Node Forms Usability
• Improve Local Tasks Usability

I'd like to clean up taxonomy and comment module. They are a bit ancient.

I also want to continue to work on making Drupal faster and easier to use on big websites. I especially want to work on getting master/slave support into core.

There are also other performance related patches that need review and some work.

--
Drupal services
My Drupal services

(@Killes, above, also please post details at the taxonomy group!)

After checking to make sure I hadn't posted a plan I never did in personal battle plans for Drupal 6, I feel OK putting out a very modest battle plan... call it a skirmish intention...

Pass data back and forth between login, registration, and resend password forms. This has bugged me since the beginning– when you start to sign up at a web site, you're likely to start filling in the registration and/or login form without really registering (cognitively) which form you are or should be filling out. A little bit of javascript goodness, and/or a button to "Register" that takes you to the full form from the "Login" form, would be a huge user-friendly boost. Likewise for offering to send a replacement password when you try to register with an existing username/e-mail or get your password wrong.

If I'm able to do anything with this I may turn to the bigger issue of registration flow– let people register or log in while posting content, but this would probably require getting a good deal of LoginToboggan into core.

^{benjamin, Agaric Design Collective}

Add more options, to drupal became more configurable, exists lot of functionalities that can't be configurable.

FORUM;
RSS;
Change the errors to one configurable static page (e.g. BD Error);

____________
Marco Sousa
https://www.gaap.dev

Making them not suck.

I'm annoyed at the fact that you always have to have a _support module to be able to do anything, so i want to make profiles simpler to develop.
A large part of that is also making profiles be able to do things like provide cck node types and fields, and provide views.

--
The future is so Bryght, I have to wear shades.

Developing input formats (the core filter module) according to the idea exposed at Input formats. A different point of view.

--------------
Claudiu Cristea
http://www.ascentgroup.ro

We will be supporting our modules such as login_destination as well as audiofield and videofield modules for CCK. I would like to implement a good solution to output audio and video data uploaded by this field (may be integrate it with SWFTools). I would be glad to help Dopry to move all common functions into filefield.module and make other file upload modules such as imagefield, audiofield and videofield to depend on it.

I would also like to propose a few things which we consider will improve Drupal architecture. They are not what we plan to contribute because they are related to core or modules maintained by others:

1. Take more "low level" modules into core. Low level - means module do nothing visible but give useful API for other modules. Example: token.module.
2. Take CCK into core and make it so that all other modules can use its API/hooks to create/add fields for existing content types. This will help modules such as location not to bother about creating their own tables and managing data to extend nodes with needed fields. Instead, they will just specify which fields should be added to which node types and CCK will do the rest (those fields should be probably not removable).

   This will make table structure far more cleaner. There will be no so many SELECTs on node_load event.

3. Split NODE entity into two entities: NODE and CONTENT. Make NODE to be the base of CONTENT, TERM, USER, COMMENT. CCK will be applied to NODE. So, everything which inherits NODE will receive a powerfull extending mechanism. Node will be a simple object (with no content features) and will be used to create/manage/extend data. CONTENT will be exactly what Node is now.
4. Improve taxonomy. There are two huge inconveniences here:
   • Very poor control of form elements. Taxonomy should not bother about populating any elements to node form. It is very difficult to control their appearance now (CCK is far better). Taxonomy has to manage hierarchical structures only and provide API. Then CCK taxonomy field will be used to bind terms to nodes, set required flag, define possible widgets, etc.
   • Taxonomy method of storing hierarchical structure is not the best. There is more advanced approach to storing trees in a table.
5. User profile need to be reworked completely in order to utilize power of CCK package. May be nodeprofile.module should be reworked and taken into core.

----------------
Regards,
Dmitry Kresin, ARDAS group - Web site development, Drupal services, Software development, IT outsourcing.

item 1: path validator for path module (check if user chosen path is available)
item 2: module manager for small snippets, so one doesn't have to have swarms of tiny modules, the manager will contain and hold them all
item 3: xmpp for drupal

that pretty much sums up my current plans at the moment, though i think the first two will be done soon. third will take some time, but thats the real cool future.

I've been using Drupal for over a year now for a tutorial site and a non-profit site. During this time I've been learning PHP since I originally did all my development in C# and JAVA. For this next phase of Drupal I hope to get my feet more wet with module development. I've been reading the Drupal Development Book and playing with my own custom modules.

I hope to have my first contribution of a simple but useful module such as a Drupal tip of the day type module. I also hope to continue posting and hopefully fixing bugs in the modules I currently use that others have developed.

Sorry this isn't a bigger chunk of future Drupal 7 development but I know as I learn more I will be able to contribute much more.

I'd like to help KarenS et al. integrate PHP 5's Date/Time system with Drupal. Geographic timezones can be used so sites and users will no longer have to set their offset forward/back, and any summer/winter times in the past or future can be correctly calculated.

I'll be coding or leading others to code lots and lots of unit tests, most probably SimpleTest. The plan is to create a regression test for core and 50 to 100 modules. Making it automated would be even better. Maybe I can hook up with webchick on this.

I'd like to be involved in the data API / new database abstraction efforts. I think I have things to contribute there.

And in general, I'd like to spread my wisdom to other efforts. Not to be too boastful, but I've been around the block more than a few times, and often see otherwise brilliant efforts make some obvious mistakes which could be avoided with a little perspective. Hopefully I can provide some gentle advice which will be accepted in a few other places.

I blogged my battle plan: http://wimleers.com/blog/battle-plan-drupal-7

//
At first i liked better Joomla because of how it looks, i mean it's site is rather nice, it has a nice theme and i like how the news articles are presented, along with nice images. But when i tried finding out more about the features, it blowed me away; sorry joomla, but a good project has a nice introduction with images and feature list and no, an offline live demo doesn't counts.
//

I would like to help out with graphics (3d, 2d raster or vector), especially for news articles and such (like joomla has because i believe they add a very nice touch to the articles and site) and perhaps even with themes (if i can manage to skin drupal... very new to it and i'm not really into coding).

~!Obey King Dread Knight!~

My battle plan, in the form of a bad haiku:

Strings yet exist which
Drupal six has not tweaked.
There will I focus.

I'm getting really fast at patch application and testing and reporting, thanks to the many fine folks in #drupal, so I'll be doing a lot more patch reviews this year. Yeah!
______________________________
Senpai (also see my Drupal Dojo account)
I work for Achieve Internet.

Im interested in taking a crack at a Drupal-specific CSS Sprite generator to help the great push of Drupal performance to another level. I would like to have it refined enough to possibly be included in D7 core

____________________________________________________
Tj Holowaychuk

Vision Media
350designs
Stationery Style Design Inspiration

First off, I'll create the rules engine for d6,
then if there is interest in it I'd have a look at improving the drupal action triggering system to be rule based.

I haven't been involved in Drupal core yet, but since Drupal 7 development is open I really wish to contribute something. Most of my plans are a direct result of my Google SoC 2007 participation.

Introduce a new Core theme

I really feel that besides Garland Drupal is really lacking some decent core themes. Because it was the initial idea behind it and because it provides a good base I want to enhance and improve the Deco theme to be included in D7 Core. Not as a replacement for Garland but as a complement.

Admin theme

There has been some buzz #79023: Get an administration theme into core about making an admin theme. I really like the idea of this, so I'ld like to contribute to some of my ideas to this issue.

Color.module

During the development of the Deco theme I really struggled with implementing color.module support. While color.module is a great idea it's not suited for complex themes. There's an issue #166054: DROP Task: Color.module: themes can only have 5 color options pending for it and it has been marked as a DROP task, so I'll probably claim this one ASAP.

At a glance under the hood of aggregator.module (#16282: OPML Import for Aggregator), I notice that a lot of it could be smoother, especially when the aggregator syndicates a ton of feeds. Here's a list of thing's I'd like to add or improve.

Batch updating.

My cron job was completely killed when I added a large number of feeds (>400) a while back. Right now aggregator_cron attempts to refresh all refreshable feeds with no care for volume.

Cache feed errors

and do not refresh failed feeds until told to do so. (Adhere to the RFC 2616 definitions of which HTTP statuses are temporary and which are permanent)

Site URLs

Support site URLs alongside feed URLs. For most feed formats, the site URL is specified in the feed.

Auto-discovery

. Support auto-discovery of feeds if a site URL is entered instead of a feed URL.

List may be added to later on. Feel free to add your own pet peeves regarding the aggregator...

This is more or less what the user-readonly module does (with respect to profile fields) in drupal 5.

This one has been bugging me for a while, it would be very simple, and very lightweight. Similar to my visibility_api module ( should be more robust for D7 and also should be in core ) many modules including blocks, table_export, all WYSIWYG's need visibility settings, be it by path, role, CSS selectors etc. This is something I believe should not have to be hard coded into each of these modules.
____________________________________________________
Tj Holowaychuk

Vision Media
350designs
Stationery Style Design Inspiration

I have been working hard on a PHP script which I called MergeDB.php. I merges two Drupal databases, the development database and the production database, and creates a third new Drupal database with the results.

As I see, this should be a very common problem that many administrators face against every day, so I wonder why Drupal lacks some support for that issue and more surprisingly, why there are no requests for that in the forum.

Some time ago, I deeply browsed the Drupal site searching for some answers (tutorials, snippets, forum, ...) but only find this short poor information:
http://drupal.org/node/120617

Then I decided it was time to post a question, just to make sure that I was not going to invent the wheel for the second time:
http://drupal.org/node/206066

And finally, after some nights programming, I developed MergeDB.php. I would need some help:
- to convert it into a Drupal module (configuring from a graphical interface would be more comfortable than from an XML file)
- to migrate from Drupal 4.7 to other versions (probably no major changes are required, but not sure as I only know 4.7)
- to write the documentation in native English (I can write a draft in quite "understandable" English)

Regards.

• I'll work hard to bring Inline API (at best including Wysiwyg API) into a working and stable state for D7. douggreen's efforts will hopefully boost this goal.
• Also: Enhancing translation capabilities of Drupal core by introducing a new layer between user input and data CRUD operations.

Daniel F. Kudwien
unleashed mind

I am hoping to make it posaible to run drupal just on php 5.2 + so all I need to do to setup is upload the .tar.gz file and extract it on the server. With to need to setup a database or permitions.

and make blueprint css theme gen

one good thing would be to implement the multiblock module in core block module
http://drupal.org/project/multiblock