Remove blog module from core

I can't agree more. It does not even serve a "hairy edge case implementation of the CMF" purpose like poll does.

OK. Presuming that this goes to contrib (which I personally think is a fine idea):

--we need to modify aggregator.module to remove the "Comment on this news item" functionality that ties in with blog module (if no longer in core, it no longer gets built-in interactions with other core modules).
-- CHANGELOG.txt entry.
-- it seems that at one point Blog API was dependent on permissions provided by blog.module, but that may have been solved for 6. I think there is some stuff hardcoded in BlogAPI that references what I assume to be blog module paths ('blog/'. $user->uid).

Edit: removed a couple of "presumably"'s. For some reason I had three in this post, which was at least two too many.

ah yes i think blogapi defaults to blog here and there, search for blog whole words only.

Keith Smith - all of those are good points.

Getting rid of hardcoding from blogapi, and the if (module_exists('blog')) in theme_aggregator_block_item() are both worthwhile in their own right. So I'll open separate issues for those and mark this as postponed.

I heard anecdotal evidence recently that people expected blog module to provide a framework for multi-user blogs expected of a community site and many single user blogs use the automatic linkifiers for personal sites as well.

Aggregator here: http://drupal.org/node/233407
Blog API here: http://drupal.org/node/233425

I also would like to note that removing modules from core is the kiss of death and many people do use blog module. Or at least so I hear.

sepeck:

// I also would like to note that removing modules from core is the kiss of death

blog.module has had 55 commits in two years, most of these have either been big string freeze cleanups or just enough bug fixing to keep it up with API changes. The only feature added to it in that time has been additional permissions (part of a general cleanup of permissions for all node modules). It's already dead in terms of development.

// I heard anecdotal evidence recently that people expected blog module to provide a framework for multi-user blogs expected of a community site and many single user blogs use the automatic linkifiers for personal sites as well.

OK anecdotal was the wrong word. This was a meeting with university staff evaluating Drupal modules for various internal and external projects - the university representatives asked 'how do you make Drupal more wordpress-like? blog module didn't really do it'. The original source of the question wasn't in the room, maybe 'second hand' would've been better but I didn't make it up ;)

// and many people do use blog module.

Including me (since 4.7), but I'd be quite happy downloading from contrib, even happier if it was a views plugin. It's an extra 30 seconds to install the module from contrib when I upgrade. However people who download core for their blog site and discover that blog module doesn't do human friendly urls, blogroll, weekly archives, trackbacks and wysiwyg will likely suffer slightly more disappointment.

I was readling the blog post http://www.gomediazine.com/tutorials/create-a-killer-band-site-in-drupal... a few minutes ago and found these unsolicited remarks, which really echo much of the sentiment behind this issue. Hopefully, the author will not mind if I paste those paragraphs below:

First of all don’t turn on the Blog Module that ships with Drupal unless you want multiple blogs that tie together. It activates more than one blog and allows the mixing of authors posts on the front page of your site. This is overkill for 99 percent of blogs and will likely confuse you. It works great if that’s what you want to set up. But if you want a common Wordpress style blog then you don’t need to turn that module on.

If you want a standard kind of blog then just use Drupal Stories. Stories are another content item, other than page, that comes with Drupal. Or create your own content item for your blog. You can turn on the ability to leave comments on any content item in Drupal and viola you have a blog. Sure there is more to it than that in order to add some common blog functionality, but that gets you started.

+1 to remove the blog module.

I also agree with catch that renaming the resulting contrib module, "multi-user blog" would be great.

I also agree that if it is kept in core it should be renamed "multi-user blog".

Subscribing..... There's a couple of things that the Blog module does that is helpful for people who use Blogs:

1. Creates a blog entry content type
2. Creates a handy block that lists latest blog posts
3. Gives users a list of their own blog posts at blog/%user

Of course, these could live in contrib, but they are handy for people who just want a simple blog without having to rely of contrib. If Blog module was enabled during the update from Drupal 6 to Drupal 7, we'd have to consider what to do in the upgrade path.

+1, I just think it needs to be implemented differently then it currently is

I'm for moving the blog module to contrib and renaming it multi-user blog. I think this would not only make core lighter but breathe some new life into the blog module. I recently had to create my own version of the blog module using views and a combo of other things because core didn't cut it. Moving the blog module to contrib would allow it to rely on other contrib modules.

+1 this makes sense, the "magical wordpress-likeness" enabler must come from personal_blog.(install)profile.

+1. We'd see a much more fully-featured implementation of blogs in contrib I think. I agree with RobLoach's comment that the upgrade path is a big issue here though...

@ catch - so, other then the disconnect between it's design as a multi-user blog instead of a single user blog, so what if there have only been 55 commits. What specific features have the masses been clamoring for that absolutely need to be added? It works very well as it currently is so I really must be missing something about how awful/evil it is.

I saw another issue which was all about changing the blog modules description to - multi-user blog. That seems to me a more reasonable step on something that many many sites use.

We want to slim down Drupal, make it smaller and have less CMS and more CMF. This is a step in that direction.

@dmitrig01 - 'we'? I don't know that there exists a 'we' consensus yet. I do understand that there are people who do want that, but fairly sure I don't agree with them yet. Their arguments haven't yet convinced me. It may very well be that I just don't understand their arguments so far presented.

See #12 for many of my same reasons why I like it where it is.

The blog module provides a built in tool that enables those who are not in the CMF crowd (me) to build sites more easily. I have heard that people can accomplish the same thing with a combination of other contributed modules but have yet to see a published recipe and those solutions relay on multiple contributed modules to accomplish. Contributed modules that are still not out of alpha release at this time either. Until the engine elements of Views is in core, I definitely don't see that either.

Well Dries has stated a few times that he'd welcome a 'single user blog' install profile in core - there's a start on this here: http://drupal.org/project/single_user_blog. If we had such a profile, then the blog.module as it is currently would very likely not be used. That's a big if at the moment, but I think there are real issues in terms of expectations when people see 'blog module' that an install profile could handle much better.

However I agree it'll be much nicer in many ways when the core of views is in core, in the same way blog module would be a lot nicer if it could depend on views for the query building and display, which it could if it's moved to contrib.

@ catch - there are a lot of things Dries has said he'd like to see. Some of them he gets to see, others get ignored. Blog module as it currently is would not be used for single user blogs sure. There still remains a use on multi-user blog sites. Ideally this install profile will show up one day. The engine elements of views as well at which time the discussion becomes more interesting.

In # 12, Rob mentions the issue regarding the upgrade path if blog.module were removed in d7. Is that a hard nut to crack? I think that is the only reason to keep blog.module in core.

Drupal is moving toward CCK and fields. @sepeck: It's not moving away from serving CMS needs. It's just the recipe to achieve many CMS use-cases is different now than it was when blog.module was developed. There is vast consensus within the community which supports the CCK revolution.

The challenge is that for folks new to creating sites with Drupal, CCK solutions require more modules and more steps to set-up. Let's face that challenge directly (installation profiles, docs, screencasts etc.).

Keeping around blog.module makes the important job of bringing people on to the "CCK way" harder. People end up having to unlearn stuff.

I have no problem with folks who want to continue to develop custom content modules "the old way". That is what contrib is for. If there is an itch, go ahead and scratch it. But core should really be setting an example. Core should model best practices and consensus philosophical approaches that the community has embraced..

I'll end where I started. How can we solve the migration issue if we remove blog.module from core come D7?

Shai

@ Shai - How can we change the 'blog' content type to a CCK style content type? How in this new world can we provide the tools that blog module provides people already?

People used the same argument on book module. Book module got it's content type changed to a cck style content type and expanded it's functionality so the "it's not a CCK style content type" is not a justifiable argument. I am intimately aware of the move to CCK style, but I would rather not at the expense of functionality that currently doesn't exist in core.

Of course, you all could be providing better arguments then mine but I think not. Most arguments are 'blog module is confusing to people wanting to set up single blog owners'. That is not blog modules purpose and that could easily be changed by changing the description. There is in fact an issue for it. That would solve that confusion and still provide a framework for multi-user blogs which are used on many sites.

You seem to be focusing on the content type of blog module, not the tools is provides for which there are no comparable existing tools in core. Until some portion of the views engine gets in I don't see it happening either.

I have better different question. How could we get a patch to convert the blog content type to CCK style for legacy content in similar way to how book module was converted? In this manner we continue the march towards CCK. When Views engine gets in, we have a launching point towards removing more logic from blog module but until then we maintain a legacy functionality that differentiates Drupal from many other CMS's.

@ sepeck: I agree that there are cool aspects of blog.module once you realize it is a multi-user blog module. You've noted that those functionalities are not in core. How does that justify it being in core? Contrib modules exist precisely to extend functionality of Drupal. The question is, "Why, now, in April, 2008 is blog.module in core?"

Questioning whether a particular module is in core is analogous to Drupal's commitment to being open to break APIs each major cycle. Drupal is committed to breaking APIs (despite the enormous amount of work it causes for people) because of its commitment to innovation and promoting a coherent, cruft-free code base.

To use the bicycle wheel metaphor: Core is the hub, project/Modules are the spokes. Each core module should have a clearly articulated explanation of how it contributes to the hub.

Shai

@ Shai, wrong question. It's already in core. It does what it does really well. So far I have not seen a compelling argument to remove it other then "some people don't like it and it's no longer pretty". It works. Yes, it does need to be updated to leverage the newer CCK technologies. But it still provides features that are used by a lot of people and organizations.

It's already in core. Why now do you want to take it out and remove/reduce the usability of Drupal as a CMS? You have stated in your justification to move Drupal more towards a CMF. Dries State of Drupal presentation survey clearly showed that 70% want CMS functionality while 30% want CMF. Removing Blog module reduces Drupal's CMS functionality unless there is an equivelent features replacement in core. At this time, there is not.

Moving blog to contributed modules is a death stroke for it. You and others have a philosophical desire to make thing elegant, I like elegant, I also like usable. Removing blog from core removes tools. Removing tools reduces functionality.

My suggestion is similar to book module approach. Convert the blog content type to CCK. This provides a migration path for existing blog module users and eases the transition.

If Views engine gets into core this iteration then more code could be reduced/removed but views engine getting into core is not a sure thing nor is it something that can be predicted as it depends on a lot of variables (time and resources of a limited number of people). If it views engine doesn't get in, then the blog module functionality will remain for the user base. If views engine does get in during the D7 cycle, then having the content type already be CCK style will ease the identification and removal of the other automation tools blog module provides. Everyone wins.

@sepeck. I totally agree that at the heart of this discussion is: "What is the right question to ask?"

I think the presumptive question should be "Why is it in?" not "Why should it be out?" And I don't think, "It's always been there" is a good enough response. Or even, "core can't do that right now without it" -- which is true for a gazillion things.

@sepeck, That said, I basically agree with what you wrote:

My suggestion is similar to book module approach. Convert the blog content type to CCK. This provides a migration path for existing blog module users and eases the transition.

If Views engine gets into core this iteration then more code could be reduced/removed ... If views engine does get in during the D7 cycle, then having the content type already be CCK style will ease the identification and removal of the other automation tools blog module provides. Everyone wins.

What I took out from your words was the, "if views engine doesn't get in..." I don't think deciding to remove blog.mdoule should be dependent on whether Views engine gets in to D7. Leaving blog.module in core makes it harder to see what the purpose of Drupal core is. It's confusing.

It especially makes it harder for developers just arriving at Drupal or evaluating Drupal. The Drupal old-timers know the history and know why it is in core. But, say, a java developer who has a limited amount of time to evaluate this whole Drupal buzz will just be confused by its presence. Drupal will come off as being less coherent to that person. The sooner the deletion of blog.module can be committed, the better.

@sepeck. In trying to understand your dim view of blog.module being in contrib, I think there is another relevant question, "How long does it take a newbie to Drupal to realize he/she must use contributed modules in order to build a web site?" I think the answer is under 10 minutes. Any review of Drupal mentions this, all the introductory docs mention this. I don't think Drupal's reliance on contrib is one of the harder parts to understand in the Drupal learning curve. Figuring out contrib module reliability/duplication etc. is a big deal, a challenge. But a lot of people are working on that right now in the d.o. group and elsewhere. I think we can assume they will make some progress.

I don't think this is a question of CMF vs. CMS. I think it is totally appropriate to add WYSIWYG and image handling into core. Aren't those more CMS than CMF functions? A vast amount of users desire Wysiwyg and use images in their sites. Having a centralized way to handle those functions would be fantastic. A multi-user blog? Shrug.

The disagreement here is about the purpose of core. It's about which is the right question to ask, "why is it in?" vs "why kick it out."

Is there a statement written anywhere about the purpose of core? That might help.

best,

Shai

@ Shai... my dim view? Historical reasons for a features existence are certainly a valid criteria for consideration of keeping them in my dim view. Because each core module that has been removed from core is dead. I use it and know people who use it and I know of several big sites that use it. It is, in my opinion, an important feature of Drupal core. A feature that is important to the Community part of Drupal.

Also, there is a better way to make it go away then just removing it.

People who like/want features in Drupal need to be involved early or people with visions make decisions that they disagree with and get told to 'live with it or get involved later' after the fact. I do not want to be told after the fact to lump it for something in core with the features I like and use because I wasn't involved in discussions like this.

The reason I think it should depend on views engine in core is because what it does for you (I use blog module for a single user blog) that in the absence of views can not be replicated unless you are a programmer. Views is just now arriving at an Alpha release for Drupal 6. Which means the features and functionality which I and others benefit and use today would potentially not be available for the next release. Unless such functionality was in core today in the form of an engine. This is 70% CMS part for which I tend to advocate for.

Also, merely removing it destroys a migration path (go use a contribute module is not a migration path I like as an answer) for the most part when it may be more elegant to just roll the features/capabilities into new technologies and eliminate it that way. Change blog type content to CCK style content.... Now all users content is CCK enabled. That means an entire content type is gone (the last non-cck content type in core I think). Site implementors happy, much good karma in the world of Drupaland. Elegantly migrated so what code exists for that special node type is now gone. Assuming views engine stuff gets in, the current blog hierarchy could be replicated with it as an available view in a multi-user blog type framework and / or a single user blog framework. This solves a couple of needs. It is a migration path forward for people using it. It serves as a set of built in views for people to leverage and it does not remove a feature that many sites currently use.

But we cannot assume the views engine stuff will get in. It might not. Life happens. People get busy, patches don't get reviews or maybe contributed. This happened once with CCK stuff.

So, summary. I am a voice. Just one. But without an opposing voice all those who talk like there is this 'assumption' of a real 'we' will act in a manner consistent with their vision. I don't disagree with the eventual vision of this 'we', I disagree with the proposed solution which is not elegant and does not solve things. It merely dumps them elsewhere.

_{note: I don't care about poll module, just like I didn't care about archive module. I do care about blog module. So if you are bored and looking for something else to pull feel free :)}

@Steve,

First, I don't think we are that far apart, actually.

Second, I wasn't careful enough with my words and I think you interpreted "dim view" in a way I didn't mean. I think you read "dim view" as "unenlightened perspective" (which is kind of hostile) -- whereas I meant it as "negative assessment." Words do have a life of their own. I'm sorry about that. One thing I love about Drupal is the tone of the conversations.

I challenge your assumption that because past dropped modules have died that future ones will also.

I think there advantages to slimming core earlier rather than later and you think the advantages of waiting outweigh the advantages of dropping. Both assessments are reasonable.

That's why I think that having a written statement on the mission of core would help sort this out.

best,

Shai

No offense taken.

We have that. mission and principles.
We disagree on where the line for determining 'slim' is. Also, I am somewhat jaded on the survivalability of a former core module that does not have a maintainer listed in maintainers.txt already.

OK, this is the opposite of the problem I'm having. I *need* the blog module, but it doesn't appear to have installed when I did the drupal installation via CPanel. It's not in my admin-->modules list and it doesn't appear as a content type that I can create. Where would I get the blog module, or if it's already there, how do I get it to show up in my admin-->modules and my create content areas?

@insite - this is a future development issue not a support issue. I suggest you try the forums or open a separate support issue.

Thanks sepeck. Sorry about that. Posted the ? in post installation.

subscribing.

+1 for removing blog from core.

I think with a lot of talk going to add CCK/Views into core, alot of "presentation" modules (mainly blog, forum and tracker) will not be used in the future.

While some have disagreed with me in the past, I do think we should remove modules from core when functionality has surpassed them. Why offer core modules when most (if not all drupal admins) run to get CCK and views and those modules can do it and offer more functionality.

It just seems to me that CCK/Views (I would add OG and Panels too, but thats me and not the majority) has changed drupal in a lot of ways. Lets add the "core" aspects of those modules to core, add a migration path from blog to new system, keep "blog" for one release as "legacy/deprecated" then remove on version 8.x.

I can understand that Dries and other core team members do not want to make core depend on contrib modules. But I don't think they should just see the core code and not the benefits of the contribs (ok I am wording this wrong).

Basically if Blog can be done better with contribs than with core, I don't see a problem with pointing drupal users to those modules as opposed to "yes drupal can do blogs with blog.module, but most users don't use it".

+1 for removing blog from core
+1 for changing module name to "multi-user blog" (if it retains its current feature set)

i'm in favor of allowing multiple node types in a blog, and i think it makes sense to support shared blogs in addition to the one-blog-per-user model. (it seems like single/multi user behavior could be changed at the module level settings, so a user is never "stuck" in one or the other.)

i am about to start working on a module that does the above, and provides users with a more wordpress-like blog experience. i'll use the concerns voiced in this discussion as a jumping-off point - is there anything else i should take into account before getting started designing this?

Generally, I'm -1 for removing modules for Core.

My main point is that core modules are testbed for new features implemented by core (Menu, FAPI, Batch API, etc.), and we require to test proof these new features as soon as possible in our development cycle without having to wait for contrib modules to do so. To take two examples from the D6 dev cycle:

• The poll module uncovered a critical bug in the FAPI AHAH implementation, that was fixed the very same day of the D6.0 release! (http://drupal.org/node/216515)
• On the other hand, the development of Views 2 uncovered critical bugs in D6 only several months later

So I would argue we need to have a handful of modules in Core that implement a representative subset of Core features.

I'm fine removing blog, forum, tracker, etc. from core if Views-like functionality (and I guess Custom Links functionality) gets into core and we can ship the default profile with a suitable replacement. Not before.

Having the .info file name it "Group blog" module and tweaking the description a bit, though, would be more intuitive for people. I'd definitely support that. :)

@michaek: before starting a module, you should look very carefully to see if what you're proposing can already be done by views, organic groups (and maybe pathauto, custom breadcrumbs etc.) - the main impetus for this issue is that most drupal admins can set up something similar to blog.module using the views UI within a few minutes - there's only a couple of bits that aren't covered (like links back to users' blogs from their posts etc.).

@Damien: while the core modules do indeed provide bug/test fodder in core - that's not why they were originally there - they were there to provide features that users want almost immediately when they download Drupal. At the moment, many of these features are provided better from contrib. An accurate description for poll module would be "not many people use this module, but damn has it found some weird fapi bugs" - it's not a great advertisement.

The main answer to this issue in particular is 'views in core' - then blog becomes a hook_breadcrumb, hook_link and hook_views_default_view (or whatever it's called now).

edit: crossposted with webchick, but yes, just like that (which is why this issue is 'postponed').

@catch: so I agree with webchick: ok to remove it, but only *after* some near feature-equivalent replacement got in.

@catch: agreed entirely. if the requirements that i gather for the potential module are met by existing modules, then i'll see no reason to go forward with it.

as long as views is in core, then there's no need for blog, forum, etc. so +1.

I would assume blog, forum, etc... would be removed if Views is integrated into D8.

-1 for removing it from core.

even if views gets into core, it would better to update teh module to use views than to remove it. Same with forums. Forums are an important piece of functionality for many community sites (as are group blogs/news) and removing them from core seems silly. If i wanted *just* a framework, then I'd be coding in CakePHP or CodeIgnitor.

It's not so much a "framework" as building modules in an abstract and "lego-like" way. There also seems to be a movement away from modules that define there own content type (blog, forum, event, etc...).

Most of blog can be duplicated via core and views. All one would have to do is create a view with the needed fields and filters; add an argument for the user id (if you only wanted that users blog entries to show); then set the sort criteria.

I realize that blog does a few other little things (like breadcrumbs and such). Maybe those other little pieces can be absorbed by the most relevant contrib module. If Views gets into D8, those extra little pieces could be placed there. This also has the benefit of that code being used throughout all of Drupal, not just tied to the blog module.

If Views does get into core, a simple sample 'view' could be shipped with core to provide a "blog view". This isn't a question of stripping Drupal of code, but refactoring it. The example I just described would just transfer the blog.module to a view.

The point is that being able to recreate "most" of the functionality by manually configuring and fiddling with several other modules is much different to getting "all" of the functionality by just enabling the blog module, ticking off some permissions and moving on with life. The difference is a few minutes vs. an hour or more. The reason I use drupal is to avoid work, not to create more.

This argument does not convince me when the blog module could just be enhanced to utilize new core functionality (i.e. views) or addressing deficiencies instead of being tossed by the wayside.

You have misinterpreted my post.

1. My proposal is based on Views actually getting into core

2. If Views does make it into core and can fully duplicate 'blog', shipping a 'blog' view should be an acceptable replacement for 'blog'

My point being is that with CCK/Views can duplicate most (if not all) of 'blog'. So if the overall consensus is to move in that direction, we should refactor old modules to this new system.

Changing from the current method to my new proposal would not have you fiddling with the system for hours if coded correctly. Having Drupal ship with a group of predefined views could make removing some of the modules trivial.

If Views does get in to core and Drupal does ship with the Views "core" in D8, The current setup could change to:

Current Setup:

Activate blog module

Proposed Setup:

Activate Views Core

Enable 'blog' view/Set 'blog' content type

As you can see this method is not as time consuming as you might have thought. It just requires two more options to be set (blog content type and enabling the actual view). We could even remove "Enabling the "blog" view" option if Drupal shipped with it enabled.

I hardly see this as taking hours to complete. Also, your comment about CakePHP and CodeIgnitor IMHO is poorly thought out. The above method could require no coding whatsoever.

I am not well versed in the little extra details that 'blog' ships with. Could someone better clarify some of the details that 'blog' does that cannot be duplicated by Views?

Thanks

Views has its overheads / resource consumption w.r.t shared hosting particularly.

Blog, or rather the multiuser blog, is a boon to many and used by many, many. It is a common term and easy to understand. As well as easy to implement. The site is ready for mutliple users with multiple individual blogs from its birth (installation)

Views is amazing but still geeky to many ( their voices unheard ?? )
A drupal installation by default gives wiki (book) and blogs (and other stuffs) which is amazing and easy. Thats how I got stuck to drupal.

At its present form drupal is sufficiently slim. If further 'slimmetry' is wanted ( is that the only reason why blog needs to get shifted ) drupal can be just user registration and login system with all other stuffs as non-core modules. There are some systems like this (?xoops, socialengine)

By removing blog from where it is, please do not kill
- the simplicity ( heardly understood by geeks )
- what is already in use by thousands
- normal expectancy
- easy backward compatibility ( have been using as core, now with upgrade I change to contrib ??? )

I understand and respect your POV, I just humbly disagree.

Of course all is this based on Views becoming a core module. If it doesn't then the status quo should remain the same. If not, and views does get into core, I think a further look into this would be beneficial.

Drupal itself caters to a "geeky" group. Most mainstream users that simply want a blog (or a MU blog) go to Wordpress, Wordpress-MU and Joomla. Of course, I am not saying that Drupal should become the "geeky" CMS; I do believe that one of Drupal's goals should be more mainstream acceptance. I just think it is a "Power User" CMS.

I realize that Views can take resources and overhead to run, but that is also dependent on the complexities of your page and block views. Surely a simple blog page would use next to nothing compared to views that require arguments and custom code to run properly.

I personally try to stay clear of modules like blog (as well as forum, book, etc...). I have no formal coding experience and those modules seem rather inflexible compared to CCK/Views. I also like to work at the lowest common denominator, meaning the minimal amount of code/modules active on my sites. If I am using Views I don't want to use another module. if Views can do 90% of the legwork, I use Views and either live without the other 10% or find a leaner module/code that can do it. So my way of looking at this, is to open those modules up and create a more abstract way of thinking about them.

I also realize that their is a group of Drupal admins that don't rush out to get CCK/Views during installation (it baffles me honestly, even some of my simple sites use Views). So I see this as a balance of power. Do we leave it as is, and maintain the status quo (simplicity and ease of use) or do we change it (more flexible and abstract)?

Nothing stops you ( or any 'geek'y users ) from using Views to 'blog' but it becomes difficult for the multitude of other users, whose 'ability' and 'needs' one is able to judge by looking at the forum posts :)
If the 'blog' module is removed completely one has no choice but to use views BUT if it is there, less geeky ones ( who abhor setting cck, views, filters, fiddling etc etc ) can pursue 'blog' normally while those who want can reject and do it with Views.

>> I realize that Views can take resources and overhead to run, but that is also dependent on the complexities of your page and block views.

There are certain blocks etc one cannot do without. Many sites having blog+forum can just do without views. For certain hosting env.s sply shared ones, too much dependency on Views can be a problem and cause unnecessary bad repute to drupal &/or Views - http://20bits.com/2007/02/27/4-problems-with-drupal/

>> those modules seem rather inflexible compared to CCK/Views
They are at certain points but at the same time they probably are not in certain cases. (eg. How do you allow bloggers to have their own headers and subheaders as well as privacy levels with just views ? )
Most flexible, slim system will be to have just user system+security and all else as module.

>> (it baffles me honestly, even some of my simple sites use Views).
This is nothing baffling, as most users want 'out-of-the-box' components (mainly wiki/book, forum, blog, album, groups, pm etc ) so that these are just ready AND they can concentrate on actual site content, design, and most important of all getting some users who will 'use/visit' the site :)

If we're going to refactor blog module to make it a default view when views gets into core, some of the multi user page title/link handling could live on in a tiny glue module, but I think for now this is probably won't fix.

@catch: Good Idea for now. For the last 5 or so posts, I was just going back and forth with no real goal other than to promote removing the blog module.

Let's take a chill pill and wait until Drupal 8 is actually in -dev.

Truce?!