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.

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.

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.

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.

@ 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. :)

@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 :)

@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?!

tagging

Just something to add here - if blog.module is not being removed - can it be improved to become more featureful?

When I asked about #470580: Allow multiple content types for user blogs on irc, the overwhelming majority of the response was "use views instead" instead of extending blog.module.

(admittedly, I have not been able to make that patch show green as there are some exceptions produced by simpletest.)

not sure if this was ever mentioned... for an actionable "smallcore" issue, go here: #537434: Drop the blog API from core

Blog in core is a nightmare cos it doesn't really do what people expect. I personally think it should be removed to contrib, in a kind of half-hearted "smallcore++" way. None of us will miss it, and if things like Features et al take off, packaging blog into a feature is simple enough.

The small core movement should not be taken lightly - if we can get Drupal to a position where core is small *but* we can present a new user with config options like "shop", "blog", "brochure site" and so on, this is a big step towards something really brilliant. EzPublish has been doing this for five years or so!

This also ties in nicely with points made by bmann about themes, of course. Win win win.

Pleeeaaase take blog out of core and just put a nice starting page there pointing to some sensible docs on d.o or something? Pweeeeez?

When I first started using drupal I setup my blog.

I enabled blog module, and all the chaos started. It just didn't do what I thought it would. I bet there are so many people in the same boat, and I can't think of any reason why I would ever use it again.

For my blog now I have a 'blog' content type which I setup manually, and all the posts are listed on the front page, /node. It works perfectly. If I wanted anything more than that I would install views.

No need for Blog module.

I'd be willing to help maintain a contrib blog_mu.module that has a dependency on views. I think we can re-apply the smallcore tag now that BlogAPI is gone.

#58: I would actually call it Blog module.
#59: Time for golden contrib? Dries?

Sub.

I second removing blog.module from core:

• It isn't what people think it is,
• You don't need it to do a "blog", just start writing "story" nodes,
• BlogAPI was removed, this shouldn't escape the hammer.

Take blog out of core +1
Golden contrib +1
Name it blog.module +1

I guess there should be some kind of semi-official category in modules (and themes too, maybe) that contrib devs can't assign to their own modules, called something like "core team endorsed". That way n00bs can go and look in, pull out what they need and the modules in there are the "recommended" contrib by the core team. Otherwise someone picking up Drupal who is not a dev will be totally stumped if there are no modules included, given the myriad of choice available these days... =/

I think that's what bangpound is pointing out, right?

If you delete the Story content type, how do you get it back?

There are way too many ifs in that issue. If Views is ported to Drupal 7, if features take off, if there are people willing to maintain and support distributions, etc.

On the other hand, Blog is a respectable part of Drupal core, it is well tested and allow core to "eat its own dog food", by actually using the API it provides.

I believe it is way to early to consider removing the Blog module from core, even if I agree that we need to do it at one point.

Postponed to Drupal 8.

> I think that's what bangpound is pointing out, right?

@greg.harvey That was my take on it. :)

> If you delete the Story content type, how do you get it back?

@gh0st25 This is an issue queue about removing blog module from core. Try the forums or #drupal-support in IRC or open a separate support issue. :)

I freaking DARE you to remove blog from core. And upload, forum, pol while you're at it. Go on. Go onnnn!

Smallcore folks should publish an attack plan for D8. It can't be scattered on comments to various issues.

Indeed. This is something that we're in the process of. Our basic philosophy is that today's Drupal is two pieces of software jammed into the same box: a modular PHP web framework, and a "product" for building out small group publishing and collaboration sites. At this point in Drupal's life the two work against each other: UX and functionality improvements to the 'product' are held back because no one wants to bloat up the framework, and the framework is held back because it has a very specific use-case (the 'default Drupal product') hard-coded into many of its nooks and crannies.

The #d7ux project ran into this in a big way: they never received a clear answer from us, the community, when they asked whether their UX and design improvements were intended for the Framework (and, thus, every product built on top of it), or the specific product that ships as Drupal Core. In most cases we said 'Both!' and it was a very difficult road for that team. In the end, UX improvements that would have made that product better didn't happen because they wouldn't work for other sites or products based on the Framework. At the same time, developers building rich web sites on top of the Framework already have to spend man-weeks on every project removing the features that the Drupal Product embeds into the Drupal Framework. It's a catch-22.

I agree wholeheartedly with Dries when he says that the 'canonical Drupal product' -- what non-developers see when they download Drupal, or what developers see when they say, "I'll poke around and see what this can do!" -- needs to have actual functionality, and needs to improve. Simply culling out all the modules we dislike and saying, "Ta-da!" will hurt that goal quite a bit. Having a multi-user blogging tool built into a community collaboration framework, for example, is an unambiguously good thing.

My goal is a future in which the 'Default Drupal Product' and the 'Drupal Framework' are available as separate downloads. Existing install profiles can be built on the Framework, and the 'Default Drupal Product' -- what we currently call core -- will simply be an install profile, automatically packaged up and bundled together with its dependencies. That's one of the reasons that #594704: Allow packaged install profiles on d.o to pull in code from other sources + sites is such an important issue, and the activity on it is encouraging.

All this rambling to say: Blog module should not be part of the Drupal Framework. But until we can separate the Product from the Framework (via #594704: Allow packaged install profiles on d.o to pull in code from other sources + sites), stripping modules like Blog out of core hurt the Product quite a bit. Once that piece is in place, though... it's hunting time.

While I disagree with smallcore and also do use this module, I do think it may be good to move it to contrib even for drupal 7 - I need slightly more features in it that are not going to be added in core (and using views is not an adequate replacement).

I want to allow multiple content types in a blog and the only way I can see this (pretty small) feature added is if the module got some tender loving in contrib.

For all the aysayers about this module - your problem is more one of naming rather than features - you expect a normal single user blog but get a multiple users personal blog setup.

Another option is to fork the module, but leave the current version in core for the meanwhile. if the contrib module takes off and gets the much needed feture(), for d8 kill the core blog module.

Would that be a better option?

Just to add, I do not like the "kill it dead" option that many seem to be advocating, nor am I a fan of smallcore - drupal core should IMO be working and useable out of the box for atleast some use cases., adaptable to others with only minor changes. Otherwise all you will be left with is a database abstraction layer and not much else.

Just to add, I do not like the "kill it dead" option that many seem to be advocating, nor am I a fan of smallcore - drupal core should IMO be working and useable out of the box for atleast some use cases.

Yes. And that is precisely what #smallcore advocates as well. We just think that making that 'out of box product' better without screwing over every other use case requires splitting out the underlying framework component so that the two are not tied together as tightly.

The goal is a win-win scenario, in which adding a useful widget to forum.module would not bloat up the framework, and major re-factoring in the framework wouldn't delay cosmetic improvements to the blogging module for a year.

I second eaton's point in #69 that we need to keep both goals in mind: making Drupal a better Framework and a better Product.

Hence moving blog module is a Drupal 8 issue in my mind.

Here's an idea for a transitional step that is easily possible for Drupal 7. How about moving blog.module, poll.module and forum.module from the main /modules directory to /profiles/default/modules? This will make them available to the default install profile (for end users) but hide their module listing cruft from experts/developers who want to roll their own.

I understand that this may not be ideal for experts who want to use these modules but it is a symbolic of Drupal core's transition to a framework with install profiles as the products built on top.

Am I crazy or does this also make sense to others?

@nbz

You are not a fan of smallcore because I think you are misunderstanding what it actually is. You say "drupal core should IMO be working and useable out of the box for atleast some use cases." Small core will achieve not only a completely workable and usable Drupal product, but it will make it allow for more than just "some use cases." It will allow for many completely workable and usable "use cases" or Drupal products.

a future in which the 'Default Drupal Product' and the 'Drupal Framework' are available as separate downloads

Yer, that.

I rather enjoyed today's little can-of-worms opening. Ahhh!

#73 sounds interesting....? ^^

It is very hard to have this discussion when we haven't decided WHAT SHOULD DRUPAL PRODUCT DO OUT OF THE BOX. If we can agree on a product, I think it will be easier to see along which lines to split various pieces. The current piecemeal approach currently isn't working. I can already hear it: "ZOMG, Drupal doesn't blog out of the box, I'm totally going to use WordPress".

As always, here's the wiki for *my* suggestion of a community site out of the box: http://groups.drupal.org/node/21013 --> instructions are there on how to suggest a different product (hence me stressing "my" suggestion - there hasn't been much feedback on what other kind of product Drupal should be out of the box).

What @rickvug above says is also very interesting, although I don't know about logistics there.

I think we may be confusing two issues: smallcore, which I see as a lightweight Drupal kernel and Drupal's out-of-the-box capabilities.

From experience with a variety of software firms, I feel that these goals may overlap slightly, but they're incompatible in the long run. And yet, both of these are important objectives for the future of Drupal.

Drupal needs to have a truly stripped-down kernel that's a framework for future applications like Open Atrium. The simpler it gets, the greater variety of applications that can be built with it. However, that's an issue that's utterly independent of usability.

Usability often depends on mental models, user interface, and all sorts of abstractions that lie upon the kernel in a software application. They're overhead, and they may even have a cost with regard to machine performance. In the long run, they're a different objective from small core.

By necessity, I see Drupal moving towards a separation of a core framework and a highly usable base install. Drupal's kernel should be an elegant framework that's wrapped in an elegant UI -- but that UI should be able to be tossed at the drop of a hat.

We've historically used the terms "Drupal core" to mean "default Drupal installation". We should stop: we're just confusing two very different needs with poor semantics.

Boris: I think the point is that we are never going to agree with what "the Drupal Product" should do out of the box, because there are many different Drupal products right now, all of them valid. The basic functionality community CMS that is the "canonical" product right now in many cases conflicts with other, completely valid Drupal products (including brochureware CMS, Intranet CMS, project management tool, developer app framework, etc.).

We need to make it easier for the Drupal platform to be more than the Drupal "core" product. That's a Drupal 8 task, though, and not really solvable for Drupal 7 at this point. For that reason, I'm also going to go -1 about removing blog module now... but separating the platform from the application needs to be a high-priority for Drupal 8.

You know, I really think that if we had a greater collection of *valuable* install profiles the path here would be all the more obvious. As I said before, ezpublish by default offers a selection of setup options when you first install. If we had such a collection (repeating: blog, shop, brochureware etc) then this would easily allow us to put in a step into the "product" installer that enables us to hook into a preferred set of install profiles and ask the person which one is closest to what they want to achieve. Downloading said profile(s) mid-install isn't a totally bad idea. If they're adequately generic then this solves this problem, and necessitates the separation of core and any "default" - the core is standalone, and the rest is an install profile.

Seems obvious to me, but I think it's the lack of product definition (ergo relevant install profiles) that's clouding the value of the separation a little.

I don't care about blog.module really, but I don't like it. I just felt like starting some trouble :) In any case, IMO this reflects back to what Adrian was saying a couple months back about putting more effort into install profiles in D7. Smallcore would propagate naturally from that activity I think. Could be wrong.

Moving them to profile/default/modules isn't an option - then you'd need to hack core to actually use them - and lots of sites actually use blog and forum modules (not seen poll so much).

Actually, modules installed there continue to work. However, it wouldn't change any of the dynamics of how long it takes to get improvements into blog module itself -- so it would be a purely symbolic move. Given the headaches that come with moving a module's directory around in CVS (anyone remember the great renaming in D5?) I'd say that we are best off keeping it in place for D7, building a potential alternative in core that focuses on minimal-dependency improvements that could be pushed back into core, and treat the 'Profile/Product versus Core/Framework' issue as a fundamental D8 issue.

You know, I really think that if we had a greater collection of *valuable* install profiles the path here would be all the more obvious

Agreed. And that's one of the reasons that the work dww and chad are doing in the install profile packaging issue linked above is important. When that system is in place, we can start producing 'shipping' profiles that people can download and install just as easily as Drupal core is installed today. It's one of the critical puzzle pieces.

Ugh, CVS. Shame. Albeit a symbolic move, it would be a good one. A bit of symbolism (e.g. a big fat arrow pointing towards install profiles and #smallcore by moving numerous optional modules to the default profiles directory) would be no bad thing, IMHO. Sure, it doesn't *change* anything, but it sets out intent.

moving them to profiles/default wouldn't make sense unless we had something like #555212: Install profile inheritance

unless other profiles can easily re-use them, either through packaging or whatever, it makes absolutely no sense to move them WITHIN the core repository to a place where they are not re-usable without modifying core.

this is really a d8 thing

Yes, there's something of a chicken and egg going around. We want to have more robust Drupal-derived applications/install profiles, but we can't until the Drupal CMS product stops getting in the way. There's no incentive for Drupal the CMS product to stop getting in the way until we have better distribution support on drupal.org. There's little incentive to improve distribution support on drupal.org until we have more robust Drupal-derived applications/install profiles. Whee!

The way to break that log jam is simply to say that we want all 3 to happen, so let's start making them happen now so that Drupal 8 can be the release where it all comes together solidly. Then we work on those 3 issues in parallel, knowing that we are creating both supply and demand at the same time. That is a tried-and-true approach. It just requires the collective will and vision to do so.

Why now do you want to take it out and remove/reduce the usability of Drupal as a CMS?

@sepeck, I don't see the connection. The blog module stands to benefit greatly by getting out of core and becoming a robust and popular contributed module or feature. What @nbz says is actually a good explanation as to why.

While I disagree with smallcore and also do use this module, I do think it may be good to move it to contrib even for drupal 7 - I need slightly more features in it that are not going to be added in core (and using views is not an adequate replacement).

I want to allow multiple content types in a blog and the only way I can see this (pretty small) feature added is if the module got some tender loving in contrib.

@modulist makes a good point, too, about conflating Drupal core with Drupal out-of-the-box. Right now, Drupal OOB is pretty much just Drupal core because install profiles suck from a usability standpoint. They're hard to make, hard to find, hard to understand, hard to implement for your average n00b or casual Drupal dabbler.

To me, the challenge is having a proper, usable, secure way to handle installation of extensions of functionality. That's a big challenge. But to me it beats trying to make core the distribution for everybody.

Imagine what Drupal would be like if you could, from within Drupal, browse recipes for various kinds of what we now call install profiles. You select a recipe and it then lilnks out to pull in features -- preconfigured bundles that are ready to go. From a usability standpoint, that's easy peasy to understand and for a non-technie to execute. From a development standpoint it's quite a bit of work. From a security standpoint, there's a lot to consider.

Let's face it: The "Drupal as a product" components that are in Drupal core pretty much suck as they are. Blogs, forums, comments need real TLC to get them to fit in today's web norms. They would all benefit from the freedom of contrib development status. Let's not strangle them in an effort to hang onto a concept that isn't working.

@Boris writes

I can already hear it: "ZOMG, Drupal doesn't blog out of the box, I'm totally going to use WordPress".

Wordpress is a Swiss Army Knife (or maybe a Leatherman) to Drupal's tool shop. Wordpress tries to do everything. Drupal sets out to do anything. That's a powerful distinction, imho.

@ laura s - I cannot recall a former core module removed that did not die upon removal. So I do not see moving it out of core as a benefit but as a way to kill it. It is simple, it works well without bells and whistles. Real people do use it even though it is not cool.

To the rest, if Drupal is not functional out of the box as a basic CMS then we all lose an audience (non-developers). One member of which is me. To those talking about install profiles where? I haven't seen many and people have been talking about them for 2 versions now. I understand that Drupal 7 has some wizards now, but they rely on core modules being there for them to work. As Boris said, until an end vision could be agreed on what Drupal will be it's kind of difficult to watch what us non-dev folks see as functionality being ripped out.

I see a lot of devs saying 'you could configure it like a, b, or c' but I don't remember (m)any of you ever coming back and supplying that documentation in a readable format for the handbooks (occasionally in your own blog or book, video, site people have to buy sure, here in the handbooks?). So just because 'someone could' doesn't mean that 'someone knowledgeable' will or that such functionality will be accessible to the masses.

IF functionality could be generated through such in Drupal 8 because some subset of views makes it in, then good, I am game. IF there could be a migration path in core for those people/communities that do and have used blog module despite the disdain I get when I mention I use it, then that might also be an avenue.

I will admit that I was alienated early on in the usability discussion by people telling me I didn't know what I was talking about or was wrong so I ended up opting out and taking my IT software deployment experience with me. I view what little I have seen of this smallcore movement as a rather elitist attempt to dump the broader functional CMS aspect of out of Drupal core. Granted, I may be missing something magical in the profile fairies lining up to contribute this back but am rather cynical in this regard at this point.

"install profiles suck from a usability standpoint. They're hard to make, hard to find, hard to understand, hard to implement for your average n00b or casual Drupal dabbler."

+10. Having currently worked on a profile at work, there needs to be an export tool of sorts for people to use. If you have a really large site and want to take its features and apply them on a new site, it takes awhile to script all that. For most its quicker to copy the codebase and database over (sans node data) and change some config values.

"Blogs, forums, comments need real TLC to get them to fit in today's web norms. They would all benefit from the freedom of contrib development status."

Agree here 110%. Being a developer, my instinct is to always hook in an external system like IPB and authenticate through Drupal so it feels like 1 application to the user (for a 'Forum'). When clients say "I want a blog!" and thats it, I'd rather setup WP instead of Drupal, because thats what they are expecting. It's just not complete enough to compete at that level for the features people are expecting, IMO, and perhaps they can benefit out in contrib.

"Wordpress is a Swiss Army Knife (or maybe a Leatherman) to Drupal's tool shop. Wordpress tries to do everything. Drupal sets out to do anything. That's a powerful distinction, imho."

Having used both WP and Drupal, this is very true. WP cannot do nearly the amount of things Drupal can without extensive work.

But anyway, that seems like a whole other topic.

@sepeck How are blogs so critical to Drupal as a CMS, when CCK is in core already? Even people creating sites with blogs very frequently do it without the blog module. So what does the blog module do that's so golden? Most of the sites we build can be considered community sites in some way, but that does not mean blogs as in how Drupal blog.module conceives of blogs. It means blogs like Wordpress is. And I don't think we want to plop Wordpress into Drupal core.

And let's look at other candidates: Forums are far too simplistic. Only long-time Drupal users are even comfortable with Drupal forums. They have none of the features that forums software has had since 2000! So why continue to smother forums within Drupal core, when they can really come alive outside of it.

Comments also suffer in core. Hard-coded presentation features that make them okay, but not rockin.

And with thousands of modules in contrib, I don't see such commonly demanded features just disappearing because they aren't stagnating in core.

I see smallcore as a way of making Drupal more useful, more powerful. The objections you raise seem to be about how to make install profiles or features (as in http://drupal.org/project/features) easier to manage and use. And that's a different challenge, and more critical, because even with all these features in core now, everyone building a Drupal site needs more, and Drupal will benefit from usable ways to get that "more" that don't require Drush.

Install profiles are modules in drupal 7.

you know how every site you write has a special glue code module that it needs to make it your site?
that is your install profile now. rename it, place it in profiles/$profiles , and you are done.

As for exporting settings, look at the features module. install profiles act as containers for features (or other modules, but whatever), so all your install profile reeaally needs to do is turn on specific features during it's hook_install.

Drush and drush make are a simple mechanism to turn install profiles into complete packages that can be downloaded.
see #594704: Allow packaged install profiles on d.o to pull in code from other sources + sites

Now this could be done on Drupal.org, or done on the client side (which is how most developers are going to end up using it). The issue i linked to is basically what is stopping packaged install profiles to be actually useful.

All this code already exists, and is working today. It will continue to evolve and get more powerful in contrib during the D7 life cycle.

So when D8 opens up, we can start re-organizing things to take advantage of all of this existing functionality.

From Crell: "The basic functionality community CMS that is the "canonical" product right now in many cases conflicts with other, completely valid Drupal products (including brochureware CMS, Intranet CMS, project management tool, developer app framework, etc.)."

My argument is that the canonical product certainly _doesn't do anything out of the box_ (no roles, no multiple content types, no profiles, no images, etc.). Let's -- for starters -- pick ONE DIRECTION that it should do out of the box, and see what supporting trappings we have to have to make it do that one direction well and completely.

Yes, we are at chicken and egg. In the meantime, the "out of the box" experience is not great (what does it do? what should it do? what is this bag of settings page that I'm looking at?). Again, I just can't believe that no one on the design/UX side actually cares about his.

Contrast: oh, it's a multi user community with profiles, a blog per user, articles w/images that can get approved for the front page by editors, and even pretty decent support for a basic site gallery. Neat, WP doesn't do that out of the box!

@ laura s - See previous

It is simple, it works well without bells and whistles. Real people do use it even though it is not cool.

. Blog module means blog module. I do not care about wordpress definition. I don't and it's not relevant in the Drupal context of historical use of the Drupal blog module.

See my previous comment in the thread. Where is my replacement functionality? (oh, I have to build it by hand, add some contrib modules, when something many people use now is automatically created. see comment about dev talk but no doc show up) Where is my migration path? Blog module was a multi-user blog feature for a Drupal community based site. Doesn't say anything about wordpress or a single user blog. I mentioned earlier, before moving it out, a desire to have something to replace it in core. If that was a views subset and profile all good.

This thread is about blog module in core. You want to take other stuff out please do so in a different thread. The 'profile' solution people talk about doesn't exist. It's imaginary.

Besides, we already hit freeze. You all want it out? Take it out in v8 when we get some of this other stuffed ironed out.

And remember, the design / ui group alienated a lot of people who opted out of participation.

This is a really important discussion - great points... on both/all sides.

Okay, if we can't get blog.module out of core for D7, can we at least re-name it to "Multi-User Blog" as its human-readable name?

We are keeping blog in because it's part of Drupal's out-of-the-box "product" for people who need a product without much fussing. But as it is now, I think blog.module makes Drupal a much worse product:

1. It takes a much longer time for new users to realize they have a blog without the blog module and therefore
2. it wastes people's time and
3. it slows people down in learning what a content-type is, a node is, how Drupal works.

In other words, if we look at Drupal dabblers and desire them to become site-builders, blog.module interjects a "developmental delay" in that process (using that term as an analogy to child psych).

Is it a right-of-passage that we are thrusting on new users? "Oh, yah, everybody has to pass through the ritual of learning that blog.module gets in the way of running their single-user blog." That's not welcoming and it seems antithetical to both the "product" and the "framework."

Shai

This thread is about blog module in core. You want to take other stuff out please do so in a different thread. The 'profile' solution people talk about doesn't exist. It's imaginary.

of course it does, look at open atrium.

@sepeck:

The 'profile' solution people talk about doesn't exist. It's imaginary.

See @adrian #90.

See features/ctools solutions.

Not imaginary, but maybe takes some imagination to let go of legacy thinking. Maybe D7 is too soon, especially in this slush. But by D8? Plenty of time! (As of many comments ago, the issue has been at "postponed" status, btw.)

@boris:

I just can't believe that no one on the design/UX side actually cares about his.

I care. That's why I'm here.

Contrast: oh, it's a multi user community with profiles, a blog per user, articles w/images that can get approved for the front page by editors, and even pretty decent support for a basic site gallery. Neat, WP doesn't do that out of the box!

That solves one case. And otherwise gets in the way of umpteen other use cases. The web is changing so fast, I strongly feel that Drupal makes a mistake by building out core in one 5-year-old community site paradigm. Instead of hanging onto outmoded modules, I feel the Drupal community gains advantage by building up the flexibility and extensibility in terms of usability and power. Then watch Drupal take over. Or at least propagate like never seen before.

We are not removing Blog module from core in Drupal 7. There is no viable replacement, and "golden contrib" is a myth, at least currently.

However, we have 7 days left until 'for real' code freeze, several high-impact exceptions that are still not RTBC, and a variety of API clean-up patches for which we're at the "now or D8" stage.

Despite this, there were over 50 replies to this issue today.

Folks, could we please focus a little bit? :P

@ laura s - where on drupal.org is a profile with blog module equivalent configuration? Please do not dismiss me as 'legacy thinking for things that are not mature enough yet. Replacing something that currently 'just works' as is with something imaginary is fail.

@ adrian - where on drupal.org is the documentation/recipe on how to configure such? Drush requires shell access which is not available on all systems.

Myth, does not exist. I am well aware of those 'alternatives and they are not documented or used/understood by more then 5% of the community at this point so until that changes the poor new to Drupal person will just be confused. I sure couldn't do a multi-user blog with contrib modules and cck and I've been using Drupal for years.

Please return to this issue after D8 is out the door.

@sepeck "That solves one case. And otherwise gets in the way of umpteen other use cases. The web is changing so fast, I strongly feel that Drupal makes a mistake by building out core in one 5-year-old community site paradigm"

We actual agree :P Hence, small core, and shipping with N profiles that do different things.

BUT, default.profile, IMNSHO, *has* to _do_ something, and thus be aimed at something, out of the box. That is my suggestion. If you have a different suggestion for a simple feature set that exercises / shows off some of the capabilities of Drupal, please suggest them http://groups.drupal.org/node/21013

People onboard with Drupal (at one use case) by installing the default instance and using it out of the box. That's where the non-developer learning curve starts. What face do we want to show those users? Or do we not care about them at all anymore? If we don't, let me know, and I'll shut up and go focus on third party install profiles.

some short thoughts (i'm a themer not a programmer):

- i'm searching for generic solutions -> so remove blog from core -> or like mentioned before: move it for beginners to an cck type

- i need the standard stuff of weblog functionality in drupal -> so implement it in an generic way (for example comment notifications with actions and trigger)

- i want oop (it's a must for me to get professional developers - now a lot of them say to me: chaotic base system and we have php5 since years)

- drupal only as a framework -> no that's the wrong way - i need an cms and i think the popularity of drupal came by this fact

- a new other named or a current framework (zend, cake etc.) as base of drupal -> yes - maybe the solution for the smallcore people

- i'm not a programmer, but i'm into php a little bit -> i need more granular template variables -> i want to print a comments list seperate from the comments form - i don't want an override for this: i only want to print: comments_list and comments_form seperate

- i need a better documentation -> this is the most urgend thing for the drupal community -> kick out modules without a good documentation

- and important -> don't tell people that drupal will ever be out of the box functionality - i don't want a joomla system but a professional cms with professional features like oop, an excellent theming engine, good documentation and only a few core developers (paid ones by an strong institution like the beginning of linux)

In conclusion:

1. Blog module is not going anywhere in D7.
2. Boris is right (and has been since 2004).
3. Everyone wants something useful when they download Drupal.
4. In the near future, install profile packaging will make it possible to satisfy those people while maintaining a smaller framework.
5. Until that capability is in place, culling core modules is a mistake.

"drupal only as a framework -> no that's the wrong way"

I think of Drupal as a framework actually. I don't feel stuck in a box when I install it, much like I have with WP or other systems. If something doesn't exist, I bring up the API and get down to it. Of course I am a a developer, not a themer though.

"a new other named or a current framework (zend, cake etc.)"

Would disagree here.. that would mean the entire community would need to learn this as well in order to contribute. My guess is it would cut off a lot of contributors pretty quick.

One of the biggest things about Drupal is its not a part of something like Cake, CodeIgniter, Zend etc. It allows, right from the start, anyone familiar with PHP to begin changing the system or extending it without learning a framework AND the application API. Not to mention if the framework changed, Drupal codebase may be affected, etc etc etc. In my opinion keeping it simple has allowed folks who aren't hardcore programmers to contribute, thus in turn, others pick up and add on to it too.

Why do you say 'OOP is a professional feature' when you reiterated that you are a themer not a programmer?

The heart of the discussion seems settled for the moment. I wanted to reply to @sepeck:

where on drupal.org is a profile with blog module equivalent configuration? Please do not dismiss me as 'legacy thinking for things that are not mature enough yet. Replacing something that currently 'just works' as is with something imaginary is fail.

I wasn't saying you're "legacy thinking" but that the core structures when it comes to blog module (and some others) truly are manifestations of legacy thinking, unchanged and unchanging in core. No offense was intended.

What I'm saying is that Drupal is exceptional, but blog module is one area where the current approach, which is pretty much unchanged in the 5 years I've been working with Drupal, does not generally suffice for what people want when they say "blog". (What's more, blogs are not part of every Drupal project. I wonder if they're even in a majority of Drupal sites.) There's also the confusion factor. As noted above, a single-user site owner would not want to use blog module, and would only be confused by a module that really is just a pre-made content type with a built-in, taxonomy-like river-of-news viewing structure, that's all. That person would be better off defining a new content type and using Views. And all the other bloggy stuff people want -- from wysiwyg to social bookmarking to retweet/digg widgets to embedding images -- they will have to hunt down, download or checkout, install and configure.

And it's that last part that's the crux of the issue, I feel. It's the extendability of core that needs the love, rather than protectionism about blog module. And yes, we're just at the beginning and pushing for this in D7 was too early. But Drupal's great power in flexibility and extensibility can become more accessible and powerful with a shift towards a small, lightweight core that provides tools for structuring (taxonomy, users, permissioning, nodes, files management...), combined with a usable, easily manageable ways to extend and enable added functionalities from contrib. I am extremely excited about the excitement about smallcore. The fact that some of the sharpest people in this community are focused on it gives me great comfort and inspiration.

And yes, with open issues for D7 still demanding attention, all the focus here may seem out of place. But for a project without roadmaps, pseudo-roadmaps for the next Drupal release tend to appear and start to solidify early. People aren't buzzing about smallcore because it's not relevant, but because it is. And it will take time. And sometimes, just sometimes, long threads like this are important hashings out of ideas.

I expect there will be many blog posts about this. (Apt or ironic, that?) I'll shut up here now (yay!) and move my discussion into that arena.

@ laura s -

but that the core structures when it comes to blog module (and some others) truly are manifestations of legacy thinking, unchanged and unchanging in core. No offense was intended.

But I am not thinking that or saying that. You and the others are proposing to just remove it with what I view are not acceptable methods.

#53 - We have Niklp adding this weird begging chastising rant of just 'take it out' because #smallcore rules all and some documentation fairy will solve that. Smallcore being something many have not heard of and per planet posts seems rather divided and confused on it's goals and missions so it's advocates are merely confusing people now.

People then jumped on this remove bandwagon to remove features that leave users in the cold. It sort of wanders all over the place with the claim that 'no one uses it', 'it's to basic', 'it makes things _hard_', whatever. People are not reading the thread.

Please refer back to my posts #23, #25, and #27 of April 2008. Give users a path to convert their data from the then 'blog' content type (which is now a cck type content) and the ability to achieve the existing functionality in core with something like a views lite or configuration wizard (whatever) and blog module itself can go away (the user seen description change was already addressed).

In the meantime, developers can discuss the purity of a framework(CMF) and I will continue to argue for the equivalent functionality of a useful CMS out of core. Especially a feature I happen to use. My goals may not be yours but they will meet somewhere and that hopefully will result in something better.

Anyway, back to D7 testing push.

Smallcore being something many have not heard of and per planet posts seems rather divided and confused on it's goals and missions so it's advocates are merely confusing people now... People then jumped on this remove bandwagon to remove features that leave users in the cold. It sort of wanders all over the place with the claim that 'no one uses it', 'it's to basic', 'it makes things _hard_', whatever. People are not reading the thread.

Please note that this thread was started over a year and a half ago: it's not a sudden impulse-request by a couple of rabble-rousers. Also, please note that the folks principally involved in smallcore are arguing that blog module should not be removed until better alternatives are actually in place. There are no 'magic documentation fairies' needed.

We agree with you.

Full stop.

We agree.

Thank you. :-)

We may now return to our regularly scheduled Drupal 7 testing.

@sepeck (et al) Please feel free at any point to refer to the first few words of para. 3 of #81. I reopened this thread because I wanted some fight. I can refer you to a higher point of blame if you like, but I'm happy to take the rap. I got the fight - screw my initial point if we're making progress. @eaton, @adrianroussow and others have filled the gaps in my knowledge as eloquently as I had hoped they would.

@NickLP - Yes. You have succeeded in lowering my opinion of anything I read from you from now on.

Why thank you. You could at least do me the service of spelling my name correctly, though. I take it then that you also consider the rest of the conversation fruitless, given that it was my intention to create such an effect? I thought it turned out rather well...

PS "Pobody's nerfect"

http://buytaert.net/8-steps-for-drupal-8 let's stop saying smallcore.

I vote for Views in core. Tell me a drupal site that doesn't use Views...
but I never used blog module.

Another option would be to get the features of blog, forum and tracker into a unified flag module (or just an update to the tracker module that does that).

Another option would be to decide what functionality should actually be in core -- IMO we need to stop focusing on eliminating existing core modules or absorbing existing contrib modules, and tackle the tougher question: what functionality should be provided by core out-of-box, and what is reasonable to leave in contrib modules?

"what functionality should be provided by core out-of-box, and what is reasonable to leave in contrib modules?" hey @eaton, you're starting to steal my D7 cycle quotes :P

Nuke.

Sorry that was 7.x

That's a no-brainer too. Top reasons:

• Bojhan: I feel even for the core "use-cases" this not a justifiable feature, the UX is worse than perceived because its hard to figure out what it actually does for you.
• chx: Was there a time, ever, when someone wanted to host a multiuser blog based on this module? That's a good joke. This module buys us extremely little. You can move it contrib, it will die but noone will cry over it.

Bring the axe, please.

I'm pro-removal of blog, so much that I noted Dave Reid's creation of a blog contrib project and added myself to the maintainers list. Unless someone tracks me down in the next day or two to stop me, will probably copy blog 6.x and 7.x to the contrib side along with looking at re-assigning some open issues from core to contrib. There you go #97.

I'm not at DrupalCon to do this as part of an on-site sprint.

Re #12 and other commentary about the value of this module, I think speaks to the need for an improvement to the module search and installation process. If you could browse popular modules in contrib from your Drupal site, which don't come included in the .tgz, and then could install them without having to do extra chmodding, ftp, or sftp config, then that's the vision I see for the how to get this kind of functionality as part of an install profile.

Drupal needs to reach out from the installation to grab what the admins needs; `apt-get install blog` if you will, except without the drush, terminal interface from 1985.

Anyway, I'm clouding the issue. My main point is I'm throwing myself in as a blog maintainer.

Committed to 8.x. Bye, bye blog module. :-)

I'm marking this 'needs work' because:

1. We should add an entry to CHANGELOG.txt (also for profile module).
2. We should check MAINTAINERS.txt
3. There are references to blog module left in API documentation, it seems.

Let's make sure to follow-up with more blog module clean-up.

I don't think this version is perfect either, but it picks up some things missed in catch's version and it uses real code examples.

I use blog module.

@kattekrab The module has been moved to contrib in D8. The same thing was done with blogapi and other modules did during the D7 dev cycle.

Committed to 8.x. Marking 'fixed' now.

Switching this back to RTBC, as this isn't showing up in the commit log.

@Dries please "git push" :)

Kill! kill! kill!

Are you sure I didn't push this yet? It looks pushed to me.

I just git pulled and no longer see 'blog' when I ls, and the CHANGELOG.txt entry is there.

Marking fixed. It might've gone in in another commit. Sorry, Dries! :\

Unless I missed it, doesn't this still need a change notice? http://drupal.org/node/add/changenotice

And since adding that summary is relatively easy, tagging as Novice.

http://drupal.org/node/1294420