Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Blog 2.0: Difference between revisions

From MoodleDocs
m (Text replacement - "class="nicetable"" to "class="wikitable"")
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Work in progress}}{{Moodle 2.0}}
{{Moodle 2.0}}


* '''PROJECT STATE: Coding'''
* '''PROJECT STATE: Complete'''
* '''MAIN TRACKER ISSUE''': MDL-19676 Blog 2.0 improvements
* '''MAIN TRACKER ISSUE''': MDL-19676 Blog 2.0 improvements
* '''DISCUSSION AND COMMENTS''': http://moodle.org/mod/forum/discuss.php?d=133348
* '''DISCUSSION AND COMMENTS''': http://moodle.org/mod/forum/discuss.php?d=133348
Line 9: Line 9:
Blog entries are either in draft mode (only the author can view it), or in public mode. In public mode, everyone on the entire site can view the blog entry.  
Blog entries are either in draft mode (only the author can view it), or in public mode. In public mode, everyone on the entire site can view the blog entry.  


At one stage in 2.0 development there was an attempt to restrict who can view certain blog entries, based on course enrolment and capabilities. However, after extensive discussion and feasibility testing it became clear that this would lead to serious performance and usability issues, and would turn the blog into something more akin to a forum. It was thus decided to make all blogs public. (See MDL-19676)
Before 2.0 there was an attempt to restrict who can view certain blog entries, based on course enrolment and capabilities. However, after extensive discussion and feasibility testing it became clear that this could lead to serious performance and usability issues on large sites, and was turning the blog into something more akin to a forum. It was thus decided to make all blogs public. (See MDL-19676)


An admin setting can allow for blog entries to be accessible by non-logged-in users, for the purpose of publishing and RSS feed aggregation.
This simplification means that sites using the old BLOG_GROUP_LEVEL and BLOG_COURSE_LEVEL and values of $CFG->bloglevel have to perform an special upgrade which copies all the site's blog entries into a special "blog-type" forum in each course in which the blog entry's author is enrolled, then disables blogging at site level.


Capabilities:
Capabilities:
Line 33: Line 33:


=== External blogs ===
=== External blogs ===
A user can import blog entries into Moodle from external blogs. The external blog's entries are copied into Moodle when the external blog URL is entered, and a cron task periodically checks these external blogs to copy new entries not yet entered in Moodle. The period of time between checks can be adjusted as an admin setting.  
A user can specify external blogs which publish an RSS/ATOM feed. This feed is then checked periodically through a cron task, and entries are copied into the user's blog in Moodle, as read-only entries.


These external blogs are a user preference, and two types of tags can be added to each of them: "External tags" and "Moodle tags":
This synchronisation checks if external entries have been modified or deleted since the last sync, and updates the Moodle entries accordingly.
*External tags are used to filter the external blog entries that get copied into Moodle. They must match the tags used by that external blog.
 
*Moodle tags are automatically added to each blog entry copied into Moodle from an external blog that uses such tags. This makes it easier to distinguish which of a user's blog entries come from an external blog.
These external blogs are a user preference, and two types of tags can be added to each of them: "Filter tags" and "Automatic tags":
*Filter tags are used to filter the external blog entries that get copied into Moodle. They must match the tags used by that external blog. An external entry will be selected if it has at least one of the filter tags. (Tags are called "categories" in RSS feeds)
*Automatic tags are automatically added to each blog entry copied into Moodle from an external blog that uses such tags.


This requires the creation of a new DB table.
This requires the creation of a new DB table.
Line 101: Line 103:
=== blog_external ===
=== blog_external ===


{| class="nicetable"
{| class="wikitable"
|-
|-
! Field
! Field
Line 132: Line 134:
|
|
| The URL to the external blog (e.g. http://moodle.org/rss.xml)
| The URL to the external blog (e.g. http://moodle.org/rss.xml)
|-
| failedlastsync
| int(1)
|
| Whether or not the last synchronisation failed
|-
|-
| timemodified
| timemodified
Line 146: Line 153:
=== blog_association ===
=== blog_association ===


{| class="nicetable"
{| class="wikitable"
|-
|-
! Field
! Field
Line 175: Line 182:
*[[Blogs|Early wishlist]]
*[[Blogs|Early wishlist]]
*[[Student_projects/Blog_improvements|2008 GSoC project addressing some of these improvements]]
*[[Student_projects/Blog_improvements|2008 GSoC project addressing some of these improvements]]
[[Category:Blog]]

Latest revision as of 13:22, 14 July 2021

Moodle 2.0


Description of improvements

Who can view blog entries?

Blog entries are either in draft mode (only the author can view it), or in public mode. In public mode, everyone on the entire site can view the blog entry.

Before 2.0 there was an attempt to restrict who can view certain blog entries, based on course enrolment and capabilities. However, after extensive discussion and feasibility testing it became clear that this could lead to serious performance and usability issues on large sites, and was turning the blog into something more akin to a forum. It was thus decided to make all blogs public. (See MDL-19676)

This simplification means that sites using the old BLOG_GROUP_LEVEL and BLOG_COURSE_LEVEL and values of $CFG->bloglevel have to perform an special upgrade which copies all the site's blog entries into a special "blog-type" forum in each course in which the blog entry's author is enrolled, then disables blogging at site level.

Capabilities:

  • moodle/blog:view
  • moodle/blog:viewdrafts

Associations

A blog entry can optionally be associated with a course. This makes it possible for a user to blog "about" that course. All blog entries associated in that way can be viewed on a page like blog/index.php?courseid=3. This type of filtering of blog entries does not take into account course enrolments.

Additionally, blog entries can be associated with an activity module.

This requires the creation of a new table, in which the associations are recorded. Tracker issue: MDL-14408

Capabilities:

  • moodle/blog:associatecourse
  • moodle/blog:associatemodule

Improved navigation

Before 2.0, the navigation for any listing of blog entries was either "Site > User > Blogs" (for a user's blog entries) or "Site > Blogs" for the whole site's blog entries, optionally filtered by tag. With the new association features, we need a better way to display what type of blog listing we are looking at, based on the parameters passed to blog/index.php. The navigation should also reflect additional filters such as tag and search.

External blogs

A user can specify external blogs which publish an RSS/ATOM feed. This feed is then checked periodically through a cron task, and entries are copied into the user's blog in Moodle, as read-only entries.

This synchronisation checks if external entries have been modified or deleted since the last sync, and updates the Moodle entries accordingly.

These external blogs are a user preference, and two types of tags can be added to each of them: "Filter tags" and "Automatic tags":

  • Filter tags are used to filter the external blog entries that get copied into Moodle. They must match the tags used by that external blog. An external entry will be selected if it has at least one of the filter tags. (Tags are called "categories" in RSS feeds)
  • Automatic tags are automatically added to each blog entry copied into Moodle from an external blog that uses such tags.

This requires the creation of a new DB table. Tracker issue: MDL-19683

Capabilities:

  • moodle/blog:manageexternal

Search blog entries

It is now possible to search blog entries using a search box. The results maintain the current context, so that if you are viewing a list of blog entries for a particular user, entering a term in the search box will return only the blog entries for that user that match the search term. The search term also appears in the navigation breadcrumbs.

Tracker issue: MDL-19686

Capabilities:

  • moodle/blog:search

Contextual blog menu

Previously, the "blog menu" block was the same on every page on which it appeared. In 2.0 it changes depending on which page you are. For example, if you are on course/view.php, it will include a link to blog entries associated with that course. Also, the link for adding a new entry will include the courseid, making the course association automatically pre-selected in the blog entry edit form.

Tracker issue: MDL-19687

File attachments

The new file manager must be implemented to allow for multiple file attachments per blog entry.

Tracker issue: MDL-19744

Comments

The new Comments API makes it possible for anyone having the correct capability to comment on blog entries.

Tracker issue: MDL-8776

New "Recent blog entries" block

This block can be configured to display the last N blog entries, filtered by context. For example, if you are viewing an assignment activity, this block would display the last N blog entries that are associated with that assignment.

Tracker issue: MDL-19688

Potential problems and limitations

Upgrade from "Users can only see blogs for people who share a course"

This mode was always a slightly quirky and uncomfortable hack. It was mostly useful for sites with very distinct courses and users, such as those where each course consists of the employees from a separate company, and My Moodle was used to hide the companies from each other. However, for the general case, the main problem is that you see ALL blog entries from those people, not just ones that are about your courses.

This mode has no direct equivalent in Moodle 2.0 because we have resolved not to emulate "course-like" modes within a system that is at system level, and outside the courses. This helps understanding of the blog system, simplifies the implementation and improves performance.

However some people may be using that mode so we do need to provide an upgrade path for them.

Informationally, the idea of just seeing all the blogs from people who are in your course is the same as a course forum.

So a possible upgrade would be to do this:

If the mode is set to "Users can only see blogs for people who share a course" then
  Set the new mode to "Users can only see their own blog"
  Foreach user who has a blog 
    Foreach course that user is enrolled in 
       If a "Course blogs (recovered)" forum doesn't exist yet in the course (section 0) then create one
       Foreach blog entry that the user created 
          Create a new discussion from the blog post with the same dates, attachments etc

This way no data is lost. The teachers can choose to delete the whole forum if they choose to. The original blog entries should not be touched.

DB Structure

2 new tables need to be added: blog_external and blog_association

blog_external

Field Type Default Info
id int(10) auto-incrementing The unique ID for this external blog.
userid int(10) The owner of the external blog
name char(255) A descriptive name for the external blog. Automatically fetched during initial import, can be overridden.
description text(small) A long description of the external blog. Automatically fetched during initial import, can be overridden.
url text(small) The URL to the external blog (e.g. http://moodle.org/rss.xml)
failedlastsync int(1) Whether or not the last synchronisation failed
timemodified int(10)
timefetched int(10) The last time the entries from this external blog were fetched by Moodle.

blog_association

Field Type Default Info
id int(10) auto-incrementing The unique ID for this blog entry<->contextid association.
contextid int(10) The context id defined in context table - identifies the instance of the course or plugin associated with the blog entry.
blogid int(10) The id of the blog entry (from the post table) being associated with a course or module instance

Upgrade process

The only task required by the upgrade process is to install the new DB tables.

See also