Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#2630 closed defect (bug) (fixed)

Plugin directory redirecting to wrong plugin

Reported by: dvankooten's profile DvanKooten Owned by: otto42's profile Otto42
Milestone: Plugin Directory v3.0 Priority: high
Component: Plugin Directory Keywords:


In some browsers, the URL for a plugin redirects you to an entirely different & unrelated plugin instead.

To reproduce the issue, please go to in a browser other than Chrome. It should bring up the MailChimp for WordPress plugin but is instead taking me to

Affected browsers:

  • Firefox
  • Brave
  • Mobile Chrome

User report:

Change History (19)

#1 @SergeyBiryukov
7 years ago

  • Milestone set to Plugin Directory v3.0

#2 @DvanKooten
7 years ago

It actually seems to affect Chrome too, the error is just very inconsistent. Sometimes it works for a short timespan (~10 minutes), then it stops working for what seems to be the same timespan. Something cache related?

#3 @tomgreep
7 years ago

For me it's in all browsers I have access too:

  • Chrome on Windows and Android
  • Internet Explorer on Windows
  • Edge on Windows
  • Firefox on Windows
  • Opera on Windows

Since I experienced this, it only some of the times worked in Chrome on Windows and Android. But as said before, very inconsistent.

#4 @tomgreep
7 years ago

Maybe good to see: I used to show in a lot of browsers. About half of them show the correct page, the other half don't.

#5 @WiZZarD_
7 years ago

Full headers when I open this page are as follows:

Request URL:
Request Method:GET
Status Code:301 
Remote Address:
Response Headers
content-type:text/html; charset=UTF-8
date:Wed, 29 Mar 2017 13:43:40 GMT
x-nc:HIT lax 249
Request Headers
accept-encoding:gzip, deflate, br
user-agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

There seems to be a redirect that triggers on something.

#6 @dd32
7 years ago

There was a few reports of this at launch, which spurred [5178] - I have no idea if that's the code responsible, but it's the only thing I could think of to redirect to that specific path (/changelog/). This is the first i've heard of it still happening since that commit too.

The sporadicness of it is that only one webnode has cached the bad redirect (301's get 1hr caching for logged out users), but I'm still not sure where the redirect has come from

Last edited 7 years ago by dd32 (previous) (diff)

This ticket was mentioned in Slack in #meta by otto42. View the logs.

7 years ago

#8 follow-up: @tomgreep
7 years ago

Now it also happens for Contact Form 7.

#9 in reply to: ↑ 8 @lukecavanagh
7 years ago

Not having that issue
Replying to tomgreep:

Now it also happens for Contact Form 7.

This ticket was mentioned in Slack in #meta by tellyworth. View the logs.

7 years ago

#11 @DvanKooten
7 years ago

We're still getting reports from several people that they're being redirected to the Changelog plugin. Browsers seems to be caching the HTTP headers so when trying different browsers, you have to be in "luck" to run across it. Once you do, you'll get that same behavior for a short time.

When using curl or wget there seems to be a 50% change of being redirected, even on consecutive runs.

curl -v
wget -S

Unfortunately, I am far too unfamiliar with the code and/or architecture to dig into this myself (not even sure if I can). This has to be happening for other plugins too, right? Anything in our plugin's README that could be triggering it?

Version 1, edited 7 years ago by DvanKooten (previous) (next) (diff)

#12 @Otto42
7 years ago

This is not browser caching, there is nothing you can do to fix it, please don't try to do so.

This is caching on our end and we're sorting it out.

#13 @Otto42
7 years ago

Update: We have worked out why this is happening. Working on a way to test a fix now.

This ticket was mentioned in Slack in #meta by clorith. View the logs.

7 years ago

#15 @Clorith
7 years ago

#2650 was marked as a duplicate.

#16 @Otto42
7 years ago

  • Owner set to Otto42
  • Resolution set to fixed
  • Status changed from new to closed

In 5211:

Plugin Directory: Handle redirects for clients that send the URL fragment back to the server after a redirect. Redirect such clients to the URL without the fragment. Fixes #2630.

#17 @Otto42
7 years ago

Sorry, finally correctly fixed in [5217]. This one took a couple tries because I had to wait for caches to expire to see the results.

The few plugins doing this (3 that we know of) that are currently redirect looping should clear up within an hour, and after that the problem should not recur.

#18 @DvanKooten
7 years ago

That does seem to do the trick, great! Thanks so much for acting on this.

#19 @tomgreep
7 years ago

I still had to clear the local cache, but indeed it seems to work!

Note: See TracTickets for help on using tickets.