Making WordPress.org

Opened 14 months ago

Closed 14 months ago

Last modified 14 months ago

#2630 closed defect (fixed)

Plugin directory redirecting to wrong plugin

Reported by: DvanKooten Owned by: 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 https://wordpress.org/plugins/mailchimp-for-wp/ in a browser other than Chrome. It should bring up the MailChimp for WordPress plugin but is instead taking me to https://wordpress.org/plugins/changelog/.

Affected browsers:

  • Firefox
  • Brave
  • Mobile Chrome

User report: https://wordpress.org/support/topic/download-mailchimp-plugin/

Change History (19)

#1 @SergeyBiryukov
14 months ago

  • Milestone set to Plugin Directory v3.0

#2 @DvanKooten
14 months 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
14 months 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
14 months ago

Maybe good to see: I used browsershots.org to show https://wordpress.org/plugins/mailchimp-for-wp/ in a lot of browsers. About half of them show the correct page, the other half don't.

#5 @WiZZarD_
14 months ago

Full headers when I open this page are as follows:

Request URL:https://wordpress.org/plugins/mailchimp-for-wp/
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
14 months 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 14 months ago by dd32 (previous) (diff)

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

14 months ago

#8 follow-up: @tomgreep
14 months ago

Now it also happens for Contact Form 7.

#9 in reply to: ↑ 8 @lukecavanagh
14 months ago

Not having that issue https://wordpress.org/plugins/contact-form-7/
Replying to tomgreep:

Now it also happens for Contact Form 7.

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

14 months ago

#11 @DvanKooten
14 months 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 https://wordpress.org/plugins/mailchimp-for-wp/
wget -S https://wordpress.org/plugins/mailchimp-for-wp/

Unfortunately, I am far too unfamiliar with the WordPress.org 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?

Last edited 14 months ago by DvanKooten (previous) (diff)

#12 @Otto42
14 months 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
14 months 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.

14 months ago

#15 @Clorith
14 months ago

#2650 was marked as a duplicate.

#16 @Otto42
14 months 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
14 months 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
14 months ago

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

#19 @tomgreep
14 months ago

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

Note: See TracTickets for help on using tickets.