Deprecated - Drupal core

Drupal is interesting but using html tags is not convenient. Why not include a more powerfull editor (wyswyg) ?.
Thanking you for your attention.

Please forgive me if this is redundant, but I believe this is a bit different from the Intallation Wizard planned for 4.6, and in my search here I found no obviously related discussion in the past 6 months. Perhaps I missed something, as I do not believe this is incredibly insightful or profound. But, FWIW....

One of the biggest barriers for administrators, I believe, is the amount of database and programming knowledge required for maintaining a Drupal site. Thanks ot phpMyAdmin, module installations have become a breeze for me. But I'm still trying to master the patch thing, and dread the day when I will have to perform an upgrade that involves changes in database structure. But recently I installed a module (forgive me, I've forgotten which one) which had its own installation scripts in it. It was incredibly easy. (Another hint that this topic may have arisen before.)

I suppose you can guess where I'm going with this.

Drupal - a highly promising and excellently designed open source software - prides itself on being "community-driven". A primary Drupal interest is promoting collaboration and the sharing of views and perspectives.

Yet, paradoxically, the project decision-making structure- a relic from its very early days - is notable for its closed, centralized, and fixed nature. Most decisions on the Drupal 'core' are still made personally by the project owner and founder, Dries. The only exceptions are decisions made by one of two close associates of his. This contrasts sharply with many other open source projects, which are build on the basis of community decision making.

To fully mature as a project, Drupal arguably needs to bring its structure in line with its community spirit.

Hence this set of concrete proposals. Their aim is to set out new, expanded roles for decision making, while ensuring that the current values of rigourous code evaluation and development are maintained.

On the Google Blog ( http://www.google.com/googleblog/2005/01/preventing-comment-spam.html ) there was a post about their idea for dealing with comment spam. Basically render comment spam useless by encouraging web sites to use the tag rel="nofollow" on any links within a comment area. They're more interested in cms and blogging apps to grab hold of the idea than for each individual to do it themselves.

The groups already on board are:

Brad Fitzpatrick - LiveJournal

Dave Winer - Scripting News

Anil Dash - Six Apart

Steve Jenson - Blogger

Matt Mullenweg - WordPress

Stewart Butterfield - Flickr

Anthony Batt - Buzznet

This won't actually prevent spam from being posted, but it will eliminate any incentive to spam. Google announced a new attribute which will prevent a link from raising a site's ranking. If all user-posted links have 'rel=nofollow' added, posting a comment on your site will have no effect on the poster's site. A simple patch to filter.module will automatically append it to any link in a user's post.

Add the following line near the end of the function _filter_html, just before the line return trim($text)

I've seen a couple of *old* threads here and there, talking about improving the drupal install process, and while I'm not bothering to tackle the installer aspect yet, I am working on some code patches that will auto-install the sql file that accompanies most modules (often modulename.mysql).

So far, seems to function fine, but only for installing sql, not removing *yet* (i'm going to create a table that will record all tables installed for a module, and then run a loop to remove those tables upon uninstallation). i'm using some code from the xoops project, for actually parsing the sql file.

once i have a decently functioning script, i'll either create a project or submit the needed patches for drupal core. the modifications currently take place in system.module (since i'm not yet aware of any hooks that would be activated upon module activation), so i believe patches are what would be best, unless someone would like to point me in the best direction to create a module for this procedure

another limitation is that this is only for mysql databases atm, but there's nothing to prevent others from contributing to help with supporting other database types. it really wouldn't take much effort, mainly testing. also, this patch would assume (and check for) a modulename.mysql file (or for whatever database used), which shouldn't be a huge problem, since most modules already use that format.