Version 1.3 released

Google has the option view original picture, The redirect to post doesn’t work, it stills goes to the path where the image is restore but than with show-image/?img=/wp-content in the url bar, the image is than still with the overlay but doesn’t redirect to post. I used the hack in some earlier post what you said but that also doesn’t work, if I do that it creates no overlay at all.

Hi,

Are you using version 1.3 or 1.3.1?

Hi there,

Great job on the new realease. I see you’ve rolled in a lot of the handy features.

Just wanted to point out, not sure if it was a simple oversight, is that the url in the line$ir_location = "https://test.com/index.php?p=".ir_getpostidbyurl($_GET['img']); in the plugin’s index.php causes the post to redirect to the said url. I fixed this by just changing it to my website’s url.

Again fantastic job :-]

Thanks for letting us know about this. Very emberrasing. We have released a 1.3.2 version which should correct this.

Sorry!

Nashua Indigo said:

The redirect to post doesn't work, it stills goes to the path where the image is restore but than with show-image/?img=/wp-content in the url bar, the image is than still with the overlay but doesn't redirect to post.

Hi, just re-read your post and realized that you probably have the watermark feature turned on at the same time as the redirect to blog.

This won’t work (there are certain inherent problems with separating hotlinking and direct hits). For now it is either or – either watermarking or redirect to blog. Both won’t work at the same time. Using the redirect to blog, though, at least you catch the people clicking “see original” in Google.

Hello,

Okay I have the newest version 1.3.2 but without Redirect to post page box put on on, the watermark will not work, and if you place both on, the watermark will work but not redirect to post. So for me this plugin works half

Okay I have the newest version 1.3.2 but without Redirect to post page box put on on, the watermark will not work, and if you place both on, the watermark will work but not redirect to post. So for me this plugin works half

Sorry to hear that. However, both cannot work at the same time. The watermark is a redirect (it sees a non approved referrer and redirects to the watermarked image) and the redirect to blog post is obviously a redirect too. The way the http protocol works, there is no way to distinguish between a hotlinked image and an image visited through a link on the hotlinking site.

However watermark should work without redirect being turned on, though. Maybe that was just a typo in your post, if not please feel free to provide more information. We will do our best to help you!

You can eliminate a 301/302 hop if you make this change when linking the image to the original story:

From:
$ir_location = get_bloginfo('url')."/index.php?p=".ir_getpostidbyurl($_GET['img']);

To:
$ir_location = get_bloginfo('url')."/?p=".ir_getpostidbyurl($_GET['img']);

You can eliminate a 301/302 hop if you make this change when linking the image to the original story:

Thanks for sharing that tips! It should work fine and as you say it will prevent the linked redirects that the Beta version of “show in original post” uses.

Anyone using this should be aware that it will prevent you from going back to show in blog preview style, but given the feedback we are getting we will probably consider depreciating that once the “show in original post” is stable.

But what about the thing fansshare.com is using, they have a watermark just like your plugin and it also redirect to post if you push the view original button ?

The way it it is now can be also set with a couple of lines in .htaccess file, I don’t have to use this plugin for.

But what @thewebhead said is that redirect the image when you push view original, to post? I have use this option but it is still redirect to homepage.

You need the overlay watermark because Google shows the full picture in on their site, that is the issue, so even if the view origina button is redirect to post or page, the fact is still that the original in full size is displayed on google itself. So yes the overlay is also needed for that part.

other issue is that view original button what leads you to a page of the directory where your image is located without showing website.

The way it it is now can be also set with a couple of lines in .htaccess file, I don’t have to use this plugin for.

No you cannot, but good luck.

Oh, and Fansshare uses a completely different system, where they tag their images with a code. Since many crawlers will disregard such tags when crawling, they will not be directed to an image but to a html page. That will lead to the image not being stored and drop out of google eventually.

Now, this is a free plugin that we have spent a good deal of time developing. If you don’t like it, just don’t use it. If people ask for features we do our very best to help out – as you will see if you look at the posts in this support forum. But please don’t be rude and come and demand features or changes and tell us that you can do watermarking and redirect to post pages by two lines in your htaccess file. It simply isn’t true.

The redirect when clicking view original image works for me Nashua. I was just talking about how the code goes from /index.php?p=### and 302’s to /?p=###, so you can wipe out index.php… but either way it goes to the page the image is on, not the homepage, for me.

I’ve read a couple of reports of fansshare’s images starting to drop out of image search because of the said url tagging.

Nashua the redirect works. Think about whether you really need the watermark. From my understanding in the preview pane, google starts loading the cached thumbnail using javascript whilst it pulls in the full resolution image (which I assume it scales) via a hotlink. The Imaguard plugin intercepts this hotlink and sends back a plain html page. So what happens is that the preview image remains blurry (ie low quality cached thumbnail is used). For my purposes, this is enough of a deterrence for scrapers and it will probably be enough of an incentive to click on the image which of course will lead back to the original post. If scrapers want to lift the low-res preview then so be it. Can’t really do much about it and that traffic is useless anyway.

If the user clicks on the view-original, then they are also redirected back to the post via Imaguard.

It’s a win win.

This is a free plugin and the developer has done us all a service by developing it. No one is holding a gun to your head saying you must use it.

I can assure everybody that I am spending hours daily trying to come up with something that will allow both watermarking and redirecting to post at the same time.

As explained elsewhere on this forum the problem is basically this:

When Google hotlinks an image this is the data sent to the server:
Referrer: Google.*
User-agent: Users Browser

When a user then clicks on the link in google to the image this is sent:
Referrer: Google.*
User-agent: Users Browser

So basically you have two completely identical data sets. I am doing my very best to come up with some way around this through lateral thinking.

As for Fansshare, we have had a few emails referring to their system so I have had time to study what they do already. I’m not convinced it’s a good idea. This is my understanding of the Fansshare situation:

1. They dynamically add a tag on their site to all images (img.jpg?rnd=8). This rnd tag presumably is a timestamp. It will work for a given period, then it will stop working.
2. If the timestamp is out of date, the system returns a watermark
3. If the timestamp is missing completely, the system redirects to the blog page.
4. (And this is me guessing) they have an exception from the timestamp requirement for local referrers.

Now, think about this. Either googlebot is going to crawl with the timestamp or without it. If you check the results in google images for fansshare, you find no images linked with a timestamp in the URL. I am presuming these are older crawled images. To me this indicate that there is a problem with the way they have set up their system – that there is something that google really doesn’t like here. Possibly it is as simple as googlebot not including a timestamp, not setting a local referrer and then simply not seeing images at.

The Fansshare system isn’t overly complicated. But I am not prepared to offer a plugin that may cause googlebot not to see any images to hundreds of people. We still don’t know the full effect of all this playing around with redirects in the first place, but at least we know that google can see and crawl the images.

If it turns out Fansshare gets their rankings back, then I will do my very best to come up with a system similar or better. But I think it is wise to hold back a little at this stage. Half the bloggers in the world are currently playing with watermarks and redirects, and I would rather be safe (relatively) than to be the first to release a fancy new feature and use our plugin users as guinea pigs.