In Dries' talk at DrupalCon Boston, he mentioned the need to remove code from core as well as add functionality. He specifically mentioned proposals to remove the throttle and ping modules from core.
Removing functionality is often an important thing to do regarding usability, and so I thought I'd raise this here.
I've just added an issue to the D7 queue a proposal to remove the "blog-it" functionality from aggregator.module. I've laid out all the arguments there. Please jump in and +1 it or argue otherwise.
Drupal's "evolution by patch" philosophy means that the decluttering of Drupal needs to happen one function at a time. The purpose of this post is simply to encourage people to discuss "What can/should we remove" and to point people to the D7 issue queue as the place where specific proposals need to be made.
It's kind of funny that a proposal to remove functionality needs to be listed as a "feature request" (none of the other categories fit, do they?) May "feature deletion" should be added to that list. It might be a way to, at least, get it on peoples minds that feature deletion is important too!
p.s. One side benefit of removing functionality is that aspiring/novice coders (like me) can jump in because it is often (not always) easier to remove code than it is to write it.
Comments
Page vs. Story
Why does Drupal come packaged with multiple content types? I've never understood this and I'd be game for removing page and/or story and/or blog as separate entities. I think if CCK moves more towards a core installation in D7 that the need for pre-packaged content types will (hopefully) go away. A blog is really the same an aggregation of a taxonomy term and on a lot of my sites i've found it easier to just apply a term to a page and then create a blog/rss link via that taxonomy. Blog seems to be replicating this functionality. Maybe there's a certain stigma by not having blog but a lot of the functionality seems replicated elsewhere through similar features in taxonomy and the page content type. If be for removing Blog (at least as a separate module), keep the blog terminology around somewhere or alllow for the option to (more or less) tag something as showing up in your blog but I really don't see a need to separate the content into a separate type OTHER then so that people can coming to a site and go "I want to blog, oh there it is!".
+1 on removing things / simplifying things :P
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
"Issue" exists to remove "blog" from core
btopro,
In fact, there is already an issue in the queue for removing the blog module: http://drupal.org/node/233407. Don't let the fact that the issue is marked "postponed" stop you from +1 ing it. Removing the blog module requires the removal of some dependencies. But voting for its removal keeps the momentum going on all of this.
Something that came up at DrupalCon Boston out of the Minn usability tests is a developing consensus that Drupal needs to ship with sample content which would include some nodes, a couple of vocabularies populated with terms, etc.
In that light I think the existence of "story" and "page" are fine -- if they are clearly explained as sample/example content types, just like there is a proposal to make the new "welcome to Drupal" splash page a sample node.
Also, if the core version of CCK gets more robust to include the ability to add additional fields to a content-type -- then there should definitely be a sample content-type which includes more than the stock title/body fields.
Shai
Shai Gluskin
Content2zero
Will do on the +1, I'm just
Will do on the +1, I'm just starting to throw myself into the community so I haven't gotten into issue scanning yet :P (soon enough though!). I did hear a bit of that discussion from DCB but I think that if it does ship with some initial content that there should be two installation profiles: one that is naked of content / types and one that does what you've mentioned and prepopulates some things. Another thing that I think would be interesting and I've proposed in discussions with a few people is making a super type that's automatically setup. What's a super type? A super type would be a type that automatically picks up other CCK fields when it's created. I'll be throwing out a few modules / glue code type things that could demonstrate when you might want to use this type of an approach but just as a breif...
I think there are sometimes were you want to define what users can input in a context driven way (certain times allowing 3 max image fields or a video for example) but still classifying the information the same way and still handling it in the same way so that you don't have to micromanage all the different potential content types and their privileges just to make things less cluttered by showing all fields.
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
FYI -- Proposal to axe "blog-it" moved to another issue in queue
There is a coding convention that is broken in the function that I propose removing. The breaking of the coding convention is raised by Catch in another issue.
Since my proposal solves coding convention problem (through surgical removal), I've marked my issue as a duplicate and put my proposal on the issue that Catch started: http://drupal.org/node/233407
Shai
Shai Gluskin
Content2zero
Site slogan & Mission statement
This could certainly be a case of my misunderstanding things, but something I've been wondering recently is, can't you get all the functionality of the "site slogan" and the "mission statement" in themes by using customized block regions in your theme? And blocks are generally more flexible, so why not do away with those two and simplify the theme settings page? Or am I missing something?
Drupal's Target Audience, What Level?
I think that Drupal is targeting both higher end web sites who use professional design firms as well as trying to be a relatively out-of-the-box solution for regular folk (willing to discover their inner geek).
Creating a customized region in a theme is not something that someone who wants to build and run their web site from a gui will do.
I was a regular person "willing to discover my inner geek". Now I'm actually a Drupal professional. I was a content-person looking for an interactive web solution for the organization I worked for. The level of geekiness required for an entry-level Drupal web site was low enough that I thought I'd give it a try. And then it was love, and I've been dating my inner geek ever since ... :) and Drupal is my life (thankfully an exaggeration).
So Drupal gains a lot from doing certain things that are clearly for entry-level folk and can end up seeming inelegant from an information architecture perspective or other perspectives.
I'd be curious to know how many people actually use site slogan and site mission. I find that most off the shelf themes present site slogan and mission really poorly so if I used them at all I'd have to get into the theming layer code anyway. That would be an argument for dumping them. But if people actually find it useful, lowering a certain barrier to entry by providing some functionality out-of-the box, then I'd say keep them.
Shai Gluskin
Content2zero
yes, and. . .
It's not even necessary to customize your block regions to duplicate the "site slogan" and the "mission statement" functionality. You could simply create a block for each that contains the appropriate text. Since you typically have multiple block regions already built in to most templates, that already gives you more flexibility than the stock site slogan or mission statement. Plus, you can customize exactly what pages you want to have those blocks appear on. And even newbies will want to learn how to use blocks eventually. Creating custom regions is only icing on the cake.
Since the site slogan and mission statement aren't always supported in themes, I think any benefit for beginners is outweighed by the resulting confusion. Please correct me if I'm wrong, but I think that theme developers could substitute a new block region for any instances of either $site_slogan or $mission in a theme. This would increase flexibility, avoid redundancy, and potentially avoid confusion. It seems like a win/win, to me.
devel list
Gabor was discussing this on the development list a month or so back, and specifically suggested using blocks and regions to replace the custom handling. I've also seen discussion about changing the special handling of primary and secondary links (and the search box) to be themed blocks/regions instead.
So creating some default blocks for these, probably via the install profile, then modifying the core themes to use them, might be a really nice patch. And it'd almost certainly remove some old code (if only to replace it with shiny new code). There are performance implications for lots of regions though.
I'm all for losing those
I'm all for losing those items. Since Theme Settings API has been added these can be removed from core and the core themes can give a small demonstration of how to add theme settings. Has there been an issue created for this?
Shai, first, thanks very
Shai, first, thanks very much for posting this. There's quite a few different issues around at the moment which are trying to do this in one way or another.
Here's a list :)
http://drupal.org/node/231437 - Remove ping module from core(committed)http://drupal.org/node/228594 - UMN Usability: split access rules into an optional module
http://drupal.org/node/61285 - Remove poll module from core so that it can be developed in contrib
http://drupal.org/node/175841 - Remove comment controls for users
Not usability, but drupal.org/node/148849 would remove the node_comment_statistics table and replace it with a more generalised API.
Maybe move the code out but let the information in
When I think of something I want to do with drupal - usally someone allready did it or something similar.
Only problem there is: How to find the information / module / code.
So, just as an Idea, why not ask the user "What do you want your drupal to be" inside drupal and within drupal installation? This question could be seperated in a few main topics, some are allready in D6: Do you need another language than English?
Another one could be "Do you want to run a blog?" The answers could be something like.
There are following possible solutions:
* Use blog module + blog api + X
This way we could keep the functionality accessable for new users while getting functions out of code which alot of people don't need.
The Forum
I personally don't think the forum should be in core. I believe it should be removed so it can be community developed more easily - ie, the same reason you guys think Poll should be removed.
The forum module in core is known to be inefficient on high-load servers. It is also designed in such a way that it differs a lot from "normal" forum software (such as phpBB, vBulletin, FUD, SMF, etc) in terms of default design, usability and functionality (or at least in my experience this appeared to be true).
At the end of the day, you could easily install the forum module if you needed to... and quite a lot of sites that I've seen that are Drupal powered TEND to simple bridge to a 'known' forum (such as the ones listed earlier).
I also experienced people
I also experienced people complaining that the Drupal forum doesn't look like a forum and lacks typical features of forum software. On the other hand the forum is a vital part of drupal.org and moving the forum out of core would result in d.o being dependent on one more contrib module.
--
ramiro.org
I don't agree
I think forum needs to stay in core. If we strip too much out we risk having the backlash of Drupal not doing anything without contribs. Plus, if we move it to contrib it needs a maintainer. It's mostly me, merlinofchaos, and catch working on D7 forums. merlin doesn't need another contrib module to have to look after and I'm barely keeping up with the advforum queue as it is. I don't want the responsibility of all of forum on my shoulders alone.
Of course, a lot of this depends on how much we're allowed to do with forum in core. We've got some pretty radical plans to get past the boss man. If he vetos them, then I have a feeling advanced forum will end up being a core forum replacement rather than an add on like it is now. I'm already struggling to stick with my plan of not replacing forum in D5/D6 because there's only so much you can do in contrib. So we'll see how it goes in D7.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
Forum
Move Core forum out, or advanced forum in... Sure this would need work on advanced forum.
Life is a process
Life is a journey, not a destination