Jani Uusitalo

It works! Brilliant, thanks a lot!

All right, thanks for the response. As I said, the shortcode approach works just fine so I’ll have to stick with that, and create my own custom post type if/when necessary.

No problem, and thanks for the rapid response to my bug-report-turned-support-request!

Yes and no. ?? No, I’ve never used anything but SLB. Yes, it’s apparently always activated links, but it also used to have the ‘Activate all image links in item content’ option. Being able to uncheck that option I could use SLB as I have until now: with lightboxing only on links I’ve manually specified as rel=”slb”. The automatic url-snooping thingy just doesn’t work for me, since I use lots of image links pointing to wiki pages of those images.

FWIW, it was easy to fix this for myself: I just cut process_links() so that it immediately returns with unprocessed $content.

So, uh, how do I retroactively extend this reversed behavior to all the links on my blog relying on the previous behavior? I think it’s easier for me to just downgrade and freeze the plugin back to where it works the way I’ve relied on it functioning up until now.

(Not to be critical of your work; it’s your code and you do with it as you will. It just seems my use-case was niche even until recently, and now it’s no longer supported at all.)

Np, @ravanh, glad my contribution turned out helpful!

On a hunch, I instead opted to change Upload Url Path (of the main site) to point to where Fileupload Url already was pointing, and lo and behold, now the uploads get url’s with a /files/ base (which I feel is best).

Funnily, despite this same setting on the testing site, the url’s there have the wp-content/uploads base (like I mentioned in the previous comment), as if Upload Url Path didn’t have an effect. There doesn’t seem to be a Fileupload Url setting there — perhaps it’s deprecated? (The testing site runs trunk, whereas the main site runs latest stable.)

(Usually it’s the other way round: something that works in testing won’t work on the production site.)

I’m chiming in with my experience just in case more reproducers are of any help. I’ve encountered the issue @RavanH described in the initial post on my multisite install: files uploaded onto the root blog get url’s with blogs.dir while subsites (in subdirectories) get url’s without it.

I was running WPMU just prior to it getting integrated into WP proper, but unfortunately I can’t say for sure whether I did a clean reinstall or an upgrade to WP (non-MU) at that point.

I’m only running a single network with none of the plugins mentioned in this thread thus far. Well, no, actually I do run another multisite for testing purposes, completely separate from the first, and there this issue doesn’t manifest.

The upload-related variables for the main site are as follows:

`Upload Url Path:
Upload Path: wp-content/blogs.dir/1/files
Fileupload Url: https://mummila.net/files`

I suspect the Upload Path is what’s causing this; further evidence is that on the testing site Upload Path: wp-content/uploads results in url’s without blogs.dir.

I’m thinking of changing Upload Path, but I’m unsure where it ultimately should point to. If wp-content/uploads results in corresponding url’s, is that the default for the root blog? If so, is there a reason why it deviates from what the sub-sites have, which is sitepath/files? I’d expect the root site to have /files/ as attachment url base.

Wait, so post formats are different from post types, the defaults of which are always available? Oh so confusing.

I can reproduce the “post formats” selection box not showing in both 3.1 and 3.2 RC 2. In fact I wasn’t aware of such feature, as it only shows when posting on the root site (which I very seldom do on my multisite).

I tried disabling all plugins with no effect.

…and with 1.1.4 “You do not have sufficient permissions” is back.

Hi Michael,

I just upgraded to version 0.9.20 of the plugin, and thereafter successfully connected my other blog with my Flattr account. So the issue is resolved for me. Thank you!

Upgraded to 1.0.1 an lo and behold, it now works.

With 1.0, the authorizing does redirect back to my blog, but the authorization hasn’t happened (the link still prompts to authorize). The “You do not have sufficient permissions” problem also lingers, i.e. the settings cannot be saved.

Also, I seem to be talking to myself here.

After filling the key and secret directly into the database I got a little further: I get the authorizing link and get to give the permissions on Flattr’s side, but then I get a blank page (…/callback.php?oauth_token=…), so the permissions are never actually granted.

I should mention this is one of multiple blogs running under one WP installation (a MU-like installation, if you like). I’m the admin of my site so I’ve tried things as both the blog admin and the site admin credentials, with no luck.