[wp-hackers] WordPress File API Stream Wrapper Support: GSoC 2010 Project Proposal

Jon Stacey jon at jonsview.com
Fri Apr 9 17:29:37 UTC 2010

Hi Otto,

Thanks for looking over my proposal. You raise some good concerns
(concerns that even I had) and we had similar discussions in #Drupal-dev
last year. I don't have those transcripts on hand, but we finally decided
that allow_url_fopen should not be an issue and is enabled by default [with
PHP]. However, allow_url_include is a different beast. Fortunately, I have
no intention of pushing stream wrappers to that level where they would need
to be used in functions include(), include_once(), require(), or
require_once(). While I don't think allow_url_fopen will be a serious
issue, every effort will be made so that basic functionality (i.e. what WP
has now) won't be degraded on hosts where those settings can't be changed.

To address your second issue, the biggest takeaway is that it encourages
interoperability between plugins that deal with files, and opens the doors
to new kinds of functionality. For example, more seamless integration with
services like Amazon S3 or Limelight. A formal File API will need to be
drafted and implemented and then integrated with the rest of WP core. That
is if the implementation is decided to be part of core. Another option that
I am open to and included in the proposal was developing this as an
optional module. It is true that plugins can use stream wrappers now, but
they do so on their own. Every plugin has its own way of dealing with files
that are usually not compatible with other plugins that deal with files
(e.g. S3, CDN, local, etc.). Additionally, as we discovered in the Drupal
implementation there are several limitations of the PHP implementation that
must be augmented by our API. 

This API would contain a wrapper registry that supplements PHP's lacking
implementation and integrates with the WP Plugin system [wrappers can be
installed/uninstalled at anytime]. Additional functions that provide
correct behavior will be needed to make up for the shortfall of PHP such as
chmod(), dirname(), and several others. The API would also have several
methods for interacting with streams in different ways (e.g. expanding
URIs). Finally, the API would provide a large set of methods to ease the
management of files and make repetitive tasks more streamlined. For a more
comprehensive information on _some_ of the methods that would be
implemented take a look at what was done for Drupal 7 here:
http://api.drupal.org/api/group/file/7. Not all of those are needed for
WordPress, but many of them would be very useful to have and they have the
added benefit of working out the kinks in PHP's stream wrappers that
developers might otherwise have to handle on their own.

I would love to elaborate a bit more but I'm out of time. I'll be in and
out of classes all day, but I'll respond to any additional concerns or
questions you may have as quickly as I can.

Best regards,

Jon Stacey

On Apr 9, 2010, at 8:48 AM, Otto <otto at ottodestruct.com> wrote:

> Thoughts:
> - The settings of allow_url_fopen and allow_url_include and similar
> are disabled on almost all hosts I've ever used, for security reasons.
> This will severely limit the usefulness of the stream wrapping, no?
> - What would be the usefulness anyway? We don't really have a "File
> API" in WordPress, so I'm not quite seeing how this would benefit
> anything. If a plugin wants to use a stream wrapper, it can do so now.
> What would this API add, exactly?
> -Otto
> On Thu, Apr 8, 2010 at 11:40 PM, Jon Stacey <jon at jonsview.com> wrote:
>> Hello,
>> I have created a new project proposal for Google Summer of Code  
>> this year that I would like to gather some feedback on.
>> Abstract:
>> The goal of this project is to improve the file handling  
>> capabilities of WordPress by making PHP's stream wrapper  
>> functionality a part of the File API. PHP stream wrappers allow  
>> virtually any type of resource to be represented as a normal file.  
>> Stream wrappers will make the implementation details of file  
>> management transparent to developers fostering cross plugin  
>> interoperability and increasing the flexibility of WordPress.
>> Here is a link to the official proposal:
>> Here is a link to my WP-powered blog with a better formatted  
>> proposal:
>> I look forward to hearing your thoughts and wisdom!
>> Jon Stacey
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers

More information about the wp-hackers mailing list