WordPress.org

Making WordPress.org

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#352 closed defect (maybelater)

After a plugin commit, the new readme.txt data are not displayed

Reported by: dontdream Owned by:
Milestone: Priority: normal
Component: Plugin Directory Keywords:
Cc:

Description

After the latest commit in BP Profile Search, the new readme.txt data are not displayed in the plugin page:

http://wordpress.org/plugins/bp-profile-search/

The new release number does show up, but the new changelog and the new update time do not. As a side note, the plugin zip file is correctly generated and contains the new readme.txt file.

This is a frequent problem for me, and usually I'm able to fix it with one or two more commits of the readme.txt file, where I simply change one or two words in the description.

This time I didn't try to fix it myself, and I hope you can help to explain this strange behavior. It looks like the readme.txt data are stored somewhere, and this datastore is not always correctly updated.

Thanks!

Change History (4)

#1 @dontdream
6 years ago

Additional info:

I mentioned a way I fix this problem myself when it occurs (very often!), that is I commit a slightly changed readme.txt file.

Actually any commit can do the trick, as I discovered today. For a few days the plugin page had been out of sync with the committed readme.txt file, and it went back in sync today when I committed a different file.

#2 @Otto42
6 years ago

  • Resolution set to maybelater
  • Status changed from new to closed

Please do not commit extra commits for no reason.

This problem is caused by database lag. Specifically, we have multiple web servers and multiple databases and not everything updates at the same time.

Given enough time, the problem will sort itself out, as you have discovered. Right now we are dealing with enough database overload problems as is, while also trying to do several different releases in a row. The last thing we really need is people making extra commits for bad reasons and adding extra load.

Wait. Be patient with it. And if that doesn't work, email plugins at wordpress.org about it, and they can fix it for you.

If and when we get the chance to redo a fair amount of the directory, then there won't be as much of a lag time. For now, it's unavoidable.

#3 @dontdream
6 years ago

Otto,

Thank you for your explanation, I'll avoid extra commits in the future and I will email plugins at wordpress.org instead.

Just to share my own experience, after a commit the directory is either updated very quickly, almost in real time, or it never is. I've been waiting for days, even for two weeks one time, and the directory was not updated until I made another commit.

I suggest you display your explanation and recommendations prominently in the plugins directory, because I suspect many plugin authors discovered the repeated commits "trick" and are using it routinely.

Last edited 6 years ago by dontdream (previous) (diff)

#4 @Otto42
6 years ago

Yeah, I know. It's a problem. Happens more often during release times or times of high traffic on the forums. If it's actually breaking things, pinging me or plugins@ is the best way to get a rapid fix.

Touching the readme or anything else with a whitespace change will indeed do the job as every commit forces a rescan. I just don't recommend it as a solution, because it adds bloat. I can manually run an update on any specific case where it's a problem, but often people ping me and when I check an hour later, it's already handled it by itself. The process gets bogged down from time to time, and adding bloat with extra commits causes it to happen more often.

Note: See TracTickets for help on using tickets.