If you have a plugin with the sole purpose of embedding video into WP posts, or one that makes HTML5 work in WP, you need to know that there is HTML5 support for Audio and Video coming in WordPress 3.6, so please test ASAP.
Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts
To use the Maps API on an intranet or in a non-publicly accessible application, please check out Google Maps API for Business.
So please update your plugins.
(Props to Kailey Lampert for this post)
Imagine that another plugin author has asked you to look at a plugin that is currently in development to check for security flaws and help them fix any that are present. Would you know what to look for and how to fix the problems? Well, a fun challenge has arrived that will test, and hopefully improve, your knowledge in this crucial area of plugin development. I have developed a small, bug ridden plugin that requires a rigorous security review and suggestions for fixes.
The code is available from https://gist.github.com/joncave/5348689.
This is an incomplete plugin that aims to log any failed login attempts. Unfortunately, it actually harms the security of a site rather than enhancing it. All of the interesting parts are in
vulnerable.php, so you should focus your review there. Please remember not to run this plugin on any server that is accessible to the internet!
If you spot a vulnerability whilst reviewing the code then make a note of the problem, where it’s located and what the problem is. Then come up with a patch that would solve the problem. It might also be beneficial to create a request that would demonstrate the vulnerability which can then be used to test your fix. I hope that this process will help you understand more about vulnerabilities, what sorts of things to look for when reviewing your own code, how to go about coding securely, and how to fix any problems in your own plugins if a flaw is found.
If you would like individual feedback on your finding and solutions, and to provide me with some information on which bugs people found and fixed, you can submit them via this survey. Please refrain from posting any spoilers in the comments for now.
In a week or so I will write another post detailing each of the vulnerabilities present in the code and how to fix them.
Bonus challenge: with access to a subscriber level account can you find any ways of extracting the data from an option named
Version 1.0 of their API is going away very soon, so if you happen to be using that, your plugin will break.
You should keep up with Twitter’s Calendar and update your plugins to the latest versions of the API as soon as possible to prevent angry users and broken plugins.
We don’t track our progress as a project very well. We have relatively few stats that we look at over time to see how we’re growing/changing, and those we do have are largely cobbled together with various combinations of manual labor and scripting. One of the things I want to do this year is get us going in the direction of collecting stats on our work and participation levels, and to make as much of it as possible an automated process. I recognize that this stuff is non-trivial. That said, I can’t create an overall wishlist for Otto to shoot down until we figure out what stats would be good to have.
What stats would be useful/helpful/just plain cool to know around your team? This is brainstorming… don’t think about APIs or if/how it could be collected, just throw out ideas in the comments of what information you think it would great to start seeing, say on a monthly basis. List any and all ideas, including stats you are already collecting. I’ll collate all the teams’ ideas and see what the Meta team says we can do.
@coffee2code: As team rep, can you try to rally your group to make suggestions over the coming week? Thanks!
9 people voted. Results: Scott Reilly as first lead, Pippin Williamson as second lead. New team rep terms starts with the new year, so I’ll get in touch with you guys to make sure everyone is on the same page re expectations. Congratulations, and thanks for your willingness to serve!
All plugins hosted in the WordPress.org repository must be compatible with GPLv2 or later. That means all code that is on our servers, from images to CSS to JS to the PHP code, has to meet that requirement. This is an extra requirement than just the standard one of derivative code, but we strongly feel that proprietary content has no need to be in our repository. If your code needs to be split licensed, or you have to included proprietary code for any reason, we can’t host you on .org, but that has no bearing on how neat and cool your code might be.
For a list of various licenses, and their compatibility with GPLv2 please read this: http://www.gnu.org/licenses/license-list.html – We know not all of you are lawyers, and thankfully that list makes it easy to check what licenses do and don’t mesh. If something doesn’t have a license, ask the author please, and don’t assume.
The following code bases are popular (which is to say we see submissions with them pretty regularly), but at the time of this post, are not licensed GPL-compatible. None of this means you can’t or shouldn’t use this code on your sites or plugins, just that we can’t host it here if you do.
- Adobe Air
- FancyBox v2 or later
- Font Awesome (Edit: Version 3.0 of may or may not be compatible, it’s confusing)
- FLV Player
- HTML 5 Music Player (Code Base Hero) (only pre version 1.0.1 – you can use this version)
- jquery Lightbox
If there are plugins you find using these (or any non-GPL-Compatible) code bases in their plugin, please email plugins AT wordpress.org and we’ll get in touch with the developer. If you’re the author of one of those code bases, please consider re-releasing your code under a GPLv2 Compatible license! We’d love to be able to host your work here.
Time to vote for team reps again! If you haven’t seen the spiel on one of the other team blogs about how team reps/voting/terms work, the longer explanation is after the jump. tl;dr version: time to elect reps for the first half of 2013. This past time it was Mark Riley and Scott Reilly, but since then Mark has stepped back from heavy involvement with plugins so you need at least one new rep.
Note: It can’t be folks who are already the team reps for other teams, and it should be folks who want to the responsibility (mostly posting weekly updates on team activity to the weekly updates blog). Since there are some newer members of this group it might be nice for one of them to level up and learn the ropes from Scott? Up to you guys. Anyone interested in being a plugin team rep should leave a comment saying as much so people know who they can/should vote for. Voting is open until December 15, and results will be posted here once voting closes.
mordauk, It's That Time Again: Voting for Core Team Reps - WP Daily, Boone Gorges, and 4 others are discussing. Toggle Comments
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.