This plugin “extends” WordPress’s built-in media library with your Flickr account.
- download page (TBD)
- Github page
The goal here is to integrate Flickr into WordPress’s media library in order to keep and serve your image assets on Flickr instead of locally in from your server filesystem.
Other plugins embed html necessary to include a Flickr image in a post, but don’t take advantage of WordPress’s media library and thus have issues such as: adding featured images (post thumbnails), tracking and updating images where URL has changed, etc.
Because I don’t want to be destructive except on user action, this will not actually modify your existing WordPress media library, instead this tracks the Flickr media using a WordPress custom post type that is then injected into the media library.
Frequently Asked Questions
Why doesn’t this work?
Because this plugin is in development. It works enough for me to use on my personal blog. 😀
Why write another Flickr plugin?
I surveyed a ton of Flickr plugins out there. I found three sorts of plugins:
- hack TinyMCE to make it easier to embed a flickr image;
- include flickr images an album as a gallery; or
- publish a flickr album or stream as a widget.
I wanted to something different. Basically, I want to use Flickr as both the media library for my WordPress install as well the content delivery network to offload both disk space and bandwidth away from my blog.
Even if I use an plugin that embeds a flickr image (which I don’t because I edit in markdown on a local application when I blog), it runs into a number of issues including generating broken images if I replace the image and not playing nice with captions and post thumbnails.
Using oEmbed URLs generate code that isn’t responsive nor does it co-operate with picturefill to be retina-friendly. Furthermore, there is information like alt text and titles that goes unsupported. (Yes, alt and title attributes are different, WordPress core attachment handling is actually wrong.)
The goal (not achieved) is for this plugin to allow you me transparently inject flickr images as a first-class citizen in the media library.
Why isn’t the goal achieved?
There are three reasons.
The second reason (and a showstopper) is that WordPress core is written with tight integration between the media library and the native ‘attachment’ post type. There are places where key image rendering code assumes in a hard-coded manner that the post is an ‘attachment’ and not something that emulates an attachment and quits before any hook gets called. This is an unintended coding error probably because no core developer considered that you might want to use media that isn’t an attachment. If I have time, I will submit a core patch to fix this, but it is a large patch and cannot use any existing hooks/filters since current plugin developers may be making assumptions about them that would break their plugins. 🙁
The third reason is simply that the model WordPress has for media embedding is wrong, wrong, wrong. In particular, WordPress, at various points, writes the HTML asset in directly with no flexibility once it has been written beyond some
rel attributes that might-or-might-not point to the asset and size (it does size in an inconsistent manner depending on if you inserted the image via plugin or via the visual editor). This means that WordPress is not forward thinking (for example, captions are not responsive, images are not retina-ready, and attachments improperly interchange the
alt attributes throughout the code base). This plugin gets around that by choosing strategic areas to insert a shortcode that is processed at runtime to add correct functionality in. FML’s shortcode implementation also has the benefit of allowing you to easily “fall back” to legacy if this plugin is uninstalled.
Why not just make your plugin write WordPress attachments?
It’s not the recommended method. When you have a new asset of a different type, you are supposed to use a custom post type. The issue we’re running into is that WordPress assumes that all custom post types are customizations of native “posts” or “pages”, but not of native “attachments” (or menus or revisions). There are other parts of the codebase (like the capabilities field) where core has a misunderstanding of how post types interact with CMS intention. This is because real support for this feature was added very late (with version 3.0) and a lot of legacy got built up.
Furthermore inserting flickr as attachments (but without files) would cause a lot of breakages in a manner that can’t be fixed. For instance, WordPress assumes it can use gd to resize images, but Flickr images are only available at fixed sizes. Safe sites block acces to allow_url_fopen which would be needed to get image metadata from Flickr’s site (and only if “original” is accessible).
Furthermore, if you uninstall or deactivate this plugin, the attachment and flickr emulated data would be forever intermingled in a manner that can’t operate correctly without the plugin installed (and modifying attachment functions for compatibility)
How can I pay you gobs of money?
Three years ago, I was an employee of Automattic so WordPress has already been good to me. I don’t need the money and my rate now (as an engineering executive) would be too high to be practical to be paid for this hobby. My donate link is for Kiva and I have this code mirrored on github where it is easy to fork and keep up-to-date.
Instead, pay it forward by donating money to charity or contributing to open-source projects like WordPress core or plugin development.
- Too many to list