Make thumbnail creation pluggable

It'd also be nice if the size of the default thumbnail were filterable. I have not addressed that here.

Hey mdawaffe,

I've also submitted a patch that cleans up this area of WP, adding hooks and filters for attachments. The patch is here: #2682. Take a look at what I've written and you can probably integrate this idea into what I've put together.

With my patch, adding thumbnails is done in the wp_attach_upload action hook. I've implemented additional thumbnails in a plugin this way.

Glad I'm not the only one thinking about this, though. :-)

ryanscheuermann, I was unaware your ticket is as comprehensive as it is. From the title, I thought you were just changing the way the filename was stored in the DB :)

I've just glanced at your code. The advantage to the method I propose here for thumbnail attachment is that WP's default thumbnail creation code can be completely bypassed. In your patch, it will always run but can then be overwritten.

Yeah, it started out that way, and then I saw there was an opportunity to make the process a bit more organized and pluggable. When changing something as simple as abspath/no abspath proves to be more difficult than originally planned, there's probably something wrong with the whole process. :-) So I fixed it up a bit.

You're correct. My method was designed for the addition of auxiliary thumbnails or additional attachment metadata. And it makes the entire attachment process easily hooked. I don't see why our methods can't be integrated.

I'd like someone other than myself to test my code and give me a 2nd opinion on it's general implementation. Then maybe we can propose an integrated solution?

I like this idea, btw. When I submitted my patch, I wanted to make the thumbnail creation filterable, but didn't see a good/clean method of doing it. Your patch does it quite nicely though. More hooks. :-)

Any objections to integrating the two patches? Your thumbnail filtering code is easily integrated into my wp_attach_upload method. It basically replaces the same code it replaced in inline-uploading.php. I'll submit a new Trac ticket with integrated patch if all sounds good. Something like "attachment hooks & bug fixes".

In the meetup Wednesday, skeltoac said he will work up an inline uploading overhaul. You may want to see what he has in mind.

I'd like to see:

1. A nicer way of storing the path in the DB, as you have provided, for better portability.
2. MIME type based thumbnail hooks such as the above.
3. The inline uploading source as a regular old WP admin page. It could show up in the menu (for uploading things that aren't attached to a particular post) or not. Regardless of that decision, it's status as an admin page would make it super easy to add new tabs (submenu items). Easy tab addition = cool flickr plugin.
4. A clearer indication of how the picture will be displayed in the post (link to img/page/nothing, thumbnail/full). The method shuttle has proposed is far more intuitive to me than the current 'click on the image and get confused about what the popup means'.
5. As much separation of JS and HTML as possible.

Well, if that is the case, then I submit my Upload Manager plugin (written on top of my patch) for another example of how it /could/ be done. It simply replaces the iframe and provides an "Uploads" options menu. As of right now, I only use it internally for my clients. I can't submit the code (as it depends upon another plugin), but if it's of interest, I can do some rework to make it standalone. And it's not at all l10n'd.

I've attached a ZIP that contains a few screenshots.

Its features include:

* Ability to sort by Date and Name (ASC & DESC) * Filtering by 4 options: Images, Files, Music, Video (does mime-type matching) * Paging * Switches the Preview based on toggled options in a manner that is visible [not hidden by popup] (see Toggle More Options screenshot - shows Gallery thumbnail instead of regular thumbnail) * Creates an additional "center-square" cropped thumbnail (Gallery) (this is configurable to crop the top, center, bottom, or simply resize to a smaller setting) * Automatically resizes the original image based on an option (saves my clients from uploading huge photos (as in resolution-big) direct from their digital cameras) * Filters uploads into subdirectories based on mime-type (images, files, music, video) * Options page that allows you to change the visible options (you can tell it to, by default, link to the page using the thumbnail, and then only give the end user an option to change alignment - this feature is wholly designed for my non-savvy clients - better to make the decision for them than confuse with too many options) * Intense separation of JS and HTML (basically, the loops output 2 JS arrays for each attachment: metadata and options, and then when clicking "Insert File", there is a JS function that evals the chosen options to create the appropriate HTML) - it was designed to easily alter/hook the "insert HTML" methods because sometimes I use Markdown syntax instead of HTML. * Unfortunately, the downside is that I never coded a noscript method, but it's entirely within reason to add this ability.

Recently (and here's where it depends on other plugins), I've switched it to using a "tag" method that is filtered by the_content (in the form of <cms:upload name="Moose" id="3" link="page" show="thumb" align="center"/>) - but I wouldn't submit that as a core feature. (This allows me to alter the HTML output on the fly without having to find/replace through all my posts whenever something changes. Plus, it looks a lot less confusing for my clients who don't understand all that HTML.)

I'm also working on an Admin level page for managing them outside the iframe (but that's still in development). I would love to see the iframe source as a regular old WP admin page with the ability to add new tabs. (I'm also developing an "Easy Insertions" plugin to aid my clients inserting things like links to other pages, contact forms, mailing list signup forms, etc. - would like to do it as an additional iframe tab.)

I figured most of these features are left for plugin territory, but I have no problems with giving back to the core. Obviously I'd like to see the core change in such a way that doesn't cause me to have to redevelop the whole thing (which has happened before). If either you or Andy want to discuss this in detail - drop me a line: ryan at concept64 dot com. I'd be glad to help.

Screenshots of Upload Manager plugin

Here are the features again with correct Wiki formatting:

• Ability to sort by Date and Name (ASC & DESC)
• Filtering by 4 options: Images, Files, Music, Video (does mime-type matching)
• Paging
• Switches the Preview based on toggled options in a manner that is visible [not hidden by popup] (see Toggle More Options screenshot - shows Gallery thumbnail instead of regular thumbnail)
• Creates an additional "center-square" cropped thumbnail (Gallery) (this is configurable to crop the top, center, bottom, or simply resize to a smaller setting)
• Automatically resizes the original image based on an option (saves my clients from uploading huge photos (as in resolution-big) direct from their digital cameras)
• Filters uploads into subdirectories based on mime-type (images, files, music, video)
• Options page that allows you to change the visible options (you can tell it to, by default, link to the page using the thumbnail, and then only give the end user an option to change alignment - this feature is wholly designed for my non-savvy clients - better to make the decision for them than confuse with too many options)
• Intense separation of JS and HTML (basically, the loops output 2 JS arrays for each attachment: metadata and options, and then when clicking "Insert File", there is a JS function that evals the chosen options to create the appropriate HTML) - it was designed to easily alter/hook the "insert HTML" methods because sometimes I use Markdown syntax instead of HTML.
• Unfortunately, the downside is that I never coded a noscript method, but it's entirely within reason to add this ability.

[4751] addresses a piece of this.

Reviving for 2.3 consideration.

I suspect the patch is no longer applicable - it's seen no real action for some time and no evidence that anyone is motivated enough to try the patch with the latest trunk code. Resolving as WONTFIX. Please reopen if you wish to test the code.