The blog module has a built-in assumption that there is a meaningful difference between blog/ (the full site blog) and e.g. blog/1 a particular user's blog. For this reason, it is primarily only useful for a multi-user blog, which is a serious limitation (since a lot of sites start off with a single blogger but then add more, but by that point all your existing blog posts would be of a different content type, and therefore difficult to switch over).
We are seeing this problem in Drupal Gardens; we'd love to use this module for a blog site, but without serious tweaking it doesn't make sense to do so because the person starting out the site is very likely to be the only blogger.
However, it doesn't seem that hard to fix. All we have to do is check the number of blog authors in the database and slightly tweak the text and links for the two cases. That is, the module should start off making sense for a single site-wide blog, but as soon as the second person creates a blog entry, it should display things as it does now.
Note that in this patch I have removed the node links for e.g. Name's blog in the case of a single-author blog... We could replace them with a link to the main blog page instead, but I couldn't think of a great link caption for that; plus, many single-blog sites might use the front page as their primary listing or something else.
This patch might be a bit much for Drupal 7, but I'm posting it here anyway - the current behavior is nonsensical enough to be considered a bug. If not good for D7, we'll move it to D8.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | blog-single-user-792062-12.patch | 10.14 KB | David_Rothstein |
| #1 | blog-single-user-792062-1.patch | 5.81 KB | David_Rothstein |
Comments
Comment #1
David_Rothstein commentedPatch got eaten, apparently.
Comment #2
gábor hojtsyI think this is a great idea. The part I'm not so sure about is the sudden change in "site structure" when the second user starts to blog. Also, until that blog post is published, it is not possible to preview how the site would look / behave once that blog post is there, so the eg. the added node links will come from thin air. Maybe it would be a better idea to make a setting out of this instead of just trying to be so smart about it? Not sure how to cover this under a sensible setting though. Multiuser vs. single user blog is really not what you set, since even without the per user listing screens and node links, it could still be a multiuser blog just channeled into one river of news type of page. Maybe "link to per-user blogs" or something like that.
Comment #3
JacobSingh commented+1
This is a major UX fail and has been for a long time. I don't think I've had a single client configuring Drupal themselves who doesn't turn that module on, only to be massively confused when I tell them that's not what they want.
I agree w/ Gabor about making it less "smart" though... What are the options:
1. Add a setting for MU vs SU blog. Problem is where, how would someone know to look for it, what's the default?
2. Be smart the way david is doing it.
3. Be smart through permissions. If any roles have permission to create blog posts then it is MU? Kinda bad because best practices is not to use user 1... again, too smart for its own good too.
4. Email the admin when the 2nd blog post gets created letting them know that their site has become a MU blog. No precedent in Drupal, probably a non-starter but maybe the only want to get their attention.
I'm leaning towards what David's got already just because I don't know where such a setting would go or how to communicate it. If we improved the module page to have wizards on install, I'd feel better about it. There is of course a "config" link there, so maybe people will use that.
-J
Comment #4
Noyz commentedBoth ideas have merits. Not sure which is best. I like the idea of being smart, but think it's a big flaw that you can't preview and unpublished post. I also tend to dislike smart choices unless its 100% transparent - which in this case it sounds like it's not. That said, a thoughts on the non smart approach:
All modules now have a configure link. I think this could solve this problem. In terms of treatment, you could pick up the comment model "[x] show all blog entries on main blog page" or "[x] provide bloggers with a dedicated page. Help text = "for example blog/johndoe
Comment #5
David_Rothstein commentedYou can't really do that without this patch either, can you? Unpublished posts do not show up in the blog listing or on the front page, node links (as viewed by an administrator before the blog post is published) are unlikely to be the same as node links viewed by a regular user after it is published, etc. I don't think this patch adds many differences on top of that. The difference in behavior between published and unpublished posts seems like a much larger Drupal workflow issue to me.
I don't think the breadcrumb/title changes in this patch are worth a configuration setting. It is mostly just intelligent use of single/plural ("Blog" vs "Blogs") and not giving duplicate links to two almost-identical pages in the same breadcrumb - that seems like something which should be done automatically. I am not sure there are too many use cases for a site with a single blogger to have their blog page titled "Blogs" :)
So that basically leaves a configuration setting for the node link that appears on the blog posts. A configuration setting for that is somewhat of a separate issue and has been marked won't fix/closed several times, it seems:
#15077: Blog module should include option to remove author's blog link
#324796: A link called "$user's blog" is printed after each blog post and cannot be removed
(both quite a while ago, but just pointing out the history)
Really if it were an option in the UI, I think it would probably be 3 options?
1. No link
2. "David's blog"
3. "My Site's blog"
I can see why silently switching between 1 and 2 (as the above patch currently does) is maybe not great though.
Comment #6
cbrookins commented+1 to showing an option in the UI with 3 options. I'd reword the options to be
1. No link
2. {username}'s blog
3. Custom: [My Site's blog]
Comment #7
ksenzeeIf it were an option in the UI, maybe it should be
1. No link
2. David's blog
3. __________
because I might want it to say "more posts by Katherine" or some such.
Comment #8
ksenzeeThat'll teach me to refresh before I post. :)
Comment #9
David_Rothstein commentedA custom link is too complicated. How would we decide what URL to point it to?
The idea I was trying to propose is more specifically this:
* No link => means what it says :)
* Link to user's blog => if they choose this it points to
/blog/[uid], with text {username}'s blog* Link to sitewide blog => if they choose this it points to
/blog, with text {sitename}'s blogNice and simple. I think we are already somewhat pushing the limits by proposing a UI for this at all, to be honest :)
Comment #10
ksenzeeI can get behind #9 - I'd rather see the text options for both /blog/[uid] and /blog be customizable but that's an easy fix in contrib.
Comment #11
David_Rothstein commentedYup, contrib... or even the Locale module in core, I think? (I haven't actually tried this technique since Drupal 5, but I think that's the name of the module that lets you do that.)
Comment #12
David_Rothstein commentedHere is an updated patch that adds the user interface described in #9, and also makes it so that the Blog module's main page can be set as the front page of the site without it looking out of place (basically, makes it so an extraneous "Blog" page title does not display in that case).
I have also ported this code to a small contrib module: http://drupal.org/project/flexible_blogs (since we aren't too likely to get this in core for Drupal 7)
Of the options in #9, this patch currently makes "Link to sitewide blog" the default (since someone turning on the blog module for the first time doesn't have any blog entries yet, so is likely to be starting off as a single-user blog). Thinking about this a bit more, though, I wonder if we should add a fourth option to that list:
"Determine link behavior automatically"
which would go back to doing it the way my original patch did? (That way we still get the automatic behavior, but people can override it if they want to, so it's not a total mystery to them why it occurs.) Something to think about.
Comment #13
grantarchy commentedIs there anywhere which explains exactly what the pros and cons are to using the Drupal blog module and what are the alternatives to using it? I have gathered that it is not the best if there is only going to be one person posting. I haven't found many arguments as to why this is, or what one should do if they are the only person posting. In the book, Learning Drupal, they say "it's simpler and less cluttered to create a custom content type called 'blog post' and leave the module turned off" ... but there is no concise explanation on what you lose if you choose this approach or how to accomplish it. Overall I read a lot of complaints about the module, but I can't seem to find much that presents a clear and concise situational guide.
Comment #14
webchickSorry, this smells awfully feature-y to me, given that Blog module has behaved like this since before my time in the Drupal community. We're also "supposed" to be in UI freeze atm.
Comment #15
naheemsays commented@ #13 - just rename story/article to blog and you're done for a single user blog. You do not need the blog module.
What you will lose is a listing of your blog at blog/%, but if it is just a personal blog, then that will be the front page (or node page) in such a circumstance.
What the blog module allows is for users to group their blog posts in a single location (blog/% where % is the user's uid). if there is only one user, it is simply not required.
Comment #16
icosa commentedI'm struggling with this a little too, i.e, setting up a new site with a blog and wondering if I should use the blog module. The site is for one person so therefore it's a single user blog for the foreseeable future but ... knowing the client and his community involvement, I can see a good possibility of him wanting to allow someone else to blog on the site even if he hasn't thought of that yet.
I guess this patch might be the answer. Thanks David.
nbz #15 Without the blog module, "What you will lose is a listing of your blog at blog/%"
I guess you lose the block listing recent posts but that's easy to create with a view.
And I guess you also miss out on the blog API which sounds like it could be useful.
Comment #17
naheemsays commented(blog API is not linked to the blog module and can post to multiple content types. You will not lose that as it can post to any content types, but discussing how to use the modules is out of the scope of this issue.)
I agree it will be useful, but it has been postponed to Drupal 8 territory.
Comment #18
deekayen commented#233301-125: Remove blog module from core removed blog from core.
Comment #19
deekayen commented#12: blog-single-user-792062-12.patch queued for re-testing.
Comment #20
kingfisher64 commented@David _Rothstein - thank you so much for your work on http://drupal.org/project/flexible_blogs. I've not needed core blog until today. I'm grateful of your patch/module fix as this is exactly the out of the box functionality that I needed and that most users who are starting their single user blog will want.
Is David's patch/module being submitted for used in the d8 blog module by default as it's been queued for a while now?
Comment #21
deekayen commentedThe patch is pre-git era, so I had been ignoring it.
Comment #22
chris_hall_hu_cheng commentedCurrently the Blog module doesn't work with latest Drupal 8, I have be working on a big patch to solve this but wrestling with best practice for controllers etc (something which isn't entirely clear and handled in lots of different ways in core, still).
When the module is back on track shortly, it would probably be a good time to triage some of these old issues and clear the deck. Any patches are likely to require a total rewrite for D8 though ;)
Comment #23
nevergoneOutdated issue.