Posted by nbz on May 22, 2009 at 11:32pm
7 followers
| Project: | Blog |
| Version: | 8.x-2.x-dev |
| Component: | Miscellaneous |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
I would like to see the ability to have more than one content type in multi user blogs - the ability to add polls, media nodes, questionaires etc would be good.
So this is asking for the blog to become something like what happened to the forum module, but instead of being categorised by taxonomy, to be categorised by user, but not a complete listing (which is what tracker does)
Something like:
1. Keep the blog node as a default blog node implementation that is added by default to the blog.
2. For other node types have a publishing option of "add to blog".
Comments
#1
#2
An alternative approach that will probably be rejected, but here goes - replace the blog module with nodequeue (with automated nodequeue userblog functionality)?
This will allow for many types of blog nodes, and also could be extended to have a nodequeue based rearrangeable front page?
#3
+1 for the approach describing in the original post - this would be great. (Although fields in core might render it unnecessary?)
#2 is an interesting suggestion, but I would suspect that the implementation would be dicey. (Especially for the front page, since currently that uses the promoted field in the node table, and to switch to nodequeue would require adding a join to the query.)
#4
I have made a start on this, but I doubt I know enough to complete it.
Attached are two files - a new blog.install, and also a modified blog.module and blog.pages.inc - I have no idea how to create a patch that includes files that are not in CVS.
ToDo:
Functions to add a checkbox for "add to blog" and further to remove the data on update/delete.
This is more a proof of concept that anything else but I am willing to try and take it further with mentoring and (very detailed) help/instructions.
#5
and the two files combined.
#6
The last submitted patch failed testing.
#7
improved patch, but still not complete - the node load/save/edit stuff needs to be added/routed to set/show on the blog.
I have also dropped the earlier approach of a new table as that seemed to be something that would be slow adding a join onto most queries - instead I am adding an is_blog column to the node table.
#8
The last submitted patch failed testing.
#9
no real changes from the last patch - just manually changed it to be from the drupal root.
#10
The last submitted patch failed testing.
#11
and this should be feature complete. Only need to look at the tests and what they say now.
#12
grrr! Anyone know how to force tortoise CVS to make a patch from drupal root? it keeps creating it from within the blog folder. manually updated patch from drupal root.
#13
nbz: AFAIK you should be able to just right-click on your root Drupal folder and choose "Create patch.." but it's been about 3 years since i used Tortoise..
#14
The last submitted patch failed testing.
#15
nbz.
i don't like this strategy very much, but i'm open to arguments in favor of it.
i don't want every content type on my site to be 'bloggable.' just because a user has permission to create a certain node type doesn't mean she also should add it to her blog. site admins should have control over which types of content can be in blogs, and this should be separate from a typical blogger role's permission to create content of particular types. think of this in the context of feedapi or organic groups. i might want a feed to create blog items, but i don't want the feed node itself to be in that user's blog. the same goes for an OG group node. why would it ever be in someone's blog?
we still need permissions around blogging. instead of the typical node access permissions for a content type, i would abstract this to a permission to have a blog.
for example: a user has permission to create image nodes, story nodes, and audio nodes. these are also configured to be "blog" node types. that user can create his image nodes and story nodes, but he may not have permission to have a user blog which collects all/some of these postings at a path like 'blog/%user'. this permission would be the #access parameter on your 'blog_form_alter' is_blog form element.
adding a column to the node table creates potentially many zeros for what is conceptually a boolean value. it's another index to maintain, too. perhaps drupal gurus can say whether this is acceptable practice for Drupal 7 in general or advise whether this is an appropriate reason for extending the node table's schema.
another solution could be to create a table called 'blog' which contains a foreign key on the node table. nid or vid? experts will need to chime in which is preferable. this would require a join on that 'blog' table. this makes SELECTs a bit cleaner and keeps DB indexes manageable. when a node is loaded, a matching row in the 'blog' table would let $node->is_blog = TRUE.
for mysql innodb users, this kind of join between tables on the primary key is not very costly at all.
i don't understand the use of a 'blog' content type as a multiuser blog. i don't see any code that relies on this change in your patch. multiuser blogs could also be implemented using the same blog-enabled content types and a blog.module specific taxonomy vocabulary, similar to how forum.module uses a taxonomy.module vocabulary.
thanks for starting on this patch. you can often find me in IRC if you want to chat. i have a drupal 6 module that implements blog features along these lines. if you'd like to review it, it is available here:
https://bangpound.svn.beanstalkapp.com/drupal/trunk/drupal/sites/all/mod...
#16
Done this - most of how it was was due to convenience when I was modifying the code, seeing what was possible. That and I did not know how to do stuff. I have had a look at your code and taken stuff from there. However, it may be better if instead of a checkbox (on or off), there are three options: "No", "Yes, add to blog by default", "Yes, but don't add to blog by default".
I did first attempt the separate table approach like how forum module does, but the downside of that was that it had no unique content and either I would have had to have a JOIN on all the queries (which I presume is slow) or duplicate the relevant data in the blog table.
The database gurus will have to chime in over what is better/worse, but one additional advantage the current approach has is there is no need to alter node_load/save/other etc to get the value saved.
This is more historical - people in the past saw a new content type be created, and they may expect it in the future. I also now add a variable to make this addable to a blog by default while this is not the case for other content types - they need to be manually added.
Another question is one of a "guest blog". Do I explicitly ban that, or remove the tests for it? I can see uses for it... kind of like a cheap copy of The Guardian's "Comment Is Free" where people cna add content, but this is not a true blog, so we may want to again explicitly not allow it.
(I will need help on the tests - I do not know what is going on there, what is changes functionality that needs fixing in the tests and what tests are really failing...)
#17
and the correct patch.
@webchick - I did try that, but I think I have somehow changed some settings in it. It used to work properly from root, but now creating a patch from there does not create it from root.
#18
and a couple more stupid fixes.
#19
The wording may need some help, but I think this is a fine idea.
It's not fundamentally wrong to make a table whose only column is a foreign key. I'm not qualified to defend a position, but my simple reading of the problem is that it's not necessarily going to be poor performing. Good performance may rely on foreign key constraints and the clustered key indexes they require.
You'll need more feedback on the issues of legacy, documentation, etc. on the reasoning to keep a 'blog' content type. My instinct is to drop it if the only reason to keep it is because Drupal 6 users may expect to find it.
What about using a proper Field API field and widget for the "blog" checkbox?
The "guest blog" sounds like a marginal use case that (a) I don't fully understand and (b) sounds like a job for contrib.
This change may have fundamental consequences for blogapi module, so .. yeah. Just a heads up on that one.
#20
nbz
I don't want to change the title of this issue, but I propose you consider changing it and the patch's scope to:
Allow multiple content types for user blogs
"Multi-user blogs" is a vague cloudy problem. It will be easier to separate it from this basic problem of multiple content types as blog posts for users.
#21
The last submitted patch failed testing.
#22
Changed title as suggested.
Not necessarily - I *think* blogapi can post to any content type, and through permissions any content type can be allowed to created by anonymous users.
blog.module had special code to disable this for anonymous users. that code I had to strip out and now the question is if new code needs to be written. The answer is "probably", and the "problem" here is it is adding specific code to limit the use cases, instead of specific code to extend the use cases. Blog posts can be banned for anonymous users from the normal node permissions too.
#23
This should now pass all the tests.
I have also added checks so anonymous users cannot post to a content type from the GUI - is this enough? If not, what else needs to be done?
#24
nbz:
I just raised the issue of separate table vs. is_blog column in node table with Crell in IRC.
I agree with you that it looks odd to have a single column table, but this is not unlike many-to-many tables such as term_node which are also composed entirely of foreign keys.
Another method is to use a Field API field instance, but given the current uncertainties around CCK Field UI, I wouldn't want to risk users removing the necessary 'is_blog' field simply because they don't know why it's there.
#25
The last submitted patch failed testing.
#26
Updated patch that uses a separate table instead of using the existing node table.
#27
I must add that I cannot help but notice how the current patch can be refactored (by someone else!) into a (very) simplified flag module which the menu system from the blog module would simply call...
#28
The last submitted patch failed testing.
#29
nbz: it's not very different from a simple field. flag module provides the ability for multiple users to flag a node. i would be interested to find out if we should be making this "is_blog" field into an actual field API field instance. on the one hand, it makes the table a little bit "thicker" than just a single column, but it does mean you can CUT lots of code and avoid some tests.
#30
No idea, and tbh, adding fields is probably above my skill level, desides the blog module is pretty small as it is anyway.
Also, I have no idea how to fix the current simpletest exceptions either, so I may have taken this as far as I can.
#31
nbz: i was just advised that this would be a paradigm shift in the community's understanding of fields, so we will pursue the strategy of using db functions.
i will work on this patch as soon as i have time, but that may not be right away. it's worthwhile to get some testing knowledge. i'm still very new with it myself, but maybe we can work on it together on IRC later this week or this weekend.
#32
I asked again on irc about whether the blog table should be a separate table or a column on node table, but most people mentioned how they think allowing multiple content types in a blog is a task for views. I disagree for a multiple of reasons:
1. blog.module is a core module. If such functionality should be in views only, then this should be removed from core.
2. views will afaik not work with pathauto to set different paths for content that goes into the blog. (I set it uyp to have the url blogs/username/node-title - views cannot do this)
3. With views aggregating a set of content types, content types are either in a blog or not in a blog - you do not have the middle option of choosing when it is in the blog and when not.
4. There is also forum.module which in a way is doing this same thing to allow multiple content types into forums.
#33
reroll.
#34
grrr... now from drupal root.
#35
The last submitted patch failed testing.
#37
There was a file missing in the above two patches.
#38
The last submitted patch failed testing.
#39
just testing.
#40
The last submitted patch failed testing.
#41
Moving to D8.
#42
#233301-125: Remove blog module from core removed blog from core.