VoxPelli

Seems like I got the wrong line number – the correct one would be 134 and the if-statement to be prepended would be this one:

if (!isset($row['include_children']) || $row['include_children'] == true) {
	if (!is_array($term_id)) {
		$term_id = array($term_id);
	}
	foreach ($term_id as $t_id) {
		$kids = get_term_children($t_id, $row['taxonomy']);
		foreach ($kids as $kid) {
			$term = get_term_by('id', $kid, $row['taxonomy']);
			$term_tax_id[] = relevanssi_get_term_tax_id('id', $kid, $row['taxonomy']);
		}
	}
}

Direct link to relevant code: https://plugins.trac.www.ads-software.com/browser/relevanssi/trunk/lib/search.php#L134

@corelgott: Your theme needs to include the wp_footer() method to have the javascript printed as it’s for performance reasons included at the end of the page. The included script should then look like:

<script type="text/javascript">
  (function() {
    var s = document.createElement('script'), t = document.getElementsByTagName('script')[0];
    s.type = 'text/javascript';
    s.async = true;
    s.src = 'https://api.flattr.com/js/0.6/load.js?mode=auto';
    t.parentNode.insertBefore(s, t);
  })();
</script>

For future reference, as discussed on Twitter: This was caused by a bad change on Flattr.com regarding how we dealt international domain names there. Fixed there – no need to do anything with the plugin for it to get working again.

You should see a Flattr-option in the admin menu and on that page you should be able to enter the username of your account.

See this screenshot: https://skitch.com/voxpelli/8644f/flattr-wp33-test-wordpress

I have a hard time grasping what may cause a bug like this – the code looks correct and seems to be working for most and not fail as critically as in this case.

Could it be that you’re experiencing the same issue as reported in https://www.ads-software.com/support/topic/plugin-flattr-short-tags-cause-problems?replies=1 ? If so then it might be quite a big task to fix it everywhere but it would be something I would take a look out for the next bugfix release, which if I’m lucky I might be able to start on in two weeks time or so.

In version 1.2.0 there is now an option for making the entire blog flattrable and there’s a widget that one can include in the sidebar that contains a flattr-button for the whole blog.

New version is out – marking this as fixed.

Version 1.2.0 is out now and it now exposes a previously hidden setting that has a timestamp that posts has to be newer than to have the user specific buttons apply to them. Now one can change it in the settings through the “Limit to posts after” field and either leave it empty to disable the limit altogether or just change it to another date. This should fix this issue.

Version 1.2.0 have an option for disabling the escaping of a rel-payment links. I tried to reproduce the error for a long while this time and failed so this was the second best thing I could come up with.

Will mark this issue as resolved as now the ones with the issue at least don’t have to patch the plugin anymore.

I seriously can’t find any reason for this – another user reported the same or a very similar issue and I have spent most of this day trying to reproduce and debug the issue but I can’t find any reason for it really.

I think my solution for now will be an option in the settings for disabling the escaping of rel-payment links. Not a very nice solution, but at least better than for some having to patch the plugin.

I believe that I have found the cause of this – the plugin tries to get around a few errors that might occur when switching owners on already flattred things but it does this in a way that stops all old posts on a site from being assigned to anything but the site wide Flattr account.

I will make this work better in the next version that will be out very soon.

You can find user specific settings here: /wp-admin/users.php?page=flattr/flattr.php?user

The non-username settings doesn’t seems to be working that good right now, but that will mostly be fixed in the next version.

Found the reason for this – for some reason the plugin always initialized a session as the first thing it did. I can’t see any reason why it would do that and the commit where it was introduced didn’t give any reason for it either so it will be removed in next version.

Are you still experiencing this issue? We had a silly error on our side at Flattr.com where we were denying buttons that defined their language as en_US instead of en_GB and this plugin uses en_US instead of en_GB.

We have changed the behavior on Flattr.com to accept any unknown nationality of a language as the system default nationality for that language and thus buttons that had errors due to that will now work.

If you’re sure the Flattr plugin has something to do with it then I believe you and we of course should track the cause of that down!

Sorry if this might be a stupid question, but which cookie is it that you see set when the Flattr plugin is active? What’s the name of it?