XF 1.3 Link proxies significantly affects Skimlinks

Stuart Wright

Well-known member
Having run 1.3 since launch with link proxies on, I have some data on Skimlinks. The guys there have been in touch to ask we test the system by turning link proxies off.
They are saying that our Skimlinks revenue is significantly down and they are confident this relates to link proxies interfering with Skimlinks in certain browsers. By turning link proxies off for a while, we can confirm one way or the other.
The Skimlinks team are looking into the situation today to get some firm information.

Meanwhile other Skimlinks users should be aware that there is likely a problem using link proxies and Skimlinks together.
 
Which particular part doesn't work? The changes to resolve the security issue involves JS to open the link now, but it uses whatever is in the href of the link. If that is being changed on click that might not work, but there isn't another way to resolve the security issue (without other trade offs).
Hi Mike,
When you run the skimlinks test it fails.

I used to see a URL redirection as well before. Click go.2redirect long URL then they went to the eventual target.

This no longer happens with the proxy link on or off
 
Hi Mike,
When you run the skimlinks test it fails.

I used to see a URL redirection as well before. Click go.2redirect long URL then they went to the eventual target.

This no longer happens with the proxy link on or off
I don't know the technical implementation of Skimlinks to know whether our changes would be involved. JavaScript is now involved in any click of a link that opens in a new tab, but we don't manipulate the URL; we just use the URL as presented. If they are doing dynamic URL rewriting or using their own JS implementation to open links, our changes may be overriding it. They would be better positioned to know that and they can contact us if they confirm that's the case (and we can see if we can do something to resolve it).
 
Strangely this worked until I upgraded to 1.5.2. I had link proxy disabled. Now it doesnt matter if enabled or disabled , I get the same problem :(

I have changed nothing other than the update.

If it worked before 1.5.2, you must have had Link Proxy deactivated (as you said). Otherwise it would not have worked for sure.

I don't know if the default setting for Link Proxy has also changed with 1.5.2, but I assume not. So the upgrade may prop. have removed your Skimlinks javascript insert? The title detection does not affect Skimlinks at all.
 
If it worked before 1.5.2, you must have had Link Proxy deactivated (as you said). Otherwise it would not have worked for sure.

I don't know if the default setting for Link Proxy has also changed with 1.5.2, but I assume not. So the upgrade may prop. have removed your Skimlinks javascript insert? The title detection does not affect Skimlinks at all.


Correct - it was disabled prior , and it is disabled now.

I have checked the page and the JS is inserted in the footer correctly.
 
Unfortunately we might not be much more use unless we understand more about what is going wrong (from their point of view). Mike said it best:
If they are doing dynamic URL rewriting or using their own JS implementation to open links, our changes may be overriding it. They would be better positioned to know that and they can contact us if they confirm that's the case (and we can see if we can do something to resolve it).
If any one else on Skimlinks can confirm the behaviour on XF 1.5.2 with the link proxy disabled, that would be interesting.
 
Unfortunately we might not be much more use unless we understand more about what is going wrong (from their point of view). Mike said it best:
If any one else on Skimlinks can confirm the behaviour on XF 1.5.2 with the link proxy disabled, that would be interesting.
If you need me to do any more testing / diagnostics let me know
 
I've never used link proxy and upgraded all my sites to 1.5.2 late in the evening on 20th Oct:

upload_2015-10-24_13-3-55.webp

So, yes, confirmed outgoing link count drop for me (visitor stats normal in GA and no dramatic change in Adsense).

Well spotted - and if I can of assistance in resolving the issue or if you'd like FTP / SSH / Admin access to my server, just PM me. (y)

Cheers,
Shaun :D
 
Last edited:
Click counts still way down - any news from XF or Skimlinks as to why this is happening? (although it does seem to have coincided with changes in XF 1.5.2 - what changed?)

upload_2015-10-26_13-22-52.webp
 
If any one else on Skimlinks can confirm the behaviour on XF 1.5.2 with the link proxy disabled, that would be interesting.

We have the link proxy disabled, Chris, and we have also experienced a decrease. It's about 24%.
1.webp
This applies to the Skimlinks technology (not Skimwords which seems to be unaffected) and it amounts to a loss of approximately £400 every month.
So it's a serious problem which needs addressing ASAP.
 
I have contacted Skimlinks now myself as well. I'm open to trying to work with them to resolve it, but I'm not really open to removing the fix for the security/phishing-vector that led to the code change that I presume is the cause.

I'm a little confused as to why you'd only see a 25% decrease though. Presumably it should either always apply or never.
 
I emailed my contacts at Skimlinks and their CTO Richard Johnson responded immediately that he's going to contact Xenforo to work on a solution.

I mentioned the issue of not being able to use the Xenforo link proxy feature. If Mike and Richard get to talking, I'm hoping that there might be a solution to that from the Skimlinks team also.
 
I emailed my contacts at Skimlinks and their CTO Richard Johnson responded immediately that he's going to contact Xenforo to work on a solution.
That's who Mike has already arranged to speak to :)
If Mike and Richard get to talking, I'm hoping that there might be a solution to that from the Skimlinks team also.
Ironically, we do think XF 1.5.2 will solve the Skimlinks/link proxy issue; it's just we introduced something new at the same time.
 
Top Bottom