Till's blog

First off — I don't have too much experience with disqus on Wordpress but when I looked at the code(-quality), disqus is one of the best plugins for Wordpress to date. I looked only very briefly, but I found it to be very clean, well documented and well architected. Good job, disqus!

In case you happen to dive into Wordpress plugins in 2012, you will see that this is unfortunately not a given. Even (or maybe especially) the commercially available plugins to extend Wordpress are a source for PHP worst practices and contain all kinds of examples how not to write PHP. Part of it, is the platform, the rest is unexperienced developers or general lazyness.

Anyhow! Enough the rant!

Disqus and the loop

In Wordpress, almost everything is a loop. If you'd like to display a list of posts somewhere (for whatever reason), a loop is executed. The advantage (vs. a straight SQL query) range from all kinds all things like caching to convenience. When said hook is used different actions (plugin hooks) and filters are run. So even when the objective is to just collect data (and not even display it) — for example for an Ajax request/response — all these things happen in the back.

So in this case, whenever a loop is used, disqus will attempt to add their JavaScript to it. Usually, to display a comment form, counts and what not.

Problem?

The problem is, that the JavaScript code is then added all over and especially with Ajax you end up with the same code multiple times but add to that the cost of transport.

Solution!

Here's a simple workaround to prevent that.

Stick the following code into your template when you do not want the code to appear:

<?php
if (has_action('loop_end', 'dsq_loop_end')) {
    remove_action('loop_end', 'dsq_loop_end');
}

Yay! Happyness!

Fin

Filters and hooks are really what make Wordpress worth while. Period. In case you happen to do development for it, I urge you to take a look at them. I have a couple more ideas for small posts — stay tuned.

Digressing from my usual grounds, I moonlighted a bit on a Wordpress project in September. One of the project's goals was to make the entire website bi-lingual: French and German (or the way around?). And once multi-lingual is an object, WPML is the plugin to use (as far as Wordpress is concerned).

WMPL in a nutshell

WPML is a commercial plugin — and as far as I am concerned: it's money well spend.

In case there's not a lot customization going, WPML works out of the box. For those digging a little deeper, WPML includes all these extra features and functions which are supposed to make life easier, but in reality, it doesn't always work out that way.

One example is rewriting queries to only show posts in the currently selected language. It only seems to work so far, or every once in a while. WPML's documentation is out-dated (or sometimes wrong), their forum is semi-useful (hint: you have to login to see anything useful) and so on. These last issues are especially sour for a commercial product.

icl_object_id()

One of the core features to make your theme work is the icl_object_id() function. It's supposed to take an ID (and a type) as an argument and should return the ID of the translation in the currently selected language. But add custom post types (a pretty useful plugin: custom post types UI) and it gets a little confusing.

It took me a while to find my way around it, so here's a small snippet to make icl_object_id() work with any post type.

Use case

There's an image.php in my theme (which is based on TwentyEleven), but we don't want a page dedicated to a single image.

Telling contributors of the website not to link to it only goes that far: the solution is to redirect the user to the article. Now add custom post types and a multi-lingual experience: Problem?

Not so much!

This is what we started off with:

<?php
wp_redirect(get_permalink($post->post_parent));

Hint, hint: Ugh... an extra SQL-query to get the permalink.

The above works if you don't use WPML. ;-)

Then we advanced to this:

<?php
/* image.php */
$parent = $post->post_parent; // this is the parent the image belongs to
if (defined('ICL_LANGUAGE_CODE')) { // this is to not break code in case WPML is turned off, etc.
    $_type  = get_post_type($parent);
    $parent = icl_object_id($parent, $_type, true, ICL_LANGUAGE_CODE);
}
wp_redirect(get_permalink($parent));

Hint, hint: Add one query for the post type, and who knows how many more in icl_object_id(). Finish off with the one for the permalink.

Step by step!

1. $parent is what the current post is associated with. E.g. this is an image, attached to a certain post. The post is its parent.
2. Then I get the post type ($_type) — if you don't run custom post types, this is likely post. But it could be anything.
3. icl_object_id() takes four arguments:
   • $parent: the current id
   • $_type: the type of object (e.g. post, category, post_tag, … or your custom post type)
   • true: failover to return the original if nothing was found
   • ICL_LANGUAGE_CODE: this is a constant introduce by WPML, it contains the current language (de, en, fr, ...)

Fin

That's all!

Not sure if anyone has watched this yet, but Matt's latest video contains important misconceptions about the GPL.

Matt says (5:22):

So a common misconception about the GPL is that, like let's say, I'm hired to make a theme for a client. Does that theme fall under the GPL? And the answer is, no! Because it's not being distributed. Uhm, when something is distributed it's available for download to the public, you're selling it in a store, you know, it's sort of mass-distribution. When you do something for one site, or just for yourself, like for example, the theme on my blog, it's just for one site. It's not being distributed in any way. The GPL doesn't kick in.

But the GPL kicks in.

First off, whenever you base your work on GPL code it becomes GPL. Matt also agrees on that (if you watch the entire video).

The questionable part is:

• Is distribution really a requirement? Or is it GPL right from the start?
• How do you define distribution?

First off, I could not figure out the distribution requirement, but if in doubt, I think it is not a requirement for your code to become GPL. This is indeed what a lot of people describe as a loophole in the GPL and this is why the AGPL was invented.

Furthermore, what Matt thinks distribution is ("available for download to the public, you're selling it in a store"), is wrong. It does not matter if the code is distributed given to a friend, client, your grandmother or someone riding the subway with you. It's always GPL.

What I agree on is, that the GPL does not force anyone to distribute their code, or changes to GPL code.

In the end, the bottom line is: When the code is given away, it is GPL — the license applies!

AGPL vs GPL

I've previously blogged about the differences of the GPL to AGPL. The fundamental difference is that when GPL code allowed anyone to make changes and they could keep the changes to themselves, the AGPL requires them to contribute those changes to the project. In today's world, and with the nature of most of the software and its environment, it's virtually impossible (or illegal) to not contribute them back.

Conclusion

In a nutshell — I believe even Matt's own theme is GPL. **The real misconception about the GPL is, ** that people think you have to give it away (for free).

The GPL really means that whenever Matt decides to give his theme away (for money, or for free), he will have to provide the full sources of it, etc.. So for example, Matt couldn't use an encoder to hide his secret PHP code and then offer it for download.

And that is all.