#16522 closed defect (bug) (fixed)
WordPress repository not refreshing
Reported by: | fireproofsocks | Owned by: | |
---|---|---|---|
Milestone: | WordPress.org | Priority: | normal |
Severity: | normal | Version: | |
Component: | WordPress.org Site | Keywords: | |
Focuses: | Cc: |
Description
Every time I submit a change to my plugin, it does not show up on my plugin's download page. I've had to submit each new version multiple times before it finally gets picked up. It's extremely frustrating.
To Repeat:
- Commit changes to SVN trunk
- svn copy http://plugins.svn.wordpress.org/custom-content-type-manager/trunk/* http://plugins.svn.wordpress.org/custom-content-type-manager/tags/1.2.3
Expected:
New version shows up for download.
Actual:
Nothing happens. Devs get pissed.
If there's documentation about how this should be done EXACTLY, then it should be included on the http://wordpress.org/extend/plugins/about/ page. The page here: http://wordpress.org/extend/plugins/about/svn/ is very poor because it does not explain how you can actually use SVN while developing a plugin. It's correct in theory, but in reality, you wouldn't have your tags and trunk directory sitting in your wp-content/plugins directory -- it's worth pointing out how you might check out the contents of the trunk directly to your local plugin folder, e.g.
svn checkout http://plugins.svn.wordpress.org/custom-content-type-manager/trunk .
And it should be made crystal clear which readme.txt is being read to produce the download page, and it should be crystal clear how the version in the information head relates to the Stable Tag in the readme.txt file. There are several interrelated moving parts here, and frankly, even after messing around with this for hours, I have no clear understanding of how this actually works. If it were me, I'd scrap this whole thing and use a "tags/stable" branch that will always contain the version of the plugin that's visible on the download page.
Change History (48)
#1
follow-ups:
↓ 2
↓ 4
↓ 25
@
14 years ago
- Keywords svn removed
- Milestone changed from Awaiting Review to WordPress.org
- Severity changed from major to normal
#2
in reply to:
↑ 1
@
14 years ago
Replying to nacin:
I don't have a problem adding better instructions
Definitely needs to be done. From the .org How to Use Subversion page:
To do that you'll need to remember to update the Stable Tag field in trunk/readme.txt beforehand!
Untested, but I assume that operation order doesn't work either (quick look and I think it's what the OP has done) based on what Mark and yourself are saying.
and potentially even improving some of the code behind it, as the order of operations is definitely annoying.
Sounds even better!
#4
in reply to:
↑ 1
@
14 years ago
Replying to nacin:
Try this:
- Commit changes to SVN trunk, but not the 'Stable tag' in the readme.
- svn copy
- Bump the readme to reflect the new tag.
I just releaded Admin Quicksearch v0.2 yesterday and I made the changes to the stable tag in the readme prior to creating the tag with the svn copy command and it did work flawlessly.
Problem is, I believe, the new tag isn't created when the readme is parsed.
I don't know if that really is a problem. Albeit I had the same problems (missing docs) at first as well (I went into IRC), I never expected the plugin repository to automatically do the tagging for me.
Also, you might need to wait up to 15 minutes or so for the package to be built.
From my experience, the new generally named package is available quite fast, but the one tagged in the filename takes a bit longer. But that are only some minutes.
I don't have a problem adding better instructions and potentially even improving some of the code behind it, as the order of operations is definitely annoying. But we need it iron out what people keep doing wrong in order to make it so they do it properly.
I had problems to start as well and as I chatted with others about it, I think the most complicated part is to understand SVN tagging.
The rest is pretty much straight forward, like editing the readme file and commit it.
And if order of different actions is important, than this should be documented as well.
#6
follow-up:
↓ 10
@
14 years ago
Started having problems with this too:
I have "Stable tag: trunk".
Updated the readme and it's still not refreshed, 2 days later:
#7
follow-up:
↓ 12
@
14 years ago
Another example: http://wordpress.org/extend/plugins/front-end-editor/
The version is correctly set to 2.0, the screenshots are updated, but the actual text in the readme sections is not.
#8
@
14 years ago
I attempted an upgrade on a site and it actually upgraded to the same version (1.9.3).
Downloading the zip directly works, though.
#9
follow-up:
↓ 11
@
14 years ago
Having the same issue, and the suggestions above don't seem to be helping. I've tried:
- Adding whitespace to trunk/readme.txt
- Bumping readme stable tag after copying to a tag folder
- Bumping readme stable tag before copying to a tag folder
Downloading through zip gives me the latest package, but I can't get the plugin page on wp.org to update.
If someone has a surefire way to work around this big (until it is fixed), please post it here.
#10
in reply to:
↑ 6
@
14 years ago
Replying to scribu:
Started having problems with this too:
I have "Stable tag: trunk".
Updated the readme and it's still not refreshed, 2 days later:
This looks fine - stable tag 0.7 and shows as 0.7 to download?
#11
in reply to:
↑ 9
;
follow-up:
↓ 13
@
14 years ago
Replying to solarissmoke:
Having the same issue, and the suggestions above don't seem to be helping. I've tried:
- Adding whitespace to trunk/readme.txt
- Bumping readme stable tag after copying to a tag folder
- Bumping readme stable tag before copying to a tag folder
Downloading through zip gives me the latest package, but I can't get the plugin page on wp.org to update.
If someone has a surefire way to work around this big (until it is fixed), please post it here.
Which plugin(s)?
#12
in reply to:
↑ 7
@
14 years ago
Replying to scribu:
Another example: http://wordpress.org/extend/plugins/front-end-editor/
The version is correctly set to 2.0, the screenshots are updated, but the actual text in the readme sections is not.
You changed stable tag value in readme.txt before tagging - this is usually the culprit.
#13
in reply to:
↑ 11
@
14 years ago
Replying to westi:
http://wordpress.org/extend/plugins/wp-410/
The plugins page should be showing version 0.4 but it isn't. As you'll see from the trac log I've tried all sorts of antics to get it to refresh, but nothing has worked.
#14
follow-up:
↓ 23
@
14 years ago
- Cc jasonhendriks added
- Keywords 2nd-opinion added
- Version set to 3.1
Another example: http://wordpress.org/extend/plugins/blip-slideshow/
This plugin was behaving just fine until May 3/11, when I pushed some updates to trunk. I did NOT change the stable tag in trunk's readme.txt as I'm still in development, but suddenly the big red download button is pointing to the trunk .zip, even though the label still says "Download Version 1.2.4". I expect the download to remain at 1.2.4 until I change the readme.txt stable tag in trunk.
Another plugin, brand new, is having the same problem ever since May 2/11. trunk's readme.txt points to the 1.0.0 tag but the download label and .zip refuse to change from trunk. http://wordpress.org/extend/plugins/dynamic-dates/
#16
@
14 years ago
I'm having a similar issue: http://wordpress.org/extend/plugins/featured-posts-scroll/
Everything was working up to my 1.3 release, but I guess I've somehow done something to completely trash my repo.
With my 1.4 release, I probably did make the mistake of updating my trunk Stable Version prior to making the new tag. Nothing on my plugin page updated at all. So, I decided to go ahead and push out a 1.5 version with a few more minor changes. Probably again made the same mistake and again saw no updates.
I then discovered this thread, I made sure to create a 1.6 tagged version prior to updating the Stable Version on the trunk. Everything on my plugin page then updated, with the exception of the main download button which seems to be stuck pointing at trunk rather than the latest tag.
#17
follow-up:
↓ 20
@
14 years ago
If someone at wp.org is willing to let me play with the code that controls this, I would be happy to try and fix it server side. This is becoming quite a serious issue for plugin authors, and it would be nice to have it resolved fairly soon.
#18
@
14 years ago
Same thing with my Quick Chat plugin:
http://wordpress.org/extend/plugins/quick-chat/
Updated twice since yesterday, currently to 1.43 and version is not updated. It still shows 1.41. Kind of sad because it contains important bug fixes. I've tried adding whitespace to readme.txt, no help.
#19
@
14 years ago
This seems like the sort of thing you shouldn't have to think too much about. I don't know about the rest of you, but in my software development life outside of WP, my standard workflow goes something like this:
- One or more people create a branch from trunk.
- Once work on the branch is done, merge those changes back to trunk.
- Once trunk is ready for release, create a tag.
I think whatever needs to be done on the server side to make that pretty standard workflow function correctly should be addressed immediately.
#20
in reply to:
↑ 17
;
follow-up:
↓ 21
@
14 years ago
Replying to solarissmoke:
This is becoming quite a serious issue for plugin authors, and it would be nice to have it resolved fairly soon.
If everybody would quit "bumping" by adding whitespace and such, then the problem wouldn't happen nearly as often.
I'm looking through the repository logs and seeing people adding whitespace once every 15 minutes or so...
People, *that doesn't work*. No amount of modification will get the process to run or notice your changes.
STOP DOING IT.
#21
in reply to:
↑ 20
;
follow-up:
↓ 22
@
14 years ago
Replying to Otto42:
If everybody would quit "bumping" by adding whitespace and such, then the problem wouldn't happen nearly as often.
People are doing this *because* the problems are happening, and because it was suggested that this is all that is required to sort it out. Not the other way round.
People, *that doesn't work*. No amount of modification will get the process to run or notice your changes.
Could you please tell us what does work? When the plugin page does not correspond with the stable
tag in readme.txt, how can it be refreshed?
#22
in reply to:
↑ 21
@
14 years ago
Replying to solarissmoke:
People are doing this *because* the problems are happening, and because it was suggested that this is all that is required to sort it out. Not the other way round.
Yes, well, now I'm telling you otherwise. Don't do that.
The process runs when it runs and that's when it runs. Simple as that. It works by looking at the revision logs, and it then processes through those to put the changes into place, as needed.
"Bumping" increases the number of revision logs, making it have to do more work, making it take longer, making it less likely that your change will get noticed anytime soon. In other words, it's actually counterproductive.
Now, if your change got legitimately missed in some manner (still working out how that can happen), then bumping might get it to notice, but no amount of bumping will make it happen sooner. Quite the opposite in fact.
Could you please tell us what does work? When the plugin page does not correspond with the
stable
tag in readme.txt, how can it be refreshed?
What does work: Make the tag, update the readme in trunk to point at that tag, then *wait*. And yes, it may be a while.
#23
in reply to:
↑ 14
;
follow-up:
↓ 24
@
14 years ago
Replying to jasonhendriks:
Another example: http://wordpress.org/extend/plugins/blip-slideshow/
This plugin was behaving just fine until May 3/11, when I pushed some updates to trunk. I did NOT change the stable tag in trunk's readme.txt as I'm still in development, but suddenly the big red download button is pointing to the trunk .zip, even though the label still says "Download Version 1.2.4". I expect the download to remain at 1.2.4 until I change the readme.txt stable tag in trunk.
What do you mean the "trunk zip"? I can't find anything wrong with this plugin. The download looks fine to me.
Another plugin, brand new, is having the same problem ever since May 2/11. trunk's readme.txt points to the 1.0.0 tag but the download label and .zip refuse to change from trunk. http://wordpress.org/extend/plugins/dynamic-dates/
The problem here was that you had actually defined the version in the plugin at some point to be "trunk":
http://plugins.trac.wordpress.org/browser/dynamic-dates/trunk/dynamic-dates.php
Versions are *numbers*. As far as the algorithm was concerned, "trunk" > "1.0.0", so it didn't update from that properly.
#24
in reply to:
↑ 23
;
follow-up:
↓ 26
@
14 years ago
Replying to Otto42:
Another example: http://wordpress.org/extend/plugins/blip-slideshow/
This plugin was behaving just fine until May 3/11, when I pushed some updates to trunk. I did NOT change the stable tag in trunk's readme.txt as I'm still in development, but suddenly the big red download button is pointing to the trunk .zip, even though the label still says "Download Version 1.2.4". I expect the download to remain at 1.2.4 until I change the readme.txt stable tag in trunk.
What do you mean the "trunk zip"? I can't find anything wrong with this plugin. The download looks fine to me.
I can't find anything wrong either, which is why I'm here on trac ;-)
By trunk zip, I mean literally http://downloads.wordpress.org/plugin/blip-slideshow.zip. This big red download button should be pointing to http://downloads.wordpress.org/plugin/blip-slideshow.1.2.4.zip.
Here is a screenshot from Safari 5 / OS X. I am hovering the mouse over the download button, note the link showing in the status bar at the bottom of the window. Cache was emptied, page was refreshed. You say you can't find anything wrong so perhaps it is a browser issue, but I doubt it.
We all appreciate your time and attention to this, Otto.
#25
in reply to:
↑ 1
@
14 years ago
Replying to nacin:
Problem is, I believe, the new tag isn't created when the readme is parsed.
After reading the code, I think that, in theory, this shouldn't matter, unless you happen to get really, really super unlucky with your timing. Even then, I doubt order of operations is the actual problem here.
If anybody can point out a case of this occurring, live, then I'll be able to better check out what's going on. Email me directly when you get one. otto at ottodestruct.com.
#26
in reply to:
↑ 24
;
follow-up:
↓ 27
@
14 years ago
Replying to jasonhendriks:
By trunk zip, I mean literally http://downloads.wordpress.org/plugin/blip-slideshow.zip. This big red download button should be pointing to http://downloads.wordpress.org/plugin/blip-slideshow.1.2.4.zip.
Okay, when I wrote that message an hour ago, it *was* pointing to 1.2.4. I checked it myself. Now it's not.
And I see you made a change 42 minutes ago to trunk. I suspect this is not a coincidence.
Okay, and I just manually forced an update, and the link is fine again. I'll investigate further.
BTW, I notice that you include a lot of space in your PHP files to tab the name and version and other header info out: http://plugins.trac.wordpress.org/browser/blip-slideshow/trunk/blip.php
I highly recommend against that. Some parser code might not like it, and it may be part of the issue. Just a guess, but might be the case. Put your header code on the left column, don't tab it out. Needless whitespace anyway.
#27
in reply to:
↑ 26
@
14 years ago
Replying to Otto42:
Replying to jasonhendriks:
By trunk zip, I mean literally http://downloads.wordpress.org/plugin/blip-slideshow.zip. This big red download button should be pointing to http://downloads.wordpress.org/plugin/blip-slideshow.1.2.4.zip.
Okay, when I wrote that message an hour ago, it *was* pointing to 1.2.4. I checked it myself. Now it's not.
And I see you made a change 42 minutes ago to trunk. I suspect this is not a coincidence.
I will remove the whitespace in the PHP file and see if that is the culprit. If this happens again I will hold off pushing changes and notify you by e-mail. Thank-you!
#28
follow-up:
↓ 29
@
14 years ago
We're having the same issues.
We have 2 new plugins that are not pulling in changes from the readme files as well. We can't get them published. We've tried both tagging and using trunk for stable header:
http://plugins.trac.wordpress.org/browser/wordpress-google-maps/trunk/readme.txt
http://plugins.trac.wordpress.org/browser/wordpress-seo-plugin/trunk/readme.txt
#29
in reply to:
↑ 28
@
14 years ago
Replying to uglyrobot:
We're having the same issues.
We have 2 new plugins that are not pulling in changes from the readme files as well. We can't get them published. We've tried both tagging and using trunk for stable header:
I can see that your version tag in http://plugins.svn.wordpress.org/wordpress-google-maps/trunk/readme.txt ('trunk'), http://plugins.svn.wordpress.org/wordpress-google-maps/tags/1.0.3/wpmu_dev_maps_plugin.php ('1.0.4') and http://plugins.svn.wordpress.org/wordpress-google-maps/tags/1.0.3/readme.txt ('1.0.3') are all different. There's no way that that is going to work. Change them all to 1.0.3 and see what happens.
#30
follow-up:
↓ 31
@
14 years ago
mdawaffe made a patch for this problem a couple hours ago.. However, the reset make take half a day for it to scan everything. I'll check it in the morning and confirm if it's working or not. Patience, please.
#31
in reply to:
↑ 30
;
follow-up:
↓ 32
@
14 years ago
Replying to Otto42:
mdawaffe made a patch for this problem a couple hours ago.. However, the reset make take half a day for it to scan everything. I'll check it in the morning and confirm if it's working or not. Patience, please.
Things seem fine with my plugins since I removed the whitespace as per your suggestion, Otto. FYI.
#32
in reply to:
↑ 31
@
14 years ago
Replying to jasonhendriks:
Things seem fine with my plugins since I removed the whitespace as per your suggestion, Otto. FYI.
That actually turned out to not be the problem, but I do admit that it looks better without the extra whitespace. :)
#33
follow-ups:
↓ 34
↓ 35
@
14 years ago
- Resolution set to fixed
- Status changed from new to closed
The problem appears to be fixed now, thanks to mdawaffe's changes. He reran the process for everything since last May, and all plugins should be currently up to date.
#34
in reply to:
↑ 33
@
14 years ago
Replying to Otto42:
The problem appears to be fixed now, thanks to mdawaffe's changes. He reran the process for everything since last May, and all plugins should be currently up to date.
Everything appears to be fine on my end as well. A spot check of some of the other plugins mentioned here also looks pretty good.
Thanks for all the help Otto42 and mdawaffe.
#35
in reply to:
↑ 33
@
13 years ago
Replying to Otto42:
The problem appears to be fixed now, thanks to mdawaffe's changes. He reran the process for everything since last May, and all plugins should be currently up to date.
I am having the same issue even after this update. I solved it by updating the "Tested up to" tag from 3.1 to 3.1.2 in readme.txt
#37
@
13 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
Closed #18905 as a duplicate.
Looks like the changes are still not reflected under some circumstances.
#38
@
13 years ago
I think I worked out the cause of this. I'm resetting the master to rerun the last few weeks.
It may take a while (few hours) for the update to run all the way through.
#39
@
13 years ago
Okay, so it's taking much, much longer than I expected.
I'm forcing it up to date because of the sudden ridiculous influx of people trying to force it. Send any not-updated reports to me and I'll process that section by hand.
For reference, the updater *will* catch your updates, eventually. Continually changing things in SVN to try to force it won't make it happen any faster.
#40
follow-up:
↓ 41
@
13 years ago
I have just updated readmes for 6 my plugins, to remove one link per recent Automattic request. Repository already displays these updated readmes. Unfortunately for 2 of these plugins the Last Updated date was not modified, so still there is something to fix.
#41
in reply to:
↑ 40
;
follow-up:
↓ 43
@
13 years ago
Replying to sirzooro:
I have just updated readmes for 6 my plugins, to remove one link per recent Automattic request. Repository already displays these updated readmes. Unfortunately for 2 of these plugins the Last Updated date was not modified, so still there is something to fix.
Not everything on the page will update at the same time. There's more than one server doing more than one thing, and sometimes the time won't update for quite a while when the primary gets behind schedule.
Of your plugins, I count 6 with an update date of today. Is there some other one with the wrong date?
http://wordpress.org/extend/plugins/profile/sirzooro
#42
@
13 years ago
@Otto42: thanks for clarification. I wrongly assumed that single server can do whole work for one plugin. So this is not an issue.
#43
in reply to:
↑ 41
@
13 years ago
Replying to Otto42:
There's more than one server doing more than one thing, and sometimes the time won't update for quite a while when the primary gets behind schedule.
Just wondering whether the delay can be several days? I committed some changes 3 days ago - the download link changed quickly but the last updated is still stuck. Or did I do something in the wrong order? http://wordpress.org/extend/plugins/disable-comments/
#45
@
13 years ago
Another release, and date is still in the past, this is a bug that has been here for more than 6 months, I don't know why its hitting me, when will it ever be fixed... changing the readme.txt does not help.
Please please, and with some sugar on top, try to make this work
Thanks
update: seems like me lucky day, date eventually changed... Maybe because of the readme.txt change, will keep watching
#46
@
13 years ago
FWIW, the problem seems to be more common when you use Stable tag: trunk
. I've found that tagging a release and changing the stable tag in trunk reliably triggers a change to the last updated time.
#47
@
12 years ago
- Resolution set to fixed
- Status changed from reopened to closed
Now that updating occurs in real-time, we haven't seen any issues for some months now.
#48
@
12 years ago
Just stumbled upon Custom Post Limits.
According to the SVN log, the latest commit (update to 3.6) was in February 2012 (9 months ago), however the repository still says that the plugin hasn't been updated in over 2 years.
Try this:
Problem is, I believe, the new tag isn't created when the readme is parsed.
Also, you might need to wait up to 15 minutes or so for the package to be built.
I don't have a problem adding better instructions and potentially even improving some of the code behind it, as the order of operations is definitely annoying. But we need it iron out what people keep doing wrong in order to make it so they do it properly.