Blog administration and control for media site

tsvenson's picture


I am working on a media site that will have a number of blogs. I have gone over every discussion in the Multi-user Blogging group as well as the last two years posts in Newspapers on Drupal.

Although I have tested many of the modules and techniques I found, there are a few things I haven't been able to find solutions to.

The main thing I found is that multi-user blogging seems to be geared at making it available for any user with a certain role to be able to create a blog. This is something we want to avoid since it needs to be controlled by admin and/or editorial staff.

Basic requirement for the blogs are:

  1. No user can create a new blog, only be authorized to post to one created by admin/editorial staff.
  2. One user can post to multiple blogs.
  3. Any one blog can have multiple users posting to it.
  4. No user can edit surrounding info on the blog home page without special permission. They can only create new blog posts and optionally edit old posts they are the author of.

We also want to be able to present the blogs based on topic, such as using URL's like:

  • "/blogs" - Overview page of available blogs where we control the layout and presentation (Panels will be great for this)
  • "/blogs/[blog topic]" - The blog home page with description of the blog, info about author(s), latest posts, blog roll, feed and so on.
  • "/blogs/[blog topic]/[blog post]" - Individual blog posts with optional comments.

From what I have found so far, the Own term module can be used to sort out item 2 & 3 so that is a good start.

The biggest issue though seems to be to be able to control who gets access to post in blogs and at the same time make administration simple. I have looked at a whole bunch of access control modules, including Taxonomy Access Control, TAC Lite and Nodeaccess. They are all great modules, but in our taste they do add a quite complicated layer when it comes to administration that will only grow as we add new sections and features to the site.

Optimal would be if we can have a Blogger role and then for each user having that role give them individual permission for which of the blogs they can post to based on the requirements above.

I would be really grateful if anyone has any experience creating a Drupal site with similar requirements for blogging could give me some tips and advices on how you solved it.

Happy new year,


Taxaonomy Access Control

morisy's picture

I know you mentioned you looked at it, but I really think Taxonomy Access Control is the way to go. As far as I can tell, you can do everything you wan with it, without adding in the Own term module. I believe this is how does it, for example:

Unless they've changed it since my day. It also allows easy cross-posting if you want to enable it, or not.

What specific complications are you running into?

Web guy,
Twitter: @morisy / @sparechangenews

Taxonomy Access Control

tsvenson's picture

Hi morisy,

I did take a look at TAC, but when I read the "Good to know" part about that permissions for users with more than one role works "OR-ed", then it ruled it out.

T: @tsvenson | S:

"Moderated" Blogs

Mike Wacker's picture

Chris Barnes abandoned TAC a long time ago; it had a strange tendency to 404 our front page, and I don't think we had that many use cases for it by the time we got rid of it.

One interesting approach may be to allow users to create blog post, but to set the moderate flag on those posts. They won't go up on the front site until someone on the editorial side approves them, and they can also properly tag/categorize the blogs as well before approving them.

Hi Mike, A couple of things I

tsvenson's picture

Hi Mike,

A couple of things I have learned during this plus one year I have "experimented" while learning Drupal is to be very careful when selecting contrib modules to use. Particularly when it comes to modules that has a sitewide effect. Unless a sitewide effect, such as CCK, Workflow, etc is what we want, I try very hard to avoid them (isolating the problem) as they generally will add to the administration and complexity as the site grows.

In the selection process I of course do review the issue queue as well as estimating how active the development and maintenance of the module is. Then if I still find the module interesting I subscribe on the whole issue queue. I have found that subscribing on the issue queue has been very effective for me. If I start to receive a flood of issue emails for a particular module it alerts me to check what is going on to see if it might be something that is affecting my sites, or if I can do something to help. It saves me a lot of time that I instead can use more effectively for other things.

I have been thinking about how to moderate blogs in the best way, including using Workflow and so on. In the end I decided to use a reader moderated approach. That is, readers of the blogs can use a feature to report a blog post to us and we then take action on that. For other content we will in most cases use a workflow.

The reason for this is the way everyone differentiate blogs from for example editorial content. A blog is often a list of personal opinion posts triggered by the "spur of the moment". Both the blogger and the readers want them published and readable instantly. Also, readers accept that a blog post is not 100% fact checked and correct, as they do expect from an editorial article. Having the moderation delay will, in my opinion, have a counter productive effect and only put of the bloggers from posting.

When it comes to proof reading, tagging and so on I see it as our, the site owners, task to "educate" the bloggers about this. The better guidelines we give them, the less moderation and administration we end up with as well.

At least that is my take on it.

T: @tsvenson | S:

Custom blogs

Michelle's picture

If you use a custom blog solution rather than the blog module, you have more control. Make a "blog topic" type that only admins can create. They create the node and assign the desired user as the author. Make a "blog post" type that member of the "can blog" role can create. Link it to the "blog" node via node access.

Then you can get the paths you want via pathauto by filling out the option for each type.


Hi Michelle, That is an

tsvenson's picture

Hi Michelle,

That is an alternative I have been thinking about as well. From what I understand there isn't really much difference between a Story CT and a Blog CT (from the Blog module), or is it?

I have tried to find more information about exactly what it is that the Blog/Blog API modules offers more compared to creating my own custom content types. I have read the Blog Handbook but can't find much more than the "Blog it" link, which modules such as AddThis is a better alternative for, and the User Blog RSS syndication, which we wont have use for since we will have our own tailored one instead.

Is there anything else the Blog module provides that has to be recreated when using a custom blog type? Would be great if you could point me to more info about it.

I just want to make sure I know exactly what I give up if going the custom type route.

T: @tsvenson | S:

One more small thing

tsvenson's picture

One more small thing Michelle, if I may.

If the author field is used to give users permissions to post in the blog topic type, how do I then allow more than one user to post in the same blog topic?

T: @tsvenson | S:

Using CCK to administrate and control

tsvenson's picture

Right, back from the tank with a new idea.

One goal I have is to come up with a plan that minimise the risk that the solution will complicate other parts of the site. Most of the access control modules I have looked at would mean that not only the blogs would be affected, all other nodes would be to in various ways. Most likely that I would have to set default access rules/permission for them, adding another layer of complexity when it comes to administration as well as taking some form of performance hit.

Since the structure of these blogs is very simple:

  1. The overview page is at /blogs
  2. Each blog topic is at /blogs/[blog topics
  3. Each blog post is at /blogs/[blog topic]/[blog post]

That basically leaves me to only have to worry about #3.

Then the question is - How to I create a flexible system with a minimum of administration and impact on any other part of the site?

Another important factor is - Only staff or freelance contracted content contributors that we authorise will be able to post blogs.

Therefore, to start with, it will be a very limited number of people that will be able to submit blog posts.

Next requirements are:

  • One user can post to multiple blogs.
  • Any one blog can have multiple users posting to it.

In comes CCK, Content Permissions and Pathauto (plus probably some others too...).

I create, as you suggested Michelle, the Blog Topic content type that will contain description and other fields that will be presented for visitors.

Then I also create a few more "administration" fields for being able to add the [blog topic] part of the URL as well as a field for the user(s) that will be able to post for this blog topic.

With Content Permissions I can control who can edit and view a CCK field. Then I can use the [blog topic] field as a token in URL alias and the user(s) field to control who will be able to post:

This will mean that I:

  • Avoid using any access, etc, modules that would impact on other parts of the site as well as performance
  • Have the administration and control directly on the blog topic page and limit access to it to only admin/editors using Content Permissions. I could also build special admin interfaces pulling information from these pages.
  • Can view a create blog post link/button directly on the blog topic page only for users that shall be able to post there.

It will even be flexible enough to allow me to create more than one content type that can be posted as a blog post, for example a poll post. I could even have check boxes on the topic page allowing me to select what content types can be used.

The only thing I haven't looked into yet is how I can use the [blog topic] from the blog topic content type to build up the URL for the blog posts, but I believe that is a minor problem that can be fairly easy to solve. An easy way would be to simply copy the [blog topic] value from the blog topic page.

Using theme templates it will give me total freedom to theme the end result.

Then, to create a new blog I only have to:

  1. Create a new blog topic node.
  2. Set the [blog topic] to be used in the URL.
  3. Add one or more users with Blogger role that are authorised to post.
  4. Add a new Panel to be included on the /blogs page if needed.
  5. Blog ready

Of course this can, and should be, improved on, but since we can lean on trusting our bloggers (for now :) that is something that can be added at a later stage.

Another advantage of this is of course that we in the future can use the blog module to allow every other user to create their own blogs and they will be completely separated from this.

What do you think of this?

T: @tsvenson | S:

Couple suggestions

Michelle's picture

You can use Pathauto to alias the URL. If you use a nodereference field from the blog post to the blog topic, the title of the blog topic will be available as a replacement token for the blog post alias.

Nodereference can use a view to populate the options. If you have a field on the blog topic that lists the UIDs of users allowed to post on it, you could make a view of nodes where the current user's UID appears and use that in the nodereference field. I'm not 100% sure you can do that in the views UI so that part might need a little custom views coding. You'd have to try it and see.

FWIW, I'm using this custom blog solution on my own site, minus the posting permissions issues. I was using the blog module but wanted something more flexible. AFAIK, the only thing I'm giving up is the "NAME's blog" link on the blog posts and I could add that in myself if I wanted.


Yes, was going to use

tsvenson's picture

Yes, was going to use pathauto for that. Had nodereference in the back of my head to look into to solve the last issue, glad you confirm it is the way to go.

My brain is cooking right now so I will leave this for tomorrow to do a test implementation.

Right now I am just happy I have a simple solution that is completely isolated and don't need to use modules that would have had implications on other parts.

As they say, the hardest thing is to come up with the simple solutions...

T: @tsvenson | S:

That sounds like a good way

morisy's picture

That sounds like a good way of going about it, but would you be able to restrict what blog topics people can add to the URL?

For example, Tommy is the blogger for "Linux Stuff". How do you make sure he doesn't add something to "Drupal Rocks" by changing the posting URL? If they're trusted users, it might be fine now but it seems the input validation to check and see if every user has permission to choose how to populate the "Blog Name" field would be tricky, quick, and would be more problematic if you open up to less trusted users.

But maybe I'm missing something on how CCK permissions for fields work.

Web guy,
Twitter: @morisy / @sparechangenews

I don't think that will be a

tsvenson's picture

I don't think that will be a problem. Since Content Permission allow me to restrict which roles can edit and view the content of a field, Tommy will never see any of the "admin" fields.

As I said, the only thing (I think) I need to solve is to copy, or reference, the [blog topic] field from the blog topic page, where Tommy clicked the "Create Post" link/button, used for the URL to the blog post. So even in the blog post it will be invisible for the blogger so they will never be able to change it. At least that is what I hope I can do.

T: @tsvenson | S:

For one of our clients I used

mattiasj's picture

For one of our clients I used Ownterm to achieve a pretty solid multi blog solution. The issues I still have that I am not satisfied with is that each blog categories and tags don't really get isolated with nice looking URL:s. I use the terms descriptions to create blog headers combined with the authors picture which works okey.

We are currently investigating various solutions since we are about to make an even bigger multi blog site. One thought is to have a content type 'blog' paired with 'blog-post'. That would make it easy to add header images and various cck fields to the blog itself. The only problem I see here is how to solve the permissions part but from what I read above it should be possible to solve.


ggevalt's picture

I appreciate the discussion here, and wondered if you would mind giving a little more information about the content. I remain a bit confused. Are you organizing "blogs" around a particular subject or topic, or are you grouping them by geography or by age group or what?

That might help some of us offer you solutions.

For instance, if your site were about African animals and you wanted anyone to blog but wanted to confine each blog to a particular animal, so you had Tiger Blog and Giraffe Blog, etc... than I could see one set of solutions that might work. Or, even, if you were isolating blogs so you had folks blogging about animals in Botswana, and another blog from South Africa, etc....

If that is the case, then I am confused as to the administrative headache. You say at one point that you don't want users to create a new "blog" so does that mean that administrators define the blogs?

If you had a finite number of blogs and you only wanted administrators to determine what those blogs were about, you might then think about using taxonomy to do this, so you had a taxonomy field that was required but that you gave the users a choice; so if I were blogging about Tigers, I had an option to choose from the menu of animal blogs and would choose Tigers (unless I were confused, of course, and thought a tiger were a lion. Sorry.)

Then, as another user pointed out, you can use pathauto to help with creating the path that would include the blog and other information to follow (say another keyword choice and username)

And as to appearance, there are a number of options but certainly you could establish that only certain blocks or panels appeared given the path and, even, theme or CSS choices.

An additional thought would be to consider these not as "blogs" but as organic groups and that opens other possibilities.

Anyway, I don't mean to confuse, I guess I just wanted a bit more information on the content and use of your site -- that always helps with conceiving solutions.

cheers (which seems appropriate given your avatar).

Hi ggevalt, The site is a

tsvenson's picture

Hi ggevalt,

The site is a media website and the goal is that admin/editors will manage these blogs. That is, no writer with the "blogger" role will be able to create new blogs or post in blogs they are not supposed to post in. That is, we want the admin/editor to have full control over them.

The blog topic page (as described above) is the blog home page. It will pull information from various sources, such as description of the blog, author info, blog archive and of course a list of the x latest blog posts in either teaser or full post mode. The blogger(s) will have no edit rights to this page.

Then admin/editor will assign a blogger to be allowed to post in a particular blog topic. Many of these will only have one blogger, but there will be cases when more than one blogger will be able to post in the same blog.

We will use taxonomy for these, but I have ruled out modules such as TAC and TAC lite. Unless absolutely necessary we want to avoid using modules that affect the whole site when its functionality is only needed for an isolated area/feature.

So, basically my idea is that the "Blog Topic" page will both provide the blog home page and function as the administration and configuration of the blog posts. When a blogger surfs to his blog topic(s) they will see a button/link for creating a new blog post for that topic. Then the blog post is pulling the information it needs from the blog topic page to be able to create the relations needed so that the blog post then will have the correct URL.

I hope that make it a bit more clear about what I am trying to accomplish here. I am pretty sure it will be no problem, I just need to figure out how to do it :)

T: @tsvenson | S:


ggevalt's picture

Thanks for the added info, but one more bit of info would be helpful given that I'm more a content guy than a coding guy....

So what is the content? What is the focus of the site?
Are you saying that each individual given the right to be a blogger has his/her own blog and no one else can post to it and that person cannot create a new blog?

This seems contradictory:
" No user can create a new blog, only be authorized to post to one created by admin/editorial staff.
One user can post to multiple blogs.
Any one blog can have multiple users posting to it."

If one blog can have multiple users posting to it how does that square with the idea that a blogger can only post to one blog? And perhaps the key is "post in blogs they are not supposed to post in. "

So again, the question, what is the overall content and strategy? I'm still not getting the concept -- the details I can probably muscle through later -- but what's the concept? Who are the bloggers? What are the topics? Why do you want to limit them to posting to only one or a few blogs? If I know the concept and the rationale, it would be easier for me to think out potential solutions for you.

Ahh, I think I know where the

tsvenson's picture

Ahh, I think I know where the confusion is. I think its my use of [blog topic] and blog post. The blog topic is the topic for the blog, the blog home page, not the title of the blog post.

Let me give you an example.

Lets say we are a sports magazine and we want our golf writer to have a blog about golf. We also want to integrate it well on the website as an official magazine blog.

We also want all official magazine blogs like these to be presented on /blogs to give the readers a nice overview, use the same templates to make them stand out from other content etc.

Presentation of all the official blogs on the site.

This is the blog topic, the blog home page, with more information about the golf blog, the author(s), the x last blog list (teasers or full), archive and other stuff. Basically what you find an a normal blog. It will also have its own unique feed.

This is the individual blog post. It is also where readers can comment this particular post.

So, admin/editor will then create the /blogs/golf blog topic page using the blog_topic content type. They will also add our golf writer to a user cck field on that page. The "blogger" user reference field will be used to both pull information about the author(s) from their profile and the create post button/link for the right users. By making the cck user reference field unlimited we can add as many users as we need for the golf official golf blog.

Now our golf writer only need to go to /blogs/golf and will find a button/link to create the /blog/golf/tiger-woods-making-comeback blog post.

The blog_post content type will then pull some referenced information from the blog_topic page, such as the /blogs/golf URL so the new post has that in the URL as well. This information will be used to automatically set internal taxonomy terms and other stuff that is unique for the golf blog, as well as needed to list the right blog posts on the right blog topic page.

This makes it easy create the golf home page (list page for the x last blog posts about golf) by simply create a new node of the blogs_topic type without interfering with existing blogs.

T: @tsvenson | S:

DrupalMU or combining Panels with Taxonomy?

kmgflavin's picture

I want to do something just like what you're doing on the media site, but for my own purposes. I want to blog about different topics without mixing them, and I want each blog-focus, i.e. golf or jQuery, to have a different theme. Have you tried DrupalMU ( I've just started reading that, but I'm deep into a Taxonomy/Themekey/Panels test and I'd hate to rip it all out. But better now than later. My problem is that Themekey is lagging behind in development and it looks like it's missing some needed functionality.

Recovering programmer, currently with Carlisle Group. Not the Wash D.C. (Carlyle Group) one.

Creating Custom Content types

kmgflavin's picture

I just re-read your original post. I'm assuming you've tried creating custom content-types to control access to content creation, e.g. blog posts?

Recovering programmer, currently with Carlisle Group. Not the Wash D.C. (Carlyle Group) one.

Newspapers on Drupal

Group organizers

Group categories

Topics - Newspaper on Drupal

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: