Earlier this month, over 3500 of you responded to our survey asking you to help us prioritize some of the media features that had been suggested for the 2.9 release. While the exact features for 2.9 have not been hammered out yet, as we continue to match up developers with features, we wanted to share the survey results and let you know what we’re thinking in terms of approach.
First, the results. The first question, and the only one that was mandatory, asked what single media feature you would choose to include in version 2.9. The top vote-getter was standalone editable photo albums (as opposed to the current per-post gallery) at 17.5%, followed closely by easier embeds for videos and other third-party content at 16.5%. Next came basic image editing (such as rotating, cropping and resizing) at 13.7%, and post thumbnails (image teasers for posts featured on the home page) at 12.9%. The rest of the features each took less than ten percent of the vote. The full list came in like this:
The second question was optional (3406 people answered it), and asked you to rate each feature on a scale going from top priority down to definitely not for implementation priority. Results here were in line with the results from the first question, with most features rated as nice to have more often than anything else. The features that scored the highest in question 1 were more likely to have earned higher votes in the Top Priority column, but no feature was ranked as a Top Priority more often than it was ranked as a Nice to Have (though Media Albums, Easier Embeds and Post Thumbnails came close). The complete tabulations are shown in the chart below.
Question three was getting at the same thing, but in a more granular fashion, asking you to rank the eleven features in order of priority to you. As only one feature could be assigned to each position, this prevented people from assigning the same priority to multiple features, and we wondered if it would alter the results. Though some features got more recognition in this question, the overall rankings were still in line with the results from question 1. Here are the exact votes per feature/per position:
The fourth question asked for your preferences regarding including new media features in core, bundling them as plugins with the core download, or developing them as plugins but not bundling them with the core download. This vote was more interesting to watch. As the notice for the voting went first to the development community, then to the user community, it was possible to see a shift in the voting. Earlier in the voting cycle, there were more votes for bundling ‘core plugins’ for the advanced media features, while later votes skewed heavily toward just putting the features in core. This vote shows, I think, one of the differences between developer and user perspectives. While developers are heavily interested in keeping the core code lean and relying on plugins for advanced functionality, many users would prefer features they want to be included in core rather than being a separate plugin. The final tally on this question was 56.2% for including features in core, 38.1% for bundled plugins, and 5.7% for non-bundled plugins. The actual numbers:
Clearly this issue deserves more discussion, and the concept of how we move toward a system of canonical plugins and/or core “packages” intended for different use cases (CMS, photoblog, portfolio, etc) will be a big topic in the months ahead.
So where does that leave us regarding features coming down the road? When the vote closed, the results were discussed in the #wordpress-dev IRC chat to divvy up feature development.
The top-voted feature, standalone photo albums, is being worked on as a Google Summer of Code project by Rudolf Lai, under the mentorship of WordPress Lead Developer Mark Jaquith. The “pencils down” date for GSOC is in less than two weeks, at which point we’ll be assessing the state of Rudolf’s project. Hopefully, we’ll be able to incorporate it with 2.9 development, do some testing, amend the code and/or UI as needed, and have this launch with the 2.9 release (in core or as plugin TBD). Undoubtedly, additional functionality will be contributed by core contributors who have also been working on media plugins.
Easier embeds, the second most popular feature, is being looked at in a couple of ways. One, more shortcodes for third-party services. Work on this has already begun. In addition, Viper007Bond, of Viper’s Video Quicktags plugin fame, has taken on the task of working on a way to improve the embed experience in core. We’re not sure quite how this will work yet, but stay tuned.
Adding some basic editing functions like 90-degree rotation, cropping and resizing was considered an obvious winner in the dev chat, and as several plugins handle this functionality, we’re hopeful it will be included soon.
Post thumbnails are being handled by Mark Jaquith, who has created this functionality before, with an assist from Scribu, who has a similar plugin in the repository.
Lower ranked features aren’t off the radar, but may take lower priority than some other (non-media) features we have in the works. One of my favorite 2.9 features is in trunk now, and changes the way we delete content. Goodbye, annoying popup asking me if I’m sure I want to delete a comment/post/etc. Hello, fast and quiet removal into a trash can, from which the content can be retrieved if it was deleted by accident. Think Gmail style. We’re also hoping to work on improving page management, though that has a number of technical issues that may cause it to be a 3.0 feature instead.
As always, you can keep track of development progress in a number of ways:
1. Keep track of Trac. Contribute a patch, test a patch, just read through tickets if you have some time to kill, whatever. There are over 500 tickets against the 2.9 milestone currently. Patches and testing can help us get that number down.
2. Follow Trac commits on Twitter. Don’t want to get involved in the nitty gritty, just want to see what’s getting committed? Follow wpdevel on Twitter and you’ll get core commit updates in your stream.
3. See what’s on the dev agenda. Each week for the IRC dev chat, there’s an agenda, created based on developer suggestions posted at wpdevel.wordpress.com. This blog also contains discussions about specific development issues.
4. Join the dev chat. The day changed this week, to accommodate European schedules. Chats are now held for one hour each week on Thursday at 21:00 UTC. That’s 5pm NYC, 2pm in California, etc. Chats are in the #wordpress-dev room at irc.freenode.com.
5. Watch this blog. If you’re not a developer and prefer to stick to major announcements, the occasional survey to help decide a feature, and security notices, just keep doing what you’re doing. Reading this blog will get you all of these things.
Thanks again for your help in prioritizing features for version 2.9, hopefully coming toward the end of the year to a server near you!
Like this:
Like Loading...
The WordPress team had initially committed to maintaining the WordPress 2.0.x legacy branch until 2010. Unfortunately, we bit off more than we could chew—the 2.0.x branch is now retired and deprecated, a few months shy of 2010.
Many of the security improvements to the new versions of WordPress in the last couple of years were complete reworks of how various systems were handled. Porting those changes to the 2.0.x branch would have been a monumental task and could have introduced instability or new bugs. We had to make hard decisions between stability and merging in the latest security enhancements. Additionally, far fewer people stayed on the 2.0.x branch than we anticipated. I take that as a testament to the new features in WordPress and perhaps even more the features offered by plugins, many of which don’t support older versions of WordPress!
I’m disappointed that we weren’t able to keep the branch maintained until 2010, but since one of the big reasons for that failure was the massive scope of our security improvements for the newer versions of WordPress, 2.0.x doesn’t die in vain!
Like this:
Like Loading...
We’ve recently made some changes to help improve the communication between plugin authors and plugin users about the changes that are made between versions.
We feel that all software should have a changelog that details, at a high level, what changes have been made in each version so that the user can make an informed decision about when to upgrade and how much testing they should do with their site.
In order to make this an easy and open communication channel we have added support for a Changelog section in the plugins readme.txt file. This changelog information is then displayed as a separate tab in the plugin directory and also in the back end of your WordPress blog when you view the details on a new version of a plugin.
The new section is formatted as follows:
== Changelog ==
= 1.0 =
* A change since the previous version.
* Another change.
= 0.5 =
* List versions from most recent at top to oldest at bottom.
We would also like to recommend that you also provide meaningful log messages when you commit changes to the subversion repository for your plugin so that people who want to dig further into your changes can see why things are changing (At the moment is seems a large number of plugin authors leave this field blank which isn’t very helpful).
Like this:
Like Loading...
WordPress 2.8.1 fixes many bugs and tightens security for plugin administration pages. Core Security Technologies notified us that admin pages added by certain plugins could be viewed by unprivileged users, resulting in information being leaked. Not all plugins are vulnerable to this problem, but we advise upgrading to 2.8.1 to be safe.
What else is new since 2.8? Read through the highlights below, or view all changes since 2.8
- Certain themes were calling get_categories() in such a way that it would fail in 2.8. 2.8.1 works around this so these themes won’t have to change.
- Dashboard memory usage is reduced. Some people were running out of memory when loading the dashboard, resulting in an incomplete page.
- The automatic upgrade no longer accidentally deletes files when cleaning up from a failed upgrade.
- A problem where the rich text editor wasn’t being loaded due to compression issues has been worked around.
- Extra security has been put in place to better protect you from plugins that do not do explicit permission checks.
- Translation of role names fixed.
- wp_page_menu() defaults to sorting by the user specified menu order rather than the page title.
- Upload error messages are now correctly reported.
- Autosave error experienced by some IE users is fixed.
- Styling glitch in the plugin editor fixed.
- SSH2 filesystem requirements updated.
- Switched back to curl as the default transport.
- Updated the translation library to avoid a problem with mbstring.func_overload.
- Stricter inline style sanitization.
- Stricter menu security.
- Disabled code highlighting due to browser incompatibilities.
- RTL layout fixes.
Like this:
Like Loading...
Last Wednesday, the core development team and a number of contributing developers met in the IRC #wordpress-dev channel to talk about which features should be included in version 2.9, which is now entering the development phase. We’ve been planning to focus on media features in 2.9 for some time, and unsurprisingly, it was media features that dominated the discussion.* A large percentage of the requests we get from users are for more/better media features, so we’ve decided to focus 2.9 on building an infrastructure for improved media handling that we can continue to build on in versions to come. In that vein, we need your input to determine which features to prioritize and build sooner rather than later.
These are the features that we’re asking people to vote on (in alphabetical, not prioritized, order):
Additional Media Filters: In the uploader, you can currently upload an image from your hard drive, link to an image from a URL, or select an image from the Media Library. This proposed feature would add links in the Media Library pane that would allow you to filter images to those that had been used most recently, used most often, and/or marked as a favorite. These filters would be available on the Media Library screen as well.
Basic Image Editing: Enable cropping, resizing and 90-degree rotation of uploaded images.
Better Media Settings: Enable the creation of more default media settings controlled in the Settings section, and allow settings to be overridden during the individual media upload process as needed.
Bulk Media Import API: Develop an API to allow for bulk media importing by plugins or importers.
Custom Image Sizes: Instead of hardcoded thumbnail, medium, large, etc. image sizes, custom image sizes would allow you to configure the maximum dimensions for each of the sizes.
Easier Embeds: Make it easier to embed third-party content such as YouTube videos, etc. Similar to Viper’s Video Quicktags plugin.
Media Albums: Ability to create and edit photo albums that can stand alone (as opposed to galleries being tied only to a post), including photostream functionality.
Media Metadata: Enable the use of categories and tags on media files.
Photostream: Create a Flickr-style photostream that simply displays images in a chronological stream (as opposed to grouping in galleries).
Post thumbnails: Choose an image to appear as a thumbnail with your post/article/excerpt.
Revised Media UI: Redesign the uploader UI to make uploading and editing media files a simpler, more user-friendly process.
These descriptions are repeated in the beginning of the voting survey, so if you forget what something means you’ll be able to scroll up to remind yourself. Only the first question (pick your top choice) is mandatory. This survey isn’t very long. Question two lets you assign a general high/low priority to each of the 11 feature suggestions, while question 3 asks you to rank the 11 features in order of priority from 1-11. A text box or two allow you to make additional suggestions, and that’s it. The survey is anonymous, and will be open all week, until Friday, July 10, 2009 at 11:59 PM UTC.
var PDF_surveyID = ‘2F95783C8744F81A’;
var PDF_openText = ‘Vote now!’;
Vote now!
No JavaScript? Take the survey here.
Results of the survey will be used to help developers decide which features to focus on for version 2.9. The 2.9 anticipated feature list will be posted here later in July, after the priority has been determined. How many contributing developers are available to code various features will play a large part in the decision-making process, so if you’ve ever thought of contributing code to WordPress development, now’s a great time to get involved. Developer chats are held each Wednesday in the IRC channel (irc.freenode.com #wordpress-dev) at 9 PM UTC (5pm Eastern, 2pm Pacific).
* – Other non-media features that were discussed either were determined to be better held for a future version for technical reasons, or were so widely desired that they were accepted for the 2.9 roadmap without requiring a vote.
Like this:
Like Loading...
If WordPress were a country, our Bill of Rights would be the GPL because it protects our core freedoms. We’ve always done our best to keep WordPress.org clean and only promote things that are completely compatible and legal with WordPress’s license. There have been some questions in the community about whether the GPL applies to themes like we’ve always assumed. To help clarify this point, I reached out to the Software Freedom Law Center, the world’s preëminent experts on the GPL, which spent time with WordPress’s code, community, and provided us with an official legal opinion. One sentence summary: PHP in WordPress themes must be GPL, artwork and CSS may be but are not required.
Matt,
You asked the Software Freedom Law Center to clarify the status of themes as derivative works of WordPress, a content management software package written in PHP and licensed under version 2 of the GNU General Public License.
We examined release candidate 1 of WordPress 2.8, which you provided to us at https://wordpress.org/wordpress-2.8-RC1.tar.gz. The “classic” and “default” themes included in that release candidate comprise various PHP and CSS files along with an optional directory of images. The PHP files contain a mix of HTML markup and PHP calls to
WordPress functions. There is some programmatic logic in the PHP code, including loops and conditionals.
When WordPress is started, it executes various routines that prepare information for use by themes. In normal use, control is then transferred via PHP’s include() function to HTML and PHP templates found in theme package files. The PHP code in those template files relies on the earlier-prepared information to fill the templates for serving to the client.
On the basis of that version of WordPress, and considering those themes as if they had been added to WordPress by a third party, it is our opinion that the themes presented, and any that are substantially similar, contain elements that are derivative works of the WordPress software as well as elements that are potentially separate works. Specifically, the CSS files and material contained in the images directory of the “default” theme are works separate from the WordPress code. On the other hand, the PHP and HTML code that is intermingled with and operated on by PHP the code derives from the WordPress code.
In the WordPress themes, CSS files and images exist purely as data to be served by a web server. WordPress itself ignores these files[1]. The CSS and image files are simply read by the server as data and delivered verbatim to the user, avoiding the WordPress instance altogether. The CSS and images could easily be used with a range of HTML documents and read and displayed by a variety of software having no relation to WordPress. As such, these files are separate works from the WordPress code itself.
The PHP elements, taken together, are clearly derivative of WordPress code. The template is loaded via the include() function. Its contents are combined with the WordPress code in memory to be processed by PHP along with (and completely indistinguishable from) the rest of WordPress. The PHP code consists largely of calls to WordPress functions and sparse, minimal logic to control which WordPress functions are accessed and how many times they will be called. They are derivative of WordPress because every part of them is determined by the content of the WordPress functions they call. As works of authorship, they are designed only to be combined with WordPress into a larger work.
HTML elements are intermingled with PHP in the two themes presented. These snippets of HTML interspersed with PHP throughout the theme PHP files together form a work whose form is highly dependent on the PHP and thus derivative of it.
In conclusion, the WordPress themes supplied contain elements that are derivative of WordPress’s copyrighted code. These themes, being collections of distinct works (images, CSS files, PHP files), need not be GPL-licensed as a whole. Rather, the PHP files are subject to the requirements of the GPL while the images and CSS are not. Third-party developers of such themes may apply restrictive copyrights to these elements if they wish.
Finally, we note that it might be possible to design a valid WordPress theme that avoids the factors that subject it to WordPress’s copyright, but such a theme would have to forgo almost all the WordPress functionality that makes the software useful.
Sincerely,
James Vasile
Software Freedom Law Center
[1] There is one exception. WordPress does reads CSS and image files to create previews of templates for the template selection portion of the administrative interface. Even in that case, though, nothing in those files calls any WordPress functions, is treated as a command by PHP, or alters any other WordPress data structure. These files are read as data and used to create an image and display a miniaturized version of a webpage to the user.
Even though graphics and CSS aren’t required to be GPL legally, the lack thereof is pretty limiting. Can you imagine WordPress without any CSS or javascript? So as before, we will only promote and host things on WordPress.org that are 100% GPL or compatible. To celebrate a few folks creating 100% GPL themes and providing support and other services around them, we have a new page listing GPL commercially supported themes.
Like this:
Like Loading...
Recent Comments