This is the second part in a series of posts which should help you get your Drupal blog fully configured. Last week we covered a lot about multilingual settings and basic configuration. This week we'll continue to configure the site and discuss our choices for other options. There's still more to come. In addition to what we've covered so far, we will also be continuing coverage of tagging and vocabularies, creating views, creating feeds, and other tasks, some which will start to get into a bit of PHP. But this post, like last week's should be suitable even for people new to Drupal site administration. Please leave your comments and constructive criticism; we will follow up on them.

We have decided that we would also like "anonymous users" to be able to post comments on our blog posts, but of course we want to use some methods (e.g. CAPTCHA) to prevent excessive spam submissions. You'll need to allow anonymous users to post comments (in admin/user/permissions) before you can adjust the settings for anonymous comments here. If a user is anonymous, we want them to leave their contact details.
While the comment submission form can be most handy in the same
If the options for adjusting "Anonymous user" comment settings weren't available in the last step, and you do wish to allow anonymous users to leave comments, you can adjust your permissions to allow that. We've decided to allow anonymous users to "access comments", "post comments", and "post comments without approval," but of course we will not allow them the "administer comments" permission, which should be reserved for site staff.
There is a wide range of software which can be used to edit and upload blog posts with less trouble than one might have doing it in a browser window. Other benefits are that you can write your posts offline, e.g. while traveling on a plane or train without any internet connection, and finally publish them when you have completed any "draft stages" with no need to work with a clunky browser-based HTML editor, and no need to save drafts as "unpublished" nodes on your site, and then finally publish them.
For our needs, we probably only need to enable the Blog API for the "Blog Entry" content type, but you can upload via the Blog API to any content type on your site. Be aware, however, that many fields may not be addressable by your blogging software, so you will probably need to edit posts after uploading them, and manually enter values for some fields. And if there are required fields in the node creation form for a particular content type, and you can't address those fields with your blogging software, you won't be able to successfully post. This was why I, in the last post, elected to make the "tags" optional, even though we DO want to "require" them. Many applications which will use the Blog API might have trouble determining how to upload tags and we also want to use the checkboxes if a tag already exists.
In most cases, we might not need more than the 2MB maximum upload limit that's set in my local PHP configuration, but we might want to provide for larger uploads than that, and most certainly more than the 1MB allowed, by default, for uploads and for storage per user. A few screenshots in a tutorial post like this would break that limit, even if well optimized. You can fine-tune the file settings if your use case requires different limits for various user classes (roles) on your site.
Configuring your blogging software to connect to your Drupal site via the Blog API can be a bit of a task, depending on the complexity of the content types you are creating and the software you are using, and since there are many such applications to choose from, that step is outside the scope of this article.

/admin/settings/filters
Since we want staff to be able to include images in their blog posts and there might be other "sensitive" tags we trust them to use, for our use case it makes sense to allow using Full HTML as an input format for the Blog content. If you have bloggers on your site who are not employees or others you fully trust, you may wish to add another input format.
/admin/settings/filters/2
In our use case, we just need to check the box next to our new role, "author", to allow them to be able to use the "Full HTML" text format.
If you are setting up a multi-author blog on a site where you can't entrust everyone with such high privileges, you may wish to create a new input format and assign your "blogger" role ("author" on our site) to that input format. In that case, you might allow them a few more tags than the "Filtered HTML" input format allows. If you are creating a new input format, be sure to select the appropriate tags and filters to apply and order your filters appropriately (this task is complex enough, and not closely enough related to our current topic, that it won't be covered in this article).
For our use case, all blog posts should have a URL that begins with "blog/" then the node title. The Pathauto module, which is used on a lot of Drupal sites, including this one, allows us to set a pattern for the blog section of the site, which means that we can use that pattern to say that nodes with blog/* get a certain theme or will have certain other
Administer > Site building > URL aliases > Automated alias settings ( /admin/build/path/pathauto )
This might be a good time to mention that administering a Drupal site can be much easier with the Administration menu module installed and enabled. It can save you navigating through pages of administration and configuration pages and saves a lot of time in page loads.
It's super-easy to set up. You just need to turn it on and give permissions to your site administrator, and if you have the Admin role module turned on, the permissions part is automatic and any other user's given the "Administrator" role will also have the permission to use the Admin menu and administer anything active. The Admin role module is so useful and simple that it's now a part of Drupal 7 'core'.
In coming installments, we'll be improving on some of the basic settings we made here by adding and configuring other modules to help with our workflow, adding and configuring new input formats to allow us to enable special features for just the blog's text format, translating content and terms, and other fun stuff. If you're already more an experienced Drupalista, but just hadn't set up a Drupal blog before, you might be interested to know that we also plan to publish some more advance tips, including some aimed toward the "coder" community. Stay tuned…
Comments
Hello, everybody! I agree