feedmeastraycat

Worked for me to.

Viktor: Nope.

Great. Thanks!

Alex: It might be with the proxy the plugin is using? (https://sopresto.socialize-this.com/twitter/authorize/)

The auth returns an error object about the plugin v1 being depricated (just like posted above) and the plugin doesn’t handle it gracefully and just adds a blank/error user. (Like this: https://d.pr/i/AxoS)

Yeah. I installed this today. ?? It’s not resolved. You won’t get away that easy Alex! ??

Having the same issue.

Hello

Im the author of Activate Update Service.

The plugin is reeeally short. And it only does what @ipstenu suggested doing in the functions.php file. You can see the code here:

https://plugins.svn.www.ads-software.com/activate-update-services/trunk/activate-update-services.php

I don’t know why it would be affected by the domain or anything like that.

It seams like the “Automatic Submission” setting is wrong somehow.
It creates a flattr thing with the link “blogurl.com/?p=1234” instead of the permalink structur.
And when the first flattr clicks on the blog a new “flattr thing” is created with the correct permalink structur.

This is because it uses this code line:
$url = get_permalink($post['ID']);

Which does not return the permalink structure:
https://core.trac.www.ads-software.com/ticket/9963

Haven’t found a solution … yet.
Might just be easier to remove the “Automatic Submission” setting for the time beeing. The first person to flatter will create “the thing” anyways. And you don’t have to get double things. ??

—-
Edit.

Not sure I understand the WP Codex correct. :-/

The problem seams to be that get_permalink() within flattr5.php doesn’t return with permalink structure. For me anyway. But not sure why. If it WP design. Or if its a bug. Or if Im dreaming.

More investigation is required… ?? /Ramblings

I solved it. ?? Read more here: https://fmasc.net/31g

I’ve e-mailed the plugin creator about it. Hopefully it can be added to the next version.
In short, its two fixes.

1) New regexp
'/(^|\s)#([\pL\w]+)/u'

2) Removed a trailing whitespace before $suffix in aktt_hashtag_link()

Ive been looking into this a bit as well. Didn’t like the solution here which just adds a bunch of characters. It might only works for some and not for all characters. Maybe it is perfect for German special characters but not Swedish or Norwegian for example… So I did like this instead.

In the preg_replace_callback() for hash tags I changed the regexp to this:
'/(^|\s)#([\w\pL]{1,})(\W)/u'
It uses unicode to match any word character. So it should match a-z0-9 and for example ??? in Swedish and it also matches “_” which Twitter also approves in hash tags. Then it looks for any non word character after it. So it doesn’t match #tag-tag but #tag_tag or #t?g_t?g for example.

But I also noticed it has problems with two tags after each other. So if the tweet is “Wow, WordPress is really great! #wordpress #epic #stuff” it will make a link out of #wordpress and #stuff. But not #epic.

I found a ugly solution for this is to change all white spaces to double white spaces before doing the match. And then changing them back. ??

So the full code now looks like this (not the whole function, but the preg_replace_callback() part for hashtags):

$tweet = preg_replace("/(\s)/", "  ", $tweet);
	$tweet = preg_replace_callback(
		'/(^|\s)#([\w\pL]{1,})(\W)/u'
		, create_function(
			'$matches'
			, 'return aktt_hashtag_link($matches[2], \' #\', \'\');'
		)
		, $tweet
	);
	$tweet = preg_replace("/(\s\s)/", " ", $tweet);

The only problem now with this is if you have a tag with a dash in it. Like #lol-cat for example. Twitter creates a tag out of #lol and leaves “-cat” as text. On their page. This function will do #lol as a tag, remove “-” and leave cat intact. So it looks like #lol cat instead of #lol-cat … But it’s better then nothing. ??

It would be great though if this could be patched into the official plugin. Any solution that fixes ??? (and so on) in hash tags. So it finds the same tags as Twitter does.

1.0.2 is now available (within a couple of minutes).

This fixes this issues. Which was an issue with custom post names being forced to lower case. The custom post type for PostWidgets was called “PostWidgets”. But in 3.1 they became “postwidgets”. Which caused this bug for old PostWidgets created. An upgrade function in 1.0.2 fixes this.

Ive found the issue. You can read more about it in the comments here:
https://notesblog.com/notes/post-widgets/
(scroll down to Chris Rust comment on 14th of march)

I have a beta of 1.0.1 you can download here:
https://dl.dropbox.com/u/4338/notes-postwidgets_1.0.1-beta.zip

BACKUP BEFORE UPGRADING. The patch requires an update to the posts database. It should only affect the PostWidget type post rows in that database table. But its important to make sure you have a backup in case of emergency. ??

Will post the final 1.0.1 update to www.ads-software.com as soon as I have been able to test it a bit more.

And sorry for the late response to this.

The edit option where? ??

Ok. To bad. Thanks for the info though. But I don’t think I will/can do anything about it. It’s such an old version. It’s more for WP3.

What kind of error do you get however?

Bump. Still annoying as hell. ??