Last December, we added header images to the top of plugin screens. Since then, we’ve made more changes to the plugin directory and started supporting HiDPI images for those plugin headers as well.
As part of that original header update, one thing that was added which I always meant to do more with was the addition of a new “assets” directory at the top level of the plugin SVNs. This is an optional directory that sits alongside the /tags and /trunk directories, and was just used to hold the banner images. Creating a place to put plugin assets which didn’t need to be included in the plugin itself simply made sense to me.
It also never made sense to me that the plugin screenshots, which are rarely used by the plugin, needed to be included in the plugin’s ZIP file. Some plugins can use these themselves, certainly, but the majority don’t and it’s just really inflating the size of the plugin to include them.
So, starting today, you can put your screenshot files in the assets directory instead of in the main plugin directory.
A few notes, for the technically minded:
- Screenshot naming conventions have not changed, nor have the readme.txt requirements for their captioning. The naming and behavior is exactly the same, the file can just go into a new place.
- The old way still works too. If you have your screenshots in the plugin’s “stable” directory, then it will find them there just fine.
- Screenshots in the assets directory take precedence over screenshots in the plugin’s directory. If you have both, then the assets directory wins. Of course, there’s really no reason to have both, this is just for backwards compatibility.
- Like everything else in the assets directory, we are serving them through a separate static caching system, and so it may take a few minutes to update when you change them. What this means is that when you put the screenshots in there for the very first time, they may not show up on your page for a few minutes and you’ll just see the captions with no images above them. Please give the proxy some time to retrieve your screenshots and cache them before telling me it’s buggy. It should only take a few minutes.
The ultimate goal, of course, is to reduce the size of the plugin ZIP files being served. By not including the screenshots in the plugin, files are smaller and upgrades are thus speedier for everybody.
In the future, if we have a need for more “directory only” files, I expect them all to be in the assets directory as well, for just this sort of reason.
Pippin Williamson 4:48 pm on September 13, 2012 Permalink |
Excellent!
logikal16 5:00 pm on September 13, 2012 Permalink |
That’s great news, thanks!
Brad Touesnard 5:03 pm on September 13, 2012 Permalink |
Nice!
Chuck Reynolds 5:04 pm on September 13, 2012 Permalink |
This is great. Shouldn’t we also do the same for readme files? With the recent security talks concerning the version number being in the readme’s in each plugin dir.
Otto 5:15 pm on September 13, 2012 Permalink |
I don’t know what talks you speak of in particular, but a) no and b) knowing the version of code being used is not an inherent security risk.
A security risk is caused by running insecure code. The solution is not to attempt to hide the version, but to update the code to eliminate the security risk. This sort of thinking is along the same lines of hiding the WordPress version number from public view. Hiding your version number doesn’t improve security in the slightest. Fixing security related issues does.
Chuck Reynolds 10:46 pm on September 13, 2012 Permalink |
true, i can’t find the specific thing I read the other day but… whatever. just thinking out loud.
Moved all my plugins’ screenshots to /assets/ from trunk and latest tag.
Ian Dunn 7:54 pm on September 14, 2012 Permalink |
I think that’s only half true. Obviously, fixing security bugs is the most important thing, but security-through-obscurity isn’t inherently bad, if you understand it correctly.
Security shouldn’t be thought of as a binary thing — you’re either “secure” of “insecure” — and there are no silver bullets. Instead, it should be thought of in layers. Security-through-obscurity is a good first layer. It keeps the script kiddies away, so that you can focus your time on defending against real attackers.
It’d be stupid to rely on obscurity as your only layer, but it’s a good practice to employ it as the first layer among many.
Ben Lobaugh (blobaugh) 5:12 pm on September 13, 2012 Permalink |
Thanks Otto
@Chuck – good point, you would lose the tagged readme files though. Maybe the readme.txt file should just be blocked from serving?
scribu 5:53 pm on September 13, 2012 Permalink |
This makes sense. I just moved the screenshots over for all of my plugins.
I noticed that the readme.txt example doesn’t point to the new
/assets/dir yet.Otto 6:06 pm on September 13, 2012 Permalink |
Didn’t think of that one. Fixed.
Jon Brown 8:52 pm on September 13, 2012 Permalink |
http://wordpress.org/extend/plugins/about/faq/ needs updating too.
Thomas_Michaela 6:40 pm on September 13, 2012 Permalink |
Is there any discussion / ideas how to redesign the “popular plugins” section, so authors don’t need to fake their download numbers anymore?
http://wordpress.org/support/topic/plugin-all-in-one-seo-pack-another-update-with-no-changes-this-plugin-is-just-scam?replies=8
Otto 7:18 pm on September 13, 2012 Permalink |
That doesn’t appear to be faked to me, just a bad development practice.
Edit: Note that if you have hard evidence other than a one-time-thing, then that’s different. I’ll burn and salt the earth with the ashes if you can find a real case of somebody gaming our systems, but this does not appear to be such a case.
Jon Brown 7:36 pm on September 13, 2012 Permalink |
This all sounds great, nice work!
Since I’m still a little slow when it comes to SVN though… Am I correct that /Assets is outside of version control? If that’s that case, I think that alone is reason to keep the readme files inside trunk, but even if that is not the case I’d still prefer seeing readme files in the zips.
Otto 7:45 pm on September 13, 2012 Permalink |
No, you’re not correct, and I’m not sure I understand the question.
SVN is a version control system. Everything in it is “in version control”. So… yeah, you’ve left me confused.
And there’s no plan (nor reason) to put readme.txt files anywhere that isn’t part of the plugin and isn’t in the ZIP file. That’s not under discussion nor up for debate, really. Readme’s should be sent with the plugin files.
Jon Brown 7:52 pm on September 13, 2012 Permalink |
Thanks Otto, I poked around trac and figured it out…
I was thinking that the /Assets folder was outside of version control because it wasn’t inside /branches or /trunk, it’s clear that’s not accurate since it gets assigned revision numbers. The svn tree /branch /trunk /tags just always confuses me…. someday it’ll click.
Otto 7:55 pm on September 13, 2012 Permalink |
Try the writeup I wrote about it here:
http://make.wordpress.org/plugins/2012/06/09/the-plugins-directory-and-readme-txt-files/
Edward Caissie 8:03 pm on September 13, 2012 Permalink |
I must be slow or its not enough coffee today … to implement this new ‘assets’ directory the plugin author needs to send a commit with it included, correct? In other words, the assets directory is not being (has not been?) populated into the existing repository plugins (nor is it part of new plugin repositories).
Otto 8:13 pm on September 13, 2012 Permalink |
Correct, the /assets directory is not created for you. You can create it at the root of your plugin directory, alongside the trunk and tags and branches directories, and use “svn add” to add it and any files inside it to your next commit.
Edward Caissie 8:29 pm on September 13, 2012 Permalink |
Thanks. I had tested that with an existing plugin as well as checking out a newly created plugin repository as well. Just been having SVN client issues recently and wanted to make sure I was not _doing_it_wrong().
Matt Mullenweg 6:46 pm on September 14, 2012 Permalink |
Can we add it to the script that sets up directories for new plugins?
Otto 6:50 pm on September 14, 2012 Permalink |
We could, just haven’t seen the need to do so. Not everybody needs it, in the same way that uber-simple plugins don’t really need a readme.txt file.
I’ll go ahead and add it though.
elfin 8:58 pm on September 13, 2012 Permalink |
excellent – one reason why I never included any to begin with was because of the file size issue. Nice work again Otto.
shazdeh 10:38 pm on September 13, 2012 Permalink |
Totally makes sense!
Greenweb 1:30 pm on September 14, 2012 Permalink |
Great update to the system !
XYZScripts 6:08 am on September 15, 2012 Permalink |
Good move. Really saves on zip size.
Next we should separate out readme.txt from folder as Chuck said.
I think right now readme.txt is parsed from trunk until stable tag is found and then it starts parsing stable tag readme.
So we have put this file in both trunk and tag which is simply duplicate.
I dont think readme.txt is needed in s wordpress installation as it reads info from plugin main file (Correct me if an wrong)
So why not move it to assets?
Otto 2:13 pm on September 15, 2012 Permalink |
No, the readme.txt file belongs with the plugin file itself and should be in the ZIP file. Moving it to assets makes no sense.
The readme.txt will remain where it is.
Lance Cleveland 1:28 pm on September 17, 2012 Permalink |
Great decision. It is smart thinking like this that keeps WordPress ahead of all others and why I continue to recommend it as the best-of-breed for web publishing for my clients.
Aaron D. Campbell 2:08 pm on September 17, 2012 Permalink |
This was a great change. One of my plugins went from a 168k download to 52k. Thanks Otto.
wiredimpact 9:26 pm on September 28, 2012 Permalink |
This is a welcome change. It will greatly decrease the size of plugins. Thanks.
Aman 8:43 am on October 4, 2012 Permalink |
A very great decision
Less size more downloads
Ben 7:50 pm on October 14, 2012 Permalink |
Awesome news!
I was wondering if you guys where thinking about doing something for the languages files as well?
I know that means also adapting the way a plugin is installed as well, but the more translations the heavier your plugins gets. Just leaving the .mo files it can be about 100k per language depending on the plugin’s size. Translate your plugin in 10 languages and Bam you get 1Mo extra.
Thanks!
Otto 5:42 pm on October 16, 2012 Permalink |
No particular plans for languages, but that would be pretty cool. I was thinking more along the lines of having core support for language packs. Like, we could have a big GlotPress install somewhere to allow community translations of plugins and themes, then have an API to serve up-to-date .mo files, then serve them directly to users that request them, and let the core put them in the right place, etc.
Would be neat, but obviously that’s a big job there, with a lot of moving parts.
Ben 8:59 am on October 17, 2012 Permalink |
Sounds good, if we’re aiming to this kind of solution, that’s just perfect. But as you said it feels like a lot of changes and work involved.
Milan Dinić 6:34 pm on October 23, 2012 Permalink |
Still in works.
Milan Dinić 6:36 pm on October 23, 2012 Permalink |
How about displaying “Screenshots” tab only when there are screenshots, not always when “Screenshots” section of readme.txt has any content?
Joe Dolson 7:29 pm on October 22, 2012 Permalink |
The recent changes to the plug-in directory have been great — I noticed something today that I’m hoping would be a pretty quick fix: you can’t do a search on the words ‘accessibility’ or ‘accessible’. You can visit the tags, of course, but I don’t think it’s really the right response to send searches for these two terms to the results for ‘access’ — those are definitely two very distinct searches, and really should be giving different results.
Otto 7:40 pm on October 22, 2012 Permalink |
There’s no limitation on what you can search for. But the search engine considers similar words to be similar for the purposes of searching.
Joe Dolson 8:42 pm on October 22, 2012 Permalink |
Well, it’s definitely a problem — is there any way to tweak what the search engine considers to be similar? “access” and “accessibility” may be similar from a programming standpoint, but in terms of the search intent, they’re radically different – and I think it’s a serious limitation to the repository that you can’t easily find plug-ins that are intended to support accessibility.
Otto 8:57 pm on October 22, 2012 Permalink |
Well, did you try looking by tag instead?
http://wordpress.org/extend/plugins/tags/accessibility
Joe Dolson 10:25 pm on October 22, 2012 Permalink
Yes, as I said above. If the search can’t be modified, then it can’t be modified; but it would be valuable, since the search results are really fairly inaccurate for that term. There are over 1,000 results for ‘access’, but only a handful of them pertain to accessibility.