A Blog is Not Ideal for Vridar Posts

Creative Commons License

This work is licensed under a Creative Commons Attribution 4.0 International License.

by Neil Godfrey

Now that I am almost two-thirds of the way through the first round (of 3 to 4) of categorizing and tagging my 3700+ posts here it has become painfully apparent to me that a blog is not the appropriate storage area for many types of posts.

The blog allows for labelling content by categories and tags. Categories are broad conceptual terms while tags are for the many details. I have come to see that this classification system is designed to show readers what sorts of content is mostly found on a blog. That’s all very fine for some purposes, I am sure, but it is not what I want. My problem is that I have an “information science” background and I want to have a system that allows users to see fairly easily and quickly if there is a post here that might be of use to them. The categories and tagging system does not serve that purpose. It only (more or less) tells viewers the main biases of broad conceptual content that dominates a blog. Not the same thing by a long shot.

Categories and tags are fine for alerting web crawlers to what’s what when comparing or harvesting info from different sites, but they are not very useful for alerting viewers if there is something here that is of particular interest to them.

Some people have urged me in the past to separate my political content from my biblical posts so that I run two blogs. Ironically, it is the political side that lends itself more easily to the categories and tagging controls. A political blog focuses more on regular updates and is the sort of thing a blog is designed for. Though I also like to do background research posts on certain political issues and once again those sorts of posts are not ideally placed on a blog.

I am beginning to think that I ought to move, copy or somehow at least link the bulk of my and Tim’s posts to a static website instead — at least one which opens with a clear table of contents that narrows down to multiple indices.

I did have in mind a Topic Map (TAO) — I thought that would be ideal: it would, I thought, enable all sorts of cross-searching of terms, linking concepts, drawing out all sorts of answers along with related possible spin-off options. But I see that Topic Map technology has passed me by and is no longer a bee’s knees thing. I am out of touch and must catch up to see if there is a stable replacement yet available.

But that’s not going to happen before next week, maybe more than a year, even. My first task is to complete the first round of doing a “rough and ready” classification of posts with a crude category and tagging system. It will have many overlapping and grey areas but those will be refined in future iterations and refinements. Going on to 4000 posts is a lot for one person to sort through, but it has to be done, and no point putting it off any longer — as I have been doing for too long already.



The following two tabs change content below.

Neil Godfrey

Neil is the author of this post. To read more about Neil, see our About page.

Latest posts by Neil Godfrey (see all)

If you enjoyed this post, please consider donating to Vridar. Thanks!

24 thoughts on “A Blog is Not Ideal for Vridar Posts”

    1. “PmWiki”. Wikipedia.

      PmWiki is designed to be easy to install and customize as an engine for creating professional web sites with one to any number of content authors.

      “PmWiki | PmWiki / PmWiki”. http://www.pmwiki.org.

      PmWiki pages look and act like normal web pages, except they have an “Edit” link that makes it easy to modify existing pages and add new pages into the website, using basic editing rules. You do not need to know or use any HTML or CSS. Page editing can be left open to the public or restricted to small groups of authors.
      Access control: PmWiki password protection can be applied to an entire site, to groups of pages, or to individual pages. Password protection controls who can read pages, edit pages, and upload attachments. PmWiki’s access control system is completely self-contained, but it can also work in conjunction with existing password databases, such as .htaccess, LDAP servers, and MySQL databases.

      “PmWiki | Cookbook / BlogIt”. http://www.pmwiki.org.

      BlogIt provides an easy to setup blogging system, based on PmWiki, providing similar functionality to other major blogging platforms. BlogIt includes blog entry, blog management, comment entry and approval, and comment management, and comes with pagelists providing most features provided in other blog systems. Additional features like ping-backs, notifications, and tag-clouds, can be added using existing cookbooks.

      1. “How to Export a WordPress site to Static HTML”. qSandbox Blog. 9 October 2018.

        [Y]ou may want to consider converting your WordPress site into a static (HTML only) one. When you do that you can load the site locally on your computer…

        • Since a Wiki does not fully support “HTML tags” but rather “wiki markup”, there is a possible conversion issue.

        “PmWiki | Cookbook / ConvertHTML”. http://www.pmwiki.org.

        ConvertHTML implements a relatively comprehensive set of rules for converting HTML tags to wiki markup. However PmWiki markup does not support all HTML markup [tags] —so a 100% conversion may not be possible.

  1. Well, I’ve more or less completed the first stage of properly organizing the 3715 posts now. When I see a mess to be cleaned up my approach is usually just to drag everything out and dump it in one big pile so I can start with a clean space and then put back from the pile bit by bit or chuck bits out.

    I’m about to start that second stage now. That means first of all working on a way to bring some sort of consistency to the tags or subcategories that need to be made into tags. Wheh!

  2. It’s the nonhierarchical and alphabet order (as opposed to some sort of conceptual/ontological order) of the tags that bugs me. I am too used to working with standards of information control that have emerged through years of standardization — but this is the internet age and i know i need to adapt, damn it — at least do the blog thing according to proper blog ways for now.

      1. The hard part I am facing at this stage is establishing consistent and useful tag terms – not so easy across such a large number and range of posts. Once the terms are worked out the rest will be easy by comparison.

        1. I think at a reasonable pace, allowing me to have a sort of normal life in the real world, this task will take me about a year to complete. I’ve measured what’s involved and I’ve made a year my target date. Let’s see what happens.

  3. “Categories”. WordPress Support.

    Categories can only be added to Posts, but not Pages. If you’re looking to categorize your pages, use Tags. If you want to nest pages under other pages, use Page Attributes → Parent Page in Documents Settings for that page.

    “Tags”. WordPress Support.

    Five to 15 tags (or categories, or a combination of the two) is a good number to add to each of your posts.

    “Best Practices For Using Categories And Tags In WordPress”. Elegant Themes.

    Remember, categories are like your blog’s table of contents.

     • DO consider using sub-categories to organize more complicated, hierarchical topics. WordPress allows up to three levels of categories.

    Use tags like the index of your blog.

     • DON’T use tags that are just duplicates of your categories. They’re already linked together, so there’s no purpose to this. Tags should be more specific than categories.

     • DON’T use too many tags. How many tags are enough? Again, there’s no right answer for every blog. You’ll find answers all over the place, from 2-3 per post, to 30 or more. Just try to be consistent for each post…

    “How (and Why) to Convert WordPress Tags from ‘Flat’ to ‘Hierarchical'”. CSS-Tricks.

    [T]he ability to do parent/child tags in WordPress can be useful. But, you’ll have to do some work if you want to do it, since WordPress doesn’t offer this by default.

    […] in this article I’ll explore how (and why) to convert standard “flat” WordPress tags into a hierarchical, category-like format.

    When it comes to the front-end user navigation and use of tagged articles, there won’t be a visible difference.

    On the back-end, however, you can begin to build an understandable, readable, and manageable library of tags.

      1. WordPress dev here. Not sure if you missed the bit in db’s post at the end where it shows how to /change/ WordPress Tags to be hierarchical.
        Once you have categorised and tagged (perhaps with nested tags as per db’s tip) posts to your liking, you can pull them out of the database either statically (hand write lists of links to posts) or dynamically (by tag or category) to make what looks more like a static website.
        There is no requirement in WordPress to organise content by date. The option is always there to present your information by topic. In fact you can do both, at once, with the same set of data.
        There is absolutely no need to make a static website, and it seems to me that that considerable effort would be a waste. It is simply a matter of changing the presentation of the information you already have. WordPress can do it.

        1. Custom fields
          There is also a custom fields option in WordPress, which allows you to add arbitrary text data fields to each post.
          A plug-in called ACF (‘advanced custom fields’) is what devs most use to easily create and organise this data.
          You can then use this data in the back end (e.g. use it as an add-on to categories and tags, perhaps by designating posts as being part of a series) or front end (by displaying the data directly on the page).

        2. Hey, I was overtired with recent comments. Approaching it fresh today and it won’t take long using the batch edits instead of going through each post one by one, stupid me last night. My main issue is deciding the appropriate terms right now, and deciding on parameters that each category should cover

  4. Have you considered a searchable database affiliated with your site. Find what you are looking for in the database and then search for it on the site by title.

    We do this crudely with a searchable text file of all of the issues of our magazine.

    1. • The WordPress back-end database is accessible by admin.

      “WP_Query Arguments: Categories and Tags”. Code Envato Tuts+.

      Querying your posts by category and/or tag is something there’s a good chance you’ll have occasion to do with WP_Query. By using the arguments above, and combining them where necessary, you can create powerful arguments to extract exactly the data you need from the database.

      • Ideally the WordPress front-end would feature a plugin for a reader’s SQL query (per post: tag; category; keyword; etc.) that returns matching posts.

      1. “Include Category and Tags in the WordPress Search”. rfmeier.net. 2 August 2013.

        By default, a search in WordPress will only search a post’s title and the post content. Using WordPress filters, it can be extended to include taxonomies, such as categories and tags.

        Download The Plugin @ Meier, Ryan (22 May 2019). “A simple WordPress plugin to include taxonomies within your WordPress post and page searches.: rfmeier/simple-taxonomy-search”. GitHub.

    2. That’s another option to consider. I rely on similar processes regularly, but I think there are certain weaknesses that concern me with systems that are strong and good in other areas. Still thinking, thanks.

  5. • If the blog is exported to static html and then uploaded to a standard html web server. It is possible that the WordPress tag and category info may lost.

    A solution is to manually append an XML string to the blog post/page. The XML string would recapitulate the WordPress tag and category info and since it would be exported as part of the page. Then it could be used by a program to create a tag and category page on the new web server.

    NB: In theory, this would also allow a program to create a tag and category page by crawling all the posts on the current blog.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Discover more from Vridar

Subscribe now to keep reading and get access to the full archive.

Continue reading