Missing Critical Blog Functionality

This is a good place to start: http://drupal.org/project/advanced_blog.

The problem has always been that Drupal is not good out of the box to provide the experience that people expect when you say "you can also keep a blog on the site" - most people expect the functionality of WordpresMU but they really get something more closely resembling a simple multiuser blog.

Putting some of this functionality into core or taking blogging out of core altogether and replacing it with well-supported modules in contrib would be great.

I have previously created an issue on something people may or may not be interested it: #470580: Allow multiple content types for user blogs.

Not sure if fields in core would obsolete that, but the thinking was that I was more than text content in my blog - polls, videos, images etc too, so they should be allowed to be added to a blog.

I'm so glad to see this is being addressed. At my organization, we just moved to using WordPress MU for our site's blogging solution because Drupal (even in contrib) lacked the blogging features that we needed. We're currently using a module to integrate the user table between Drupal and MU, but this is a hacky way of doing things, and I would love if it were no longer necessary.

At the most basic level, I think the usability of the node edit/submit forms needs to be improved - but Vertical Tabs goes a long way toward fixing that. Bloggers also expect a separation of site front-end and back-end which Drupal doesn't have by default. (Although Drupal can also be used as a wiki, in which case the lack of separation is a *good thing*.) Bloggers want to be able to add image thumbnails to their posts easily. ImageField doesn't really map to their idea of how this should work. Image module is better, but only when paired with something like Image Assist or Image Browser. Finally, bloggers expect a WYSIWYG editor: FCKeditor works great for this in Drupal, but is difficult to configure.

Contrib modules can get Drupal to be a basic blog solution, as outlined in the paragraph above. If you add in Views and Panels you have the ability to create any of the content displays (like archives) that bloggers are used to seeing, and more. However, they are not easy to configure by any means. I like the idea of an Advanced Blog module which has prebuilt Views, Panels, etc. which can be used by site admins without them having to fiddle with arguments, filters, and the like.

The reason my organization moved away from using Drupal as a blogging solution was really the underlying architecture of Drupal (permissions system, etc.), and so it would be hard to change. WordPress MU has out-of-the-box support for people creating individual blogs at which they have full permission to do everything that they need to do. In MU, it is very easy for end-users to install plugins (vs. the FTP, modules page, permissions page dance necessary in Drupal), manage themes (vs. the confusion of the Drupal themes page, and the fact that themes by default are site-wide), add widgets to their sidebars (vs. the end-user's nightmare that is the blocks page). Drupal is designed for users to have permission to administer the whole site, not subsections of it, and its admin screens (modules, themes, blocks) were designed for site admins, not end users. Drupal's admin screens are more powerful than those of WordPress, MovableType, etc., but are more confusing as a result.

I think that "blogging platform" is a specific enough use case for a Drupal site that it should probably be a distribution/install profile, rather than the core download. If Drupal 7.x core has blog-specific Views baked in to it, then people who don't need them will complain. On the other hand, if the Blog module is removed from 7.x core, and a Drupal 7 Blogging Platform install profile is featured prominently on Drupal.org, then the people in the wider Web community who are looking for a blogging platform will be happy, and the people (I'm thinking of developers and enterprise users especially) who are looking for Drupal as a "content management framework" will be happy too.

Some things should be in core, however, which would ultimately support use of Drupal as a blogging platform. The following, I believe, are already under consideration: 1) a plugin system for downloading new modules (cf. #395472: Plugin Manager in Core: Part 1 (backend)), 2) a WYSIWYG API & an editor (I prefer FCKeditor, but something like BUEdit should probably also be available), 3) an admin bar (like http://drupal.org/project/admin), 4) advanced help (i.e., HTML-based help & contextual popup help, cf. #299050: Help System - Master Patch), 5) usability improvements to admin/build/themes.

Critically, however, I think that Drupal will not be able to compete with WordPress/WordPress MU (which are merging code base) as an advanced blogging platform unless there is a system in place where people can create a new blog and then they have control over an entire subdomain or subdirectory of the site. That is, users with the appropriate permission should be able to click a "create blog" link, and then, after a confirmation screen, be taken to an admin interface where they have access to the functional equivalent of admin/users, admin/themes, admin/modules, admin/blocks, etc. but for a specific section of the site. This would require making a "watered-down" version of the blocks page where they could only adjust what was in certain regions (like the left & right sidebar). Previews of the blocks (possibly as modal dialogs) would be nice also. It would probably also require overhauling the permissions system so that people could be granted some administrative permissions on a per-subdomain or per-subdirectory basis.

The changes I have outlined in the previous two paragraphs would not be easy to implement, but I know that, at least in the case of my organization, we won't try using Drupal as a blogging platform again until something approximating them is in place.

I'm willing to help out in any way I can. My goal with Advanced Blog wasn't so much to replace Wordpress MU (which is great) but to make blogs community friendly. I run a gaming community site (http://aionelysium.com) and encourage members to blog about game experience. The problem with the default blog module is that these blog entries cannot be easily browsed. I think that beating out Wordpress in strictly the blog environment will be very difficult. Drupal's strength comes from the wide variety of things it does, and it's ability to handle massive communities. Wordpress provides a very nice "Everyone has their own little space" kind of mentality whereas Drupal provides the "We're a community producing content together."

"Wordpress provides a very nice 'Everyone has their own little space' kind of mentality whereas Drupal provides the 'We're a community producing content together.'"

That's it exactly! And it would be quite hard for Drupal to equal WordPress(MU)'s ability to give everyone their own blog to do with as they see fit, although I do think it would be possible.

I suppose your evaluation of Drupal's blogging capabilities really depends on whether you want a single multi-user blog, or multiple separate blogs. If you want a single multi-user blog, then Drupal can be better than WordPress since it has more sophisticated ACLs and since node content can be presented in so many different ways. (Whereas there is surprisingly no out-of-the-box way to get a view of posts from all bloggers in a WordPress MU install.)

In my organization's case, we ultimately saw aggregation of blog content as less important than giving users control over their own blogging space. It was our belief that many people will only blog on a platform that works the way they are used to working (the WordPress or MovableType way). But I can see how one might evaluate things differently. Elysium looks like a great community site, and I suspect it would take a good bit of hacking to get WordPress to integrate Elysium's social features as seamlessly.

Finally, I missed nbz's suggestion at #3 last time I posted (cf. #470580: Allow multiple content types for user blogs). Making Blog module more like Book module (in the sense that any node type could be added to a user's blog) would be a fairly easy improvement to make.

Dear Drupal Friends

The Drupal multiuser blog is a disappointment
when compared to wordpress mu.

First of all, it does not allow
each of all the individual users to have
multiple blogs with separate titles, themes etc

There is no autosave inbuilt and no easy way
to add categories by each user in his own blog.
A side block showing calendar which archives
monthwise posts are also missing.

Dear EvanDonovan

I do not know whether our experience
or wishes count.

The bad things about wordpress mu and
thus good things about Drupal are

Wordpress mu's separate admin end or
admin page is confusing.
Drupal is nice and useful.

Save button is always expected at the
bottom of textarea or at the top.
That is how it is in all apps and websites
in the net. Wordpress places it at
the side which is confusing - some users
doi not find it.

Otherwise wordpress offers all features
needed for blogging.

I believe the issue comes down to whether people want multi-user/community blogs or multiple customizable blogs. From my point of view, multiple customizable blogs are terrible for a community site because it ruin immersion and uniformity. Look at MySpace vs Facebook. MySpace allows you to do whatever terrible things you can think of to your page while Facebook holds you to a more uniform appearance. I have no doubt that this is a contributing factor in why Facebook is winning that battle.

Multiple customizable blogs would require something completely different. It's really more of an automated multi-site installation thing. From my understanding of Wordpress MU (it's been awhile since I've used it), that's how it works. You install Wordpress MU and the plugins you would like everyone to have. You can also allow users to have specialized themes and plugins for only their site. So, some things are shared, but a lot is not. This sounds a lot like a multi-site install of Drupal.

So, my opinion is that the functionality for users to have their own custom site/blog should not be lumped in with the blog module. It is more of a multi-site installation profile project.

The improvements I see needed for the core blog module are:

• Make it easier for people to browse blogs. The default of simply showing the latest entries doesn't allow people to follow particular authors or view a certain time period.
• Allow some customizability (probably with blocks) to display author info, description, etc.
• Navigation inside a blog, such as filtering by tag or date.
• Ajax auto-save.
• In general, make it easier for people to post content. Not so much a blog issue as it is a general administration issue.

Hi there.

I'm Joerg, but just call me Jay - the guy who is wearing the UX hat for that microproject.
as I am relatively new to the Drupal thing - though I'm member of this site since over a year - I do need all the help I can get from you.

To be honest with you all:
One reason I rejected a year ago to use Drupal for a project, that was
There was nothing out of the box in it for me to give me a start.
I was told that changed to the better... But I do read something other here in this thread.

I think in this phase for D7 we do have the chance to devolp something mind blowing.

My idea for this project's a bit of scalable thing that possibly is a bit out of scope for a microproject:
1) First of all there has to be a blogging tool as simple as Wordpress available in Drupal
- Create an article or page in WYSIWYG (CMS features)
- Tag or categorize (or both) an article or page
- Comments on articles or pages
- Different user roles (already in Drupal)
- Generate a valid RSS Feed or connect to e.g. Feedburner

That's kind of achievable - even now - but not out of the box!

2) Generate a collaborative blog (= team or project blog) in the same environment, where some users do have access that may differ from their role elsewhere

3) Enable an admin to make something of a personal or team blog a part of another team or project blog (with noticing the source)

4) Your ideas so far in the comments

Wordpress MU is the benchmark for our efforts - but I think we can do it better than that.
(Especially the last two features aren't possible in WP MU without copying and pasting)

other nice things to have
X) Contributing some assets from the web via email or embed (like in http://soup.io , http://posterous.com or http://tumblr.com)
X) Bookmarklet support - out of the box
X) Integration of Twitter, Facebook or Google
X) maybe establish a possibility to use WordPress Plugins even in Drupal

Please give me feedback - I'm brainstorming until tomorrow afternoon and then I think I'll start to work some of the UX magic.

Cheers, J

bangpound: Good points; don't have time to reply at length right now. If you want to check out WordPress's feature set, the easiest way would be to create a free account at WordPress.com.

Dear Bangpound,

For me the real difference or
shortcoming that Drupal has with wordpress mu
is that if there are 100 registered users in a site
wmu allows each of those hundreds to have
theoritically hundreds of blogs.
Drupal only allows one user one blog.

To me Drupal seems dead silent or
apathetic to this need and yet dreams
to conquer multiblogging world.

Feature or Userinterface - if any one
is missing the puzzle is incomplete.
And unusable.

In my experience, if I only need a blog, I use Wordpress. If I need multiple blogs for multiple people with the ability to customize, theme, etc., I'd use Wordpress MU. Making Drupal's blog module better ad making it behave more like Wordpress MU are two different things aimed at two different audiences. Wordpress MU is a very iche product aimed at a very specific audience. Drupal's goal is to be a simple, efficient, framework for one to build off.

If you are looking for the functionality to allow users to post to multiple blogs, simply use the taxonomy module and views. Want multiple authors for a single blog? Again, a view can easily provide that functionality.

User interface is very important, but things like WYSIWYG are on a larger scale than the blog module. WYSIWYG doesn't get built into the blog module, it gets built into the entire site. If we are seriously looking at functionality missing in the blog module, lets keep it to things that would be implemented in the blog module. Go big, throw out big ideas, but stay within the realm of the topic.

Dear Eidolon,

The objective of this project has
been said "feature set for blogs to ensure
a competitive offering"

If you need "multiple blogs for multiple people" you say 'I'd use Wordpress MU.'
If Drupal cannot make you say "I will use Drupal"
then forget about the 'competitive offering'

There is no blogging system that restricts users
to ability to create only one blog.
Look bloggers.com, wordpress etc
If you are speaking of 'Blog' module and not giving this
in a CMS forget about Blog.

"allow users to post to multiple blogs, simply use the taxonomy module and views."

This is not about posting to multiple blogs.
It is about users having ability to
create more than one blog whether he keeps those blank
or fill up with posts.

This is the is the very basics of a blogging system any
blogging site offers. If Drupal cannot help someone to make
a blogging site why they will use Drupal?

bangpound: You hit the nail on the head. I think the implementation of a blogging system is trivial. What we need is better UX.

I've set up multiblogging on a site just the way you describe. Each blog post belongs to a user (personal blog) or it can belong to a tag or to an additional taxonomy which I called 'blog projects'. If someone wants to create a multiuser blog on the website, I create a term and people post to that 'blog' by tagging it witht that taxonomy. So the implementation is easy if you have an admin and if you have the resources to train your users. But this experience taught me that the resulting UI goes against the expectations of users. This is what I've learned they want:

1. start a blog (give it a name, a description and a path)
2. have more than one blog for different occasions
3. allow some other people to post to that blog

All of the above can be resolved with taxonomy and some complicated block logic. But it does not allow for an easy to use UI that conforms to user expectations, i.e. there's a button to do all of the above. Instead it all just sort of happens and you have to do a lot of explaining. The Advanced Blog module seems to solve some of it but I haven't used it on a live site yet.

And no, MU is not a solution. I run a Drupal site for other functionality as well and want all the blogging content available as nodes to do all the other things nodes provide. Blogging is only a small part of it.

Would multi-user (and in group blogs) not be better done with other tools, such as organic groups? (or views with a selected taxonomy term - that would pull in all posts that get properly tagged.)

The core multiuser blog system is a multi single-user blog system and changing that may be possible, but that in itself is no a flaw as it is a design decision from where I stand. It will be useable for some people, not so usable for others. What it should do is allow the simple cases to be covered, be extendable to the not so simple and with the really complex be able to be put aside. It does that I think.

I don't want to get into implementation details

Sorry, but I think this actually matters. Going pie in the sky will mean that those with the skills to get things done will not do so as they will have already discounted the discussion. They could very well have better things to do.

I think the way Forum module uses its own vocabulary and brings that vocabulary's CRUD operations into the forum's admin context is an example of how it could be different.

It's an idea, but at the same time, the taxonomy matching all the blog posts already exists - the user who created it. Instead of a taxonomy, you could do with a simple checkbox like "promoted to front page", but instead it should be "show on my blog"

Dear Bangpound,

Can you solve this small
blog problem taking it as a nanoproject?

http://drupal.org/node/491140#comment-1700674

Basically, what happens is that
auth members having permission to view
revisions done in a blog post
cannot see the "revisions" tab -
so they are unaware of revisions.

Edited : Please ignore.
It seems to be a theming problem
where tabs get hidden.

hi there.

has anyone out there a typical drupal installation online with a blogging module and is willing to give me access?

I started to install it on my own server - but my capabilities as a techno-installing-guy are too lousy, I think.
(reminds me again at the saying: you gotta know where your strengths and your weaknesses are - but you'll always have to try ;) )

thx so much for your help

J

ps. if you don't want to post the data publicly
contact me via mail at hoheisel -at- gmail.com

@ronia

I would strongly agree with the point that one WPMU account can have an unlimited number of blogs. It would be a major boon for Drupal to allow a single user to create multiple instances of the same content type. Similar to one user having multiple blogs, it would also be beneficial for users to have multiple incoming blog feeds (if the site allows aggregation)

Currently Drupal's blog system (to the best of my knowledge) assigns the blog id according to the user's id (if the user id is 10, the blog id is 10.) Currently if I were to have more than one blog, I would have to create a new content type and re-create the same content fields that the blog module uses so that I can run more than one blog on the site. Unfortunately, that method doesn't work well on sites with multiple users (certain users may want only 2 blogs, others may want 6 blogs, etc..)

One way to implement multiple blogs for each user could be to add an extra 'level/layer' of ids for the content type (blog as in the content type and not individual articles:)
-A user's first blog could be assigned a prefix of '1' and the 200th blog connected to their user account could have a prefix of '200' so that if the user id of a user is 10, the blog id of their 200th blog could be blog/10-200 (or blog/10/200).
-If a users id is 50 and they do not create new blogs, the default blog id for the 50th user could be blog/50-1 or (blog/50/1/this-is-my-first-blog-post-on-my-first-blog)

@EvanDonovan

I'm glad vertical tabs (I forwarded the idea of using VTs for node forms) has been a benefit for making content entry more easier.

It has also been mentioned before on several threads that Drupal also needs to understand more than 2 states of publication for content. Currently Drupal has only published and un-published. There needs to be a way to allow more than one state of publication to be used eg. draft, passed first review, past second review, pending permission to publish, etc. Similar to how site administrators can assign content types with input filters (eg. if there are a 100 input formats available, a content type can be assigned a filter for only 5 of those formats,) content types can also be assigned 'published states.'

A Drupal site can have multiple states of publication available and each content type can have different set of publication 'filters.' A blog may need only 2 or 3 states (draft, ready to publish, published) while another content type such as a medical review may need multiple states such as draft/ready for review by junior user role/junior role says article needs more work/ready for review by a more senior user role/ready to publish/ published.

@SteveJB:

Multiple states of publication would be good. There's still a moderate field in the {node} table, so we could always add moderation back into core without any DB changes. Modules like Modr8 take care of it currently, but I think it's important enough that core should handle it.

@bohemicus:

Your 3-step blogging workflow is what most bloggers expect, I think, and it certainly isn't the way that Drupal's core blog module works. SteveJB's suggestion of adding a new "layer" to the blogging paths would mitigate the issue of Drupal's one-blog-per-user paradigm to a certain extent, but the paths would be pretty ugly still. I think most bloggers would want something like Pathauto, so that their blog(s) could have a 'nice' URL. Wonder if it would be possible for that to make it into core.

@Eidolon Night:
Maybe I'm reading the description of the issue differently than you are, but I saw it as being about critical features that are missing in Drupal core that are necessary for Drupal's blogging capabilities to be competitive. These features don't necessarily have to live in Blog.module, IMO. In fact, I don't necessarily think that Drupal core needs to have a Blog.module, especially now that Fields are in core, although bohemicus & bangpound's points about default paths and permissions make a good case for its continuing inclusion.

I don't believe that features like WYSIWYG are only necessary for blogging, or that they should be implemented in the Blog.module. But I do think we should talk about them here, since blogging is one of the main site uses which they would support.

Just to be more clear, what I meant by 'filters' (in retrospect, input format groups wasn't the best example) was a group of available publication/submission states.

One content type could have 6 publication states while another content type could have only 3 publication states and these publication states could be selected from a total of 7 or more publication states.

@bangpound

admin/content/node does have filters for content types. It could have an extra filter (date picker?) with a time range related to when it was set as published/unpublished.

I'm not too happy with using an interface pattern of radio buttons and drop downs to create filters for admin/content/node/ . I'd rather have a line of text with drop down menus. [] represents drop down menus in the following examples:

View [ all content ] by [ all users ] that are [ unpublished ] for the time period between x days to y days.
View [ blog posts ] by [ junior editors ] that are [ reviewed by manager ] for the time period between x days to y days.

While creating a filter of available content can be done with views, an improved filtering UI in admin/content/node/ can make content moderation much more easier without a content moderator needing to enter the views building UI and then individually editing each piece of content when the content moderator is looking to review specific content on sites with a significant amount of content.

One of the greatest setbacks even for a simple blog (at least for me) is showing categories in a block, with numbers of posts in each category.

First of all, throughout D5-D6, the supporting modules have changed from Taxonomy_DHTML to Taxonomy_Menu. What happens in D7-8 is anyone's guess.

Secondly, even with that it's just lots of work for such a simple thing as blog categories.

Of course, you might send me to a PHP snippet that works - but that's precisely the point - blog categories need to work out of the box, where the user creates categories, places the block in the layout, and starts writing posts and putting them in categories. How it should be done in the UI is a different matter (the less clicks, the better), of course.

Apart from easy categories, a blog should have, in order of importance:
- a customizable title, description and URL
- permissions to post to the blog
- different content types
- subscription options to individual blogs (including RSS links in the <link> elements in the <head>), including email (though Feedblitz can be used for email subscription for scalability)
- author info (similar to Author Pane, maybe)
- related posts

Dear Drupal Freinds,

Has there been any progress
with this microproject ?

I forgot to mention before that
a very vital function - Search
does not work with
blogs written in non-english Unicode

This pretty much excludes
Drupal from their usage scenario.

Other cms-es like Joomla, wordpress
has no problem.
See
http://drupal.org/node/178840

I also post this at forum
microproject page.

@EvanDonovan - I wholeheartedly agree with you in that Drupal core does not need to include a Blog module. A goal should be to create a powerful contribution that encapsulates blogging features.

Also, it might be better to build contributed pieces of blogging functionality then use the amazing Features project (http://drupal.org/project/features) to package them and make them easy to distribute to Drupal site operators.

Either way, I'd move towards moving domain-specific functionality (probably wrong term), like blogs, forums, etc to contributed projects and keep core the powerful node-based framework that it is.

@justageek:

At the risk of repeating myself, I'll say what I said in the Forum issue ([#488714-50): I have changed my mind a bit about this after Michelle's comments over there. She has been working in this space a lot longer than I have, and seems to have a good sense of where the core is moving at this point. Some sort of Blogging API module to hold things together might still be good in core, even if we take out the Blog content type.

For example, nbz's suggestion in #3 to make "blog" a property of nodes rather than its own content type (sort of like how in Drupal 6 and beyond, any node can be in the book outline) would probably be useful to have in core.

Just a heads up - I have a patch at #470580: Allow multiple content types for user blogs implementing multiple content types in the blog. reviews/help/test fixing etc is still required though.

Let's see what we can/should do in the next release cycle.

#233301-125: Remove blog module from core removed blog from core.

This is outdated issue.