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.)
It looks like 1.6.1 now automatically adds a rel=”slb” (plus some slb_group) to image links pointing to url’s ending in a known image postfix. While a nice idea in theory, this does not work well with links pointing to non-image content that ends in an image postfix.
Steps to reproduce:
1. Create an image link pointing to a picture page in Wikimedia Commons.
2. Try clicking the link with SLB activated.
What happens:
SLB tries to lightbox the Commons page.
What I expect to happen:
I’d expect SLB not to mess with the link so that when I click the image, I’m taken to the Commons page as usual.
Other notes:
I don’t think there’s any way around this other than disabling the automatic rel=”slb”’ing feature entirely (which the plugin currently, AFAICS, doesn’t allow me to do). There’s no reliable way to determine a link *really* points to an image just by looking at the url.
Is it just me, or do the plugin’s settings get reset back to defaults with each update? Is this intentional and if so, why?
Apparently either results.php or head.php (in view/admin/) refers to an image called small.gif by a path that doesn’t work: every time I use Search Regex I get 404 hits for a ’/images/small.gif’, when it should in fact refer to [site root]/wp-content/plugins/search-regex/images/small.gif. Apparently $this->url() precluding the path in the code doesn’t work — maybe $this is out of scope?
Np, @RavanH, glad my contribution turned out so 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: http://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 withoutblogs.dir.
I’m thinking of changing Upload Path, but I’m unsure where it ultimately shouldpoint 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.
Wrapping strings in the plugin code with appropriate gettext functions would allow me to use it in my native language, so that for example ”Flattr this!” could become ”Flattroi tätä!” for my Finnish readers.
In templates/default/layout.html there are elements named ”loading” and ”close”. I don’t know if these names are dictated by Lightbox, but unless they are, I’d suggest renaming them with something more closely tied to their use by Simple Lightbox (such as ”slb_loading” and ”slb_close”, as other elements in the template are). The reason is that I just spent a significant amount of time trying to debug a weird problem with my theme, which was actually caused by ”loading” being an id used by Simple Lightbox and styled in its CSS. It was obviously easy for me to fix this by changing my element’s id, but finding out the cause was time I could have spent with more useful matters.
Thanks for the great plugin, though.
