Web hosts, a word on upload_max_filesize and post_max_size

From WordPress installs hosted at various places, I’ve tried to upload a modest 48 second video shot on a Nexus 5. This is what I usually see:

Screen Shot 2014-05-16 at 8.32.16 AM

Can upload_max_filesize and post_max_size be set to accommodate a one minute video shot on a modern phone, at the very least?

And, WordPress, let’s make this message less of a dead end. It’s frustrating as hell to do something as natural as upload a short video and get this red-stained too bad.

 

WordPress 3.6 + Audio/Video

Originally posted on Scott Taylor:

Screen Shot 2013-08-01 at 1.39.43 PM

I have already written once about the new support for Audio / Video in WordPress 3.6:
http://make.wordpress.org/core/2013/04/08/audio-video-support-in-core/

I also spoke about the new features in my Code Poet interview:
http://build.codepoet.com/2013/07/18/scott-taylor-interview/

I wanted to use this space to give the users some information about the new code and how to take advantage of it.

Upload Limits

A lot of Apache / PHP installs have an arbitrarily low file upload size limit set (usually 2MB). An average .mp3 file is at least 3-5MB. Video can be way bigger. If you are on a shared host that doesn’t allow uploads over a certain size, you may have to get more creative about where your audio and video files are stored. The only difference will be not having them in your media library. You can use all of the new a/v features with remote files.

If you have access to your own…

View original 647 more words

Rdio and Spotify oEmbed Support in WordPress 3.6

In an effort to make the new Audio Post Format UI more useful, we added Rdio and Spotify to the default oEmbed providers list for WordPress 3.6. Spotify and @nicklas2k were kind enough to whip up an oEmbed endpoint for us to use. Thanks!

To celebrate, here are a couple of albums released in 2013 that I’m enjoying.

WordPress Theme Licensing

The WordPress community is currently having a big debate over whether themes are considered derivative works of WordPress as per the GPL, the license used by WP.  The SFLC has previously declared that they consider the PHP code in WP themes a derivative work.  Other open source CMS software makers, such as Drupal, also consider themes derivative.  Drew Blas has a thoughtful post where he compares WP themes to Linux applications and likens declaring themes as derivative the equivalent of declaring Linux applications as derivative.  I left a few comments on his post noting that a more apt comparison is with Linux Kernel Modules (LKMs) rather than applications running on top of Linux.  Linux applications are more comparable to XML-RPC clients that use WP’s XML-RPC API.  Neither Linux applications nor XML-RPC clients are considered derivative.  LKMs, however, are considered by many Linux developers to be derivative works.  LKMs load directly into the running kernel and have direct access to internal data structures and APIs.  WP themes are the same way.  They load directly into WP and have access to WP internals.  The distinction between the different classes of interactions is important when discussing the letter of the GPL as well as the general spirit in which many authors of open source software regard modules, themes, and plugins that extend their works.

I’ve not followed Linux kernel development closely for the past few years, but as far as I know the debate over LKMs never definitively resolved itself.  A system was put in place where LKMs could declare their license using a MODULE_LICENSE macro.  Licenses that are not GPL-compatible “taint” the kernel.  Many Linux developers will not assist with tainted kernels.  I doubt we would do something similar with WordPress.  Many WP developers already refuse to help with proprietary themes.  Adding some API doesn’t help clarify anything.  Unfortunately, the only thing that would is a lawsuit that goes the distance.

So, where do I stand as one of the primary copyright holders of WordPress?  I’d like to see the PHP parts of themes retain the GPL.  Aside from preserving the spirit of WordPress, respecting the open source ecosystem in which it thrives, and avoiding questionable legal ground, retaining the GPL is practical. As Drew Blas notes, the theme that sparked this debate copies WP code.  Most themes copy WP code.  Unlike the argument that all themes are derivative by nature, there is little debate that themes that copy code should retain the GPL.  Going out of your way to create a theme that does not borrow a single line of code from the WP community is wasted effort.  As attested by several theme makers who license under the GPL, the license has no affect on business. Why generate ill will by using a proprietary license?  What value is there in that?  Unlike LKMs, WP themes do not have to deal with hardware NDAs and DRM, closed source third-party code, or any of the other legal hassles that sometimes force an LKM to be closed source.  Themes live in the world of the fully open source web stack.  Since you are still free to license the CSS and images in your themes as you see fit, challenging the WP community over the license of the PHP code seems like bad business.

2.8 Plugin Compatibility

Some plugins are causing grief for those upgrading to 2.8.

  • HyperDB needs to be updated to the latest version, otherwise tags won’t save.
  • DB Cache also prevents tags from being saved. I haven’t seen an update for it yet.
  • Plugins that load old versions of jQuery for all admin pages will break all kinds of stuff.  Plugins should use the version of jQuery that ships with WP.  If a plugin must use a particular version of jQuery, that version should be queued only for the plugin’s own pages.
  • Themes that call get_categories() from functions.php before the init action fires will fail.  2.8.1 will workaround this, but ideally these themes should update so that they can handle custom taxonomies properly.