This plugin adds XHTML META tags to your WordPress blog. The addition of the META tags is fully automatic , but it also includes all those features a SEO-concerned publisher would need in order to have total control over those meta tags.

The features at a glance

The following list outlines how and where META tags are added to a WordPress blog by this plugin. Please note that this list does not provide all the details you need to know about how to customize the added metatags. Its purpose is to provide a general idea of what this plugin supports. For detailed info, proceed to the next section.

• Front Page
  • Automatically.
  • Customization is possible from the plugin’s configuration panel.
• Single Posts
  • Automatically. (On WordPress v2.3 or newer tags are also used in addition to the post’s categories)
  • Customization of the “description” META tag:
    • either via custom excerpt
    • or via custom field (note that this overrides the custom excerpt).
  • Customization of the “keywords” META tag via custom field only.
• Static Pages
  • No automatic generation of meta tags.
  • Customization is possible with custom fields like it can be done in posts.
• Category Archive Pages
  • The description of the category, if set, is used for the description META tag. The name of the category is always used at the keywords metatag.
• META Tags on all pages
  • It is now possible to set any other META tag, which does not require any computation, to be added to all blog pages.

Here follow all the details about how this plugin works.

Features – How to use it

The simplest way to use this plugin is to activate it in the WordPress administration panel and forget about it. At this basic level of usage, it automatically adds the “description” and “keywords” META tags to the front page and to single post view, which, of course, can be customized in the ways outlined below.

META Tags on the Front Page

By default, the blog’s tagline (Options->General) and all the used categories are being used automatically as description and keywords for the meta tags on the front page. These can be overridden by setting a custom description and keywords for the front page in the plugin’s configuration panel (Options->MetaTags).

The description and keywords defined in the plugin’s configuration panel have higher priority and, if any of them is set, it will be used instead of the automatically calculated respective metatag.

META Tags in Single Posts

In single post view, the post’s excerpt and its categories and tags (tags are supported in WordPress 2.3 or newer) are automatically used as description and keywords. While editing a post, it is possible to define a custom excerpt. If this excerpt is not set, then the description is calculated from the post itself. This calculation is based on the following:

1. the plugin tries to use the first complete sentences of the post, if possible.
2. it also tries to keep the calculated excerpt at a length around 250 characters. As you can guess, this cannot be always achieved, so I’d say that the calculated description will be about 150-350 characters.

This automatic behaviour can also be overridden, by adding custom fields to the post. Note that the custom fields have the higher priority and, if set, their values are used in the META tags.

The contents of a custom field named description will be used in the description META tag instead of the post’s excerpt.

Contrariwise, a custom field named keywords can contain a comma-delimited list of keywords, which will be used in the keywords META tag instead of the post’s categories and tags. It is still possible though to quickly include the post’s categories and tags to this list by using the words %cats% and %tags%, which are replaced by the post’s categories and tags respectively when the page is displayed in a browser.

For example, when the post’s categories are not enough and tags are not enough for you, you can add a custom keywords field to the post, and add the extra keywords you want together with %cats% and/or %tags% :

keyword1, keyword2, %cats%, %tags%

This makes it possible to adjust and optimize the post’s keywords without having to create a huge number of blog categories and tags.

META Tags in Pages

It is possible to add the description and keywords meta tags in WordPress Pages by assigning custom fields to each page as it was discussed previously for posts. Pages do not belong to categories in WordPress, so metatags will not be added automatically without using custom fields. Also, the tag %cats%, if used in the keyword list, will not be replaced by any categories.

META Tags in Category Archives

Finally, META tags are automatically added to category archive pages, for example when viewing all posts that belong to a specific category. In this case, if you have set a description for that category, then this description is added to a “description” META tag.

Furthermore, a “keywords” META tag – containing only the category’s name – is always added when viewing category archives.

Installation

Extract the compressed package in a temporary directory and copy the add-meta-tags.php file in your /wp-content/plugins/ directory and activate the plugin in your administration panel (Options->Meta Tags).

As it has been mentioned, no configuration is required for the plugin to function. It will add meta tags automatically to the front page and to each post in single post view.

The administration page (Options->Meta Tags) contains all the information that was mentioned in the previous section, so you can access it quickly.

License

Add-Meta-Tags is an open-source project, released as Free Software under the terms of the Apache License version 2.

Downloads, Issue Tracking, Support

For the latest releases of Add-Meta-Tags please visit the downloads section of the Add-Meta-Tags Development Portal.

The development website also hosts an issue tracking facility, where you can submit your feature requests or report bugs, and discussion boards, where you can get first class support from the community of users.

Translations

Add-Meta-Tags is ready for localization.

Generally, the installation of the translation file involves copying the mo file in the plugins directory, where add-meta-tags.php exists.

Translation files are hosted by their authors and are distributed separately from the main plugin.

Currently available translations:

• Japanese Translation by coliss – This is the translation of the 1.6 version of the plugin.

A huge thanks to all for your work.

Donate

This plugin is released as free software. Nevertheless, its development requires time and effort. A small donation, as a sign of appreciation of the effort, is welcome. Please, use the following button to visit the Donations page. Thanks in advance for your support!

Other Info

This page had become the heaviest page on this web site (>120kb), so some sections have been removed to save some space and bandwidth.

The list of contributors has become too big for this page, so it has been moved inside the distribution package (file THANKS).

The changelog has been removed and is included inside the distribution package (file ChangeLog).

The comments can be found at the Add-Meta-Tags Legacy page.

Thanks for your understanding.

Add-Meta-Tags WordPress Plugin, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Today, I stumbled upon the following links, which seem to be what could get someone started with LaTeX. Andrew Roberts has done an exceptional job. His tutorials cover topics both for the absolute beginner and the medium experienced user. This is a must read! Actually, I found out about the above tutorials by this post, which contains an example of a book in LaTeX. Very interesting information.

LaTeX links for the absolute beginner, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

G-Loaded! has always been a supporter of the Atom Syndication Format, more specifically of the Atom 1.0 Specification, because of its flexibility and extended features. Although this specification has been around for quite a while now, it has not been fully adobted by the major web indexing services or by popular web applications yet.

As you might have noticed, the Atom 1.0 feed link had been the first to be displayed among all of my feed links and, also, the first to be included in the web site’s HTML HEAD area, thus making it the default choice when external software tried to automatically discover the link for the site’s syndicated content. Moreover, about a year ago, I had published the article Design the perfect Atom feed for WordPress, which guided the wordpress user in order to convert wordpress’ Atom 0.3 feed to the latest 1.0 specification and how to enhance it with various features.

But, the arrival of WordPress 2.1 left me no choice. The support for the Atom 1.0 format, although planned for this release since a long time ago, has probably been dropped. Apart from this, Google Webmaster Tools and Yahoo Site Explorer, which are two services I use often in order to check the status of this web site, still do not support Atom 1.0, but the old and deprecated 0.3 specification instead.

For all these reasons above – and a couple of minor others not mentioned here – the default feed format for G-Loaded! is RSS 2.0. Feed discovery should return this feed from now on in your browsers and other feed readers. Also, the link to the Atom 1.0 feed has been removed from the website pages. Of course it will remain active, but I strongly suggest that you use my RSS 2.0 feed.

This change will be permanent.

And the winner is: RSS 2.0, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Despite the third version of the GPL being released (read the GPLv3 legal code), all software, which has been published and hosted on G-Loaded.eu and is subject to the terms of the GPLv2, remains under its current license (GPLv2) until further notice. This is not because I consider the 3rd revision of the license as bad. I just believe it has less value than v2 for the following reasons:

1. The GPLv3 seems like it has been primarily written with the FSF’s business-world wars in mind and not the adaptation of free software to our world.
2. The GPLv3 seems like it has been written with a dream world in mind and not the real world conditions. An example: medical devices, security devices etc, which may use embedded free software, must be fully hackable by design… At this point let me wonder if we all live on the same planet after all… (Seriously, what is the matter with you people? The world is _not_ only about multimedia players, network devices and document formats!). [Update: also, read my comment about this license condition.]
3. The GPLv3 seems like a first step in an attempt to adapt the world to the free software principals, while, IMHO, we should move towards the exact opposite direction, aka adapt free software to our world.
4. The 3rd revision of the GPL has become a bit restrictive, so it is only a matter of time until someone manages to legally bypass those restrictions. So, I predict that v3 will not last for as many years as the 2nd revision has lasted. I dare to state that it won’t last more than 5 years.

In short, I would say that while GPLv2 is a diachronic license, v3 includes some restrictions that reflect the current times, therefore, even if it might have great value as a license today, it is almost certain that it won’t be that valuable in the upcoming years, as things in the software industry change rapidly.

Anyhow, despite all the above “reasons not to like GPLv3“, I will probably re-license all the released GPLv2 code to GPLv3 at some later time. Honestly, it is of little importance to me if it is GPL v2 or v3.

Moreover, I may try to use some other license as my main license for future code releases. I must admit that I am very attracted to the Creative-Commons licenses. This will depend on numerous factors, which I won’t outline at the present time.

You can read a series of quality comments about the GPLv3 in this comment thread on OSnews.

What I would like to write as a conclusion is taken from the aforementioned comments:

v2 is about “can’t we all just get along?”; v3 is about “no, we can’t”

PS: Comments are on, but I will not be following the discussion for the following days due to other obligations. Feel free to write your opinion, but do not expect any answer soon.

GPLv3 is out – The G-Loaded.eu views, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Recently, I had written a post about WordPress 2.2.1 always delivering full content with the author feeds, ignoring the publisher’s settings. I deliberately had not disclosed much information about the issue, not because it was security related, but due to the fact that it could make the content leechers’ job easier and cleaner. Now, that the WordPress developers have come up with a solution, I’ll post the details about the problem and the way to fix it.

Here is the ticket on the WordPress bug tracking system. (my initial bug report deserves a prize, don’t you think?)

But first, a few things about the author feed. It is well-known that WordPress can create a feed for almost any type of content. The author feed contains all the content that has been published by a specific author.

Starting with WordPress 2.2, all the feed generators have been moved into wp-includes, but the old files, like wp-rss2.php, still exist in WordPress’ root directory for backwards compatibility. It seems that when an author feed is requested by using those old files, the generator ignores any settings about delivering or not full content and, eventually, the feed contains the published content in its entirety.

For example, assuming that an author’s ID is 1, the following URL returns a feed with all content posted by that specific author:

http://example.org/wp-rss2.php?author=1

The resulting XML file contains full content (you won’t notice any difference if you deliver full content in your feeds by default!).

At this point, I must clarify one thing. None of the WordPress template tags returns a feed link that points to any of the old feed generators. So, it is impossible, even for an old theme, which of course makes proper use of the template tags in order to print the feed links, to print links like the one above.

On the other hand, a content leecher could very easily guess an author’s ID and craft such a URL in order to retrieve the full published content in a clean form like it exists in the feed.

Anyhow, the fix is to delete all those old feed generators from the WordPress v2.2.1 root dir:

• wp-atom.php
• wp-commentsrss2.php
• wp-rdf.php
• wp-rss.php
• wp-rss2.php

This will not affect your feeds.

Note, that, if you use permalinks, URLs like the one above will probably still work even after you delete those files, but this time they do not ignore the user settings regarding the amount of content that is delivered within the feeds. It is quite strange how they work properly this time, but, fortunately, this is how it is.

Generally, this issue is not an important one, but I think you should know about it, especially now that a fix is available.

Issue addressed: Author feeds deliver full content, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

I am nowhere near being an authority on software licensing. However, the recent release of GPLv3 with all the online discussions, all the attempts to exploit statements of the old version 2 of the license in order to achieve automatic license renewal for all the projects that were released under GPLv2 made me re-evaluate, not only the license itself, but also the methodology that should be used when licensing even a single line of code.

Here folows a list of what I believe are the best practices when licensing software:

1. Study the license’s legal code; not just read it, study it. It contains the terms under which your software will be released. Never let trends interfere with the selection of the license and, of course, make sure you do not choose a license just because you think you cannot find a more suitable one. Note that, when it comes to software licenses, the point of no return is the release of the software. If you change your mind about the license after a version of the software has been released, then it is impossible to invalidate previously released versions. Anyone, who has obtained a copy of the software with the old license, will be able to use it according to the terms of that license.
2. Include a copy of the license inside the distribution package of your software. Also, keep a local copy of the license on a web site that you fully control and link to it when necessary. If you have to link to the license’s original web page, make sure you use a URI that includes at least the name and version of the license, eg .../gpl-v2.html. Avoid linking to URLs that might be redirected to different documents over time. For example, a URI like .../gpl.html will probably be redirected to the latest version of the license whenever the latter is released, so it might bring confusion to the users of your software or to developers who wish to use the code. If the organization that issues the license has taken care, so that the license URI contains the license name, version and the general rights – like it happens with the Creative Commons version 3 licenses -, then I guess it is safe enough to use such URLs for linking.
3. Keep in mind that you, the developer of the software, are the one who will decide the terms under which the software will be released. If one of the existing licenses is satisfactory enough, then it is highly recommended that you use it. Otherwise, feel free to modify one of those licenses by adding or removing conditions in order to create a license that suits your software’s needs.
4. It is highly recommended that you remove any statements that expressly state or imply the automatic renewal of the license when a new version of it is released. Such statements can lead to serious trouble and confusion. Automatic license renewal is irrational when it comes to computer software. [Update: it is suggested to include a notice which indicates the removal of such statements inside the software's distribution.]
5. Software that is released under the General Public License (GPL) is free open-source software. On the other hand, software does not have to be released under the GPL in order to be FS/OSS. If your software is meant to be FS/OSS, there are numerous licenses that can be used in order to give your users the necessary rights to use, copy, distribute, build on it etc. See the OSI approved licenses by category.

This list may not be complete, but it outlines some general rules that can be followed in order to avoid getting into trouble with your software’s license.

Best Practices of Software Licensing, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Today, I noticed that it is no longer required to escape the backslash (\), known as the “escape character” on *nix systems, inside the pre HTML tag in order not to be removed by WordPress’ HTML filters. This bug has lived long enough to be considered as a WordPress feature, but the devs have suddenly decided to address it. So, no more pain when using the escape character inside pre tags. Good!! But, what happens to the code that has already been published with escaped backslashes? WordPress is one of those free software projects which leave some really difficult homework to their users from time to time. So, here follows my solution.

After you have upgraded to the latest WordPress version, 2.3.1 at the time of writing, create a dump of your WordPress database:

mysqldump -u wpuser -p --opt --databases mywpdb > mywpdb.sql

After the database has been dumped, those backslash pairs in your posts’ data would appear as four (4) backslashes in the MySQL database dump. This is because this file contains the raw strings of your data.

To get an idea about what a raw string is, launch the python interpreter and test the following:

>>> "string with escaped backslash \\"
'string with escaped backslash \\'
>>> r"raw string with escaped backslash \\"
'raw string with escaped backslash \\\\'

All the above python-thing is not required at all, but it is good to know what really happens. As you can see, the escaped backslash is represented by four backslashes in the raw string and this is how it has been written by mysqldump in the mywpdb.sql file.

All you have to do in order to repair all that code, while leaving all non-escaped backslashes in place, is to use a good text-stream editor, like sed in the way presented below.

Assuming that you have kept a backup of the dump, use sed to repair it in-place:

sed -i 's/\\\\/\\/g' mywpdb.sql

You can now import the repaired dump back into the MySQL server and replace your data with the corrected one.

mysql -u wpuser -p mywpdb < mywpdb.sql

Your previously escaped backslashes should now appear as single backslashes in your posts, but displayed correctly by WordPress.

I haven’t noticed any problems after performing the above operation. It might not work for you though. Use at your own risk.

If I miss anything, please let me know.

Backslashes inside pre HTML tags in WordPress, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Moving the comments your readers have submitted under one of your blog posts to another one might sound like a horrible idea at first, but there are times, especially when the number of comments has increased too much, that such an action is required in order to reduce the page loading time. I am aware of plugins that can arrange comments in multiple pages, but I am against such solutions because they usually add lots of javascript to the HEAD section of the page, so in the end the page does not load any faster at all. On the other hand, it’s not that bad after all to kindly point your readers to a secondary blog post, which has been set up in order to host the discussions about the main post. This obviously should not happen at the release time of the post when the discussion might get hot, but rather at a later time, maybe after several months. Anyway, I am not here trying to convince anyone about the pros and cons of such an action. What I care about, as usual, is the technical part: which would be the most efficient way to move the comments from one post to another?

There are two ways that can make this happen. Each one has its advantages ant disadvantages as outlined below:

• By directly manipulating the WordPress database. This is the quickest and most professional way, but running SQL statements is not everyone’s cup of tea.
• The second way is not actually about moving the comments, but rather about moving the post itself out of its comments. This is the simplest of the ways and requires zero knowledge of SQL.

Both ways are very safe.

The SQL Way

First of all, create a new post as usual and add any amount of content in it. What you will do is to attach the comments from the old page to the new one.

You will need to know the IDs of your new and old posts. It might not be possible to determine the post ID from the post’s URL as it might not be included in the permalink structure you use. In that case, examine the hyperlinks of the posts in question under the “Manage menu” in the WordPress administration panel.

In the following SQL queries, substitute OLD_ID and NEW_ID according to your posts’ IDs.

Transfer the comments with the following statement:

UPDATE wp_comments SET comment_post_ID=NEW_ID WHERE comment_post_ID=OLD_ID;

That’s it. The comments have been transfered, but we are not done yet.

WordPress keeps the number of each post’s comments hard-coded into the post’s record. This probably serves as a performance booster, but it is necessary to take care of it as well.

Run the following query and take a note of the number in the output. This represents the number of comments under the old post.

SELECT comment_count FROM wp_posts WHERE ID=OLD_ID;

Assume that the numeric result is COMCOUNT.

Then adjust the hardcoded number of comments under the two posts by substituting COMCOUNT, NEW_ID, OLD_ID in the following statements as appropriate:

UPDATE wp_posts SET comment_count=comment_count+COMCOUNT WHERE ID=NEW_ID;
UPDATE wp_posts SET comment_count=comment_count-COMCOUNT WHERE ID=OLD_ID;

You are set.

The WordPress Way

This is called the “WordPress way” because everything takes place within the WordPress administration panel. The general idea is to create a new post identical to the old one and change the old post, which actually has the comments, appropriately so that it is considered as a new post by WordPress.

1. First of all, create the new post and add content as appropriate.
2. Second and most important, take a good note of the old post’s “Title“, “Post Slug” and “Post Timestamp“.
3. Edit the old post‘s “Title“, “Post Slug” and “Post Timestamp” (make sure the “Edit timestamp” checkbox is checked) to some new values and save it.
4. Edit the new post‘s “Title“, “Post Slug” and “Post Timestamp” to the exact values of the old post (remember the note you had taken?) and publish it.

Done.

Conclusion

This is not a task WordPress users have to accomplish everyday. But, when there is need for it, you will know how to do it. Both ways are safe and complete. Use the one that suits you better.

Move comments to another post in WordPress, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

If you’ve tried out several wiki engines, you have probably noticed that the developers of each of them have invented their own wiki markup language. I guess no-one has a problem with that. It’s a free world after all. However, all these different versions of markup languages easily become a pain when you have to submit content to several different wiki engines. For instance, Wikipedia, various popular bug trackers, wiki engines dedicated to projects like Ubuntu are all very popular wikis, but, unfortunately, the contributor has to learn several different markup languages to be able to submit rich content to all of them.

I admit that I’ve always been frustrated by this situation. But, fortunately, there is some light. The Creole Project is an effort to create a standard wiki markup language using democratic procedures. The goals page reveals that this project is serious and will finally deliver something useful to humanity. The Creole 1.0 specification has been completed, but some work is still being done on several (necessary in my opinion) additions.

I think everyone who is interested in collaborative content should be happy about Creole. This is for the benefit of both the projects and their contributors because a standard wiki markup language promotes productivity. I think the language still needs more official additions, but I guess this is just a matter of time.

I got the impression that the Creole Project deserves more popularity, so I wrote this small post for all of you who might have never heard of it. It would be nice if you did the same!

Creole – Standard Wiki Markup Language, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.