Adding a blog to the Commerce provides a two-way channel for communication with users. By its nature, this tool is aimed at a Commerce web presentation layer - it does not make much sense in any other medium. In general, creating quality content is they key to achieving good search engine optimization (SEO). Therefore, generating content in a blog that can also be related to the products the Commerce sells boosts SEO and enhances its reputation. There is the option of relating products to blog posts, which helps users to reach the Commerce contents and end up buying something; this is an indirect way of helping to increase sales.
The blog follows the common layout of these tools, so it includes a space where users can leave comments. These comments are supervised, so only those that have been reviewed and accepted are displayed. This avoids the spam that sometimes attacks blogs.
Users can subscribe to the blog, to one or more of its categories or to posts, to receive notifications when the Commerce publishes new content.
The blog settings allow you to determine how different elements behave.
Comments can be regulated with these three levels of restriction:
Comments Not Permitted: Users cannot leave comments on the posts published.
Registered Users Only: Only users logged into the Commerce can leave comments. As users must be registered with the Commerce to log in, only registered users can leave comments.
Registered and Anonymous Users: Both users who are not logged into the Commerce and users who are logged in can leave comments. At this level, any user can leave comments.
Furthermore, if you only allow registered users to comment, a check can be set to verify their email address. This means that only registered users who verify their email can comment. It may be that the Commerce does not require email verification when registering, but the blog does in order to ensure the authenticity of comments. In this case, when a user tries to comment they are told that they must verify their email. The verification process consists of sending an email message to the address the user provided when registering. The user verifies the address simply by clicking on a link that leads to a web presentation layer page. There the system makes the relevant checks and, if everything is in order, verifies the address. You can find further information below.
You can also limit the number of comments a user can make to avoid spam or misuse of the tool. This check is carried out by IP to improve antispam management. When the maximum number of comments is reached, the system returns an error message saying so.
If a comment made by a user is pending review and acceptance, this user (or more specifically, this IP) cannot comment again until the first comment is published.
Subscriptions are explained in more detail below. In general, there are three kinds of subscriptions, but it is possible to limit this number so that users can only subscribe to the elements needed. Specifically, the following subscriptions can be enabled or disabled:
Blog Subscriptions: If enabled, the web presentation of the blog can display the blog subscription form; if not, users cannot subscribe to the blog.
Blog Category Subscriptions: If enabled, the web presentation of the blog can display the blog category subscription form; if not, users cannot subscribe to blog categories.
Post Subscriptions: If enabled, the web presentation of the blog can display the form to subscribe to a post; if not, users cannot subscribe to posts.
The blog can have the same languages enabled as the Commerce, or only some of them. For example, if the Commerce has Spanish, English, French and Chinese enabled, the blog might have only Spanish and English. The URLs of the blog categories and posts will therefore only be available in the languages enabled in the blog.
You can also specify a predefined language other than the predefined language of the Commerce. Imagine that a user is browsing the Commerce's web presentation in a language that is not enabled in the blog. If they enter the blog presentation, the content will be displayed in the predefined language in the blog. When they go back to the Commerce website, the content will appear in the same language as was displayed in the blog. If a Commerce web presentation page is in a language not enabled in the blog and links to posts related to a product are to be shown, these links will be displayed in the predefined language in the blog.
The main blog route - the home page - can be a route with whatever friendly URL we want, and also configured for each language enabled in the blog. If the same route is used for all the languages (for example /blog), when a user accesses the blog they will see it in the language they are browsing in, providing this language is enabled. If it is not, the content will be displayed in the predefined language of the blog. As the web presentation layer can include some kind of control to change the language, the system will return the blog start page in each language by adding /[id] to the end of the SEO route, e.g. blog/es or blog/en. This happens even if the Commerce does not have the function of displaying the language in the URL enabled (if it has it enabled, it is normal that it is displayed). For further information, see SEO Suite.
This function makes it possible to count the number of impressions for a particular post (number of times it has been displayed). If it is enabled, the Commerce sends the system a notification every time it records an impression. Rankings of the most seen or read posts can then be run.
The blogger is the author of a post. They can be any user of the Commerce who takes on a special function, in this case that of blogger. The configuration to do this is set in the BackOffice user section. The blogger must have a name (a single field for all languages) and optionally a description (depending on the language of the blog), which is displayed to introduce the author.
Commerce managers with the necessary permissions can edit, enable/disable and publish posts. Publishing a post means leaving it enabled with a publication date earlier than the current date. If a later publication date is set, the post will not be displayed in the blog until this date has passed and therefore the post cannot be considered published.
Each post must always be linked to a blogger (a Commerce manager with the necessary permissions must do this). If requested, the system can display a list of all bloggers and, when filtered by blogger, a list of the posts published by each of them.
A blogger is by definition a user with this function. A blogger can therefore be a Commerce manager who creates and publishes posts, but can also be an external author. In the latter case, the author has to send a text to a Commerce manager who creates the post and publishes it in their name - just as journalists send their articles to the newspaper editor to review, correct and publish them.
Posts can have a series of labels associated with them. These serve to classify their content. It is advisable to display them as a cloud so that the user can filter posts by label and see all the ones that have this label linked to them. Labels are created once and then linked to the post as needed; names must be created in all the languages enabled for the blog.
Posts can be grouped by category, making the category a main classification. For example, a cookery blog can have one category for posts with vegan recipes, another for posts with recipes for desserts and so on. A post can belong to more than one category (the mechanism is similar to that used with products in the Commerce and their categories). It is advisable to display them so that the user can filter posts by category and see all the ones associated with them.
Blog categories can have filters applied to them for users, groups of users, countries and areas. Then, as it normally happens, the visibility of posts depends on the visibility of the categories that contain them. For example, if a particular category is filtered for a "VIP" group of users, only users who belong to this group can see the posts included in the category.
As posts can belong to more than one category, there is a main category, which is the one that contains the "original" post. If the post is included in several categories, this does not mean there is more than one copy of it, but that there is a symbolic link to the original post (similar to the shortcuts to applications or documents on computers). In short, only one actual post exists, and it is in its main category; the rest are shortcuts created in other categories. Note that if a post is included in two categories and one of them has a filter applied to it but the other does not, the user will be able to view the post only if the main category is the visible one. If the filter hides the main category, the post will not be displayed.
Posts can have items related to them. These are often products or categories in the Commerce's catalogue, news or banners relevant to the content. In addition, other posts or categories of posts can be associated with them. When a user accesses a post, the system can return the items (of any of the kinds listed) related to this post.
For example, a post explaining a recipe could include related items from the Commerce that serve to make it, such as utensils or the different ingredients. As these items are included in the page with the post, it is highly possible that the user will look at some of them through the link provided and end up buying them.
As mentioned above, users can subscribe to a blog, to blog categories or to posts. The subscription mechanism is associated with a background process controlled by the system that regularly checks whether any notifications need to be sent.
If a user subscribes:
To the blog: The system sends a new post notification when a blogger publishes a post in any category.
To a blog category: The system sends a new post notification when a blogger publishes a post in the category to which the user has subscribed.
To a post: The system sends a new comment notification when a comment is published in the post to which the user has subscribed.
The system has two templates for blog notifications: one for subscribers to the blog and to categories in it, and another for subscribers to posts. The notifications, which are sent by email, include wildcards to insert a range of information. These are the wildcards for the blog notification templates:
%blogName%: Name of the blog, as defined in the blog configuration
%itemType%: Type of element (this can be blog, blog category or post)
%itemName%: Name of the element (title of the blog, category of the blog or post)
%blogLink%: Link to the blog
%linkDeleteSubscription%: Link to cancel a subscription to the blog
%CommerceName%: Name of the Commerce
%CommerceURL%: Link to the Commerce
%imagesURL%: Route to the image server
%CommerceLogo%: Link to the Commerce logo
<!-- %loop% -->: Start of repeated block
%postSmallImage%: Small image of the post
%postLargeImage%: Large image of the post
%postPublicationDateTime%: Date and time of publication of the post
%postPublicationDate%: Date of publication of the post
%postPublicationTime%: Time of publication of the post
%postName%: Title of the post
%postShortText%: Summary of the post
%postContent%: Content of the post
%postSmallTitleImage%: Small image of the title of the post
%postLargeTitleImage%: Large image of the title of the post
%postLink%: Link to post
<!-- %/loop% -->: End of repeated block
It is advisable for users registered with the Commerce to be able to see and manage their subscriptions to the blog, to the different categories and to posts, in a subscription section in the web presentation user panel. Commerce managers can also see subscriptions in the BackOffice, specifically in the subscription section included for each user.
Verification of Email Addresses
Verification of the email address is an optional additional check before allowing users to leave comments; this only affects registered users. When a user wishes to leave a comment on a post, the system acts as follows:
(a) If the function is enabled in the blog, it first checks that it is also enabled in the Commerce. If so, it checks that the user email address is verified. If it is, it does not ask for any further verification.
(b) If the function is disabled in the Commerce or it is enabled but the address is not verified, the system sends an email message to the user with a link to a page where they can verify it.
If the blog is expected to receive a lot of comments and replies, it might be worth enabling verification of addresses in this tool. In this way, the Commerce manager can ensure that comments are of high quality and helps them to reduce spam.
Users can cancel their subscriptions in two ways:
Registered and anonymous users: Through the link included at the end of the notification message, which points to a page where they can cancel their subscription. This is the only way anonymous users can cancel a subscription.
Registered users only: Through the subscription section of the user panel in the Commerce web presentation. Here they can see all their subscriptions and cancel them directly. For this reason, among others, it is recommended that you include this section in the user panel.
Comments and Ratings
Depending on the settings specified, either registered and anonymous users or else registered users only can comment on posts. All comments are moderated and only those that have been approved will be published. As they are not published immediately, it is important to inform users of this with a message that appears after they send the comment, indicating that their comment has been received and will be published shortly. For a comment to be published, it must be marked as reviewed and accepted. If it has only been reviewed, it will not be visible.
If anonymous users can comment, they will only be obliged to give a nick. If only registered users can comment, they must give a nick and their email address. Also, to track the number of comments sent by each user, the comment and the user's IP are sent to the system.
Comments can have replies. Replies are handled in the same way as comments, with the difference that they are displayed linked to comments (i.e. they are under the relevant comment). As replies can be nested, they can have successive replies. It is advisable to display this nesting on different levels or with differentiated indexing. Once published, replies also trigger a new comment notification.
Ratings, Likes and Dislikes
Posts can be rated from 0 to 5. They can also be liked or disliked, which is a different way of rating them. Based on these assessments, the system can be asked for the highest-rated posts or those with the most likes or dislikes.
Each post can only have one rating, one like or one dislike per user, and only registered users can give assessments of these kinds. Therefore, ratings, likes or dislikes posted are recorded with the user in question. This helps prevent manipulation of the post's reputation.
A user can only delete likes or dislikes they themselves posted. If they tried to delete another user's likes or dislikes, the system would return an error message.