Vote for 2.9 Media Features

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.



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.

Themes are GPL, too

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’ 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’ 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 http://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.

WordPress 2.8.1 Beta 2

2.8.1 Beta 2 is ready for testing.  Download it, check out the changes since beta 1, and review all tickets fixed in 2.8.1.  We especially suggest, recommend, and beg that plugin developers test their plugins against beta 2 and let us know of any issues.  Notable fixes in beta 2:

  • 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

Thanks again for testing WordPress.

WordPress 2.8.1 Beta 1

We’ve started work on the first maintenance release to 2.8.  2.8.1 will fix a handful of bugs that turned up in 2.8.  Today we’re releasing the first beta of 2.8.1.  Download it, and check out the bugs fixed so far.  Here are some of the notable issues that are fixed in beta 1.

  • 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.

If you would like to automatically upgrade from 2.8 to 2.8.1 Beta 1, follow these instructions.  Thanks for testing WordPress.