In this thread I’d like to gather possible features for the petition for an improved media library in CP.
As base, these are my ideas for the neglected love child:
a more complete media library API
directory / file list instead of just the regular view (including different upload options, eg. optionally adding a subdirectory and putting files in there)
improved sorting options
add categories and tags (which are a rather simple thing to implement, as files are essentially a post type called ‘attachment’)
auto-reindex / regenerate thumbnails, maybe even selectively regenerate thumbnails (or any other image size)
I’m going to implement the improved media library as an experimental plugin, where I try to add each feature separately (including a settings section to optionally disable / enable specific features, and maybe also configure them further).
Update:
Suggestions of plugins, issues and articles for implementing wanted features (from the petition comments):
hell, that would be so awesome. Its always SUCH A STRIFE and such a horrific, cruel PITA to teach each and any client, self-proclaimed “designer” etc. pp. to NOT use insanse-sized images in their posts … lets figure this one out
Please coordinate with @fwolf if you’re interested in contributing.
As far as the plugin code, I’d recommend keeping separate improvements organized in separate classes / files and adding settings to enable/disable each one. This will make it easier to sort through if some of the improvements become things we’d like to add to ClassicPress core directly.
yep, thats along the lines I thought it should be done, too. I gonna tinker up a quick “register parts” micro-API for that purpose, plus generic helper class (which includes things like is_assoc etc.), a base “plugin.php” + readme file and then push it into the repo, so that we’ve got something to work with
On a side note: Using namespaces for the separate parts would be great, but I don’t know if this would hinder less PHP-savvy people to contribute … also whether this is going to work nicely with current WP code if this is going to added at some point (hopefully), I really dont know. Thus I guess its better to use the classic PHP 5.x approach without namespaces (for now).
I’d love to see OOP and namespacing used in all new code, personally. There are a couple of fantastic tutorials (probably more) from Steve Grunwell that can get people up to speed with writing OOP and using namespaces. He wrote them for WordPress, but (especially right now) they are exactly the same for ClassicPress. See WordPress Plugin Design Patterns and PHP Namespaces for WordPress.
My feeling on building a feature plugin is to build it as though it was absolutely going into core. Then, if it does, there’s no extra work involved bridging gaps, writing new tests, etc.
So … we could use namespaces, because CP is dropping support for PHP < 5.6.
AFAIK there is already code using namespaces inside WP - I think I’ve seen it just recently, either while digging through the update API, or the HTTP API.
Gonna look it up and use that as example
Update: Nope. There is nothing … must have mistaken it with some more complex plugin I was handling during work (like, all the time!)
Thus I’m still writing a simple handler for “registering” (and loading) the features (mostly to let them be enabled and disabled via option), but this one is already sitting in its own namespace.
May I ask a dumb question?
This list of options for a plugin or core are impressive and would make the media library really great, but if that is possible now for CP why it never happened for WP?
Because it was never a priority for WordPress would be the biggest reason. They could have used some time to change this neglected part, but instead they figured that fixing a non-broken editor (or rather destroying it) was more important.
Next to exactly right. Most or even ALL requests for improvement of the last 5 - 6 years were neglected, moved to a different release and then forgotten (or purposefully ignored). The only “big” think that ever happened was the UI, eg. putting Thickbox into core and keeping it up-to-date (because the original ThickBox stopped working after jQuery 1.2.1)
I’m going to implement the improved media library as an experimental plugin, where I try to add each feature separately (including a settings section to optionally disable / enable specific features, and maybe also configure them further).
do you mean that this will be a temporary plugin for testing waters on how all those options might be implemented in CP’s core future versions?
Yes, but “experimental”, so it may be just parts of it. More important: Its a real-life implementation, to see what works and what not - not just theoretical discussions
Most certainly. This is why I wrote in the petition: “A more complete API” - including such things.
Including better documentation (probably, at the start, “just” proper and thorough PHPDoc - aka its WP-focused equivalent).
If we move to using Namespaces, I would recommend that we:
Do so very sparingly, and we debate each namespace with the first assumption that we do not need it,
Follow a very prescriptive code standard for using namespaces,
Implement a custom classmap-based autoloader so we don’t end up for 3, 5 10 or 25 autoloaders running every time a new class needs to be loaded (PSR-4 really does not work for a WordPress-based site when dealing with plugins, me-plugins and themes.)
Cons when using namespaces:
PHP namespaces are not the most intuitive things to use given the rules the PHP team choose to implement. That can make code with a lot of namespaces hard to work with for the typical WordPress developer. IMO we should not stray too far from our roots or we’ll lose people who otherwise would have been interested in CP. CP is an improved WordPress, not the 2nd coming of Symphony. I have seen this story before and it does not end well.
With meta programming the PHP team’s regrettable choice of namespace separator can make for some very hard-to-reason-about code with class names in a string where namespace separators need to be escaped, and with the multiple levels of hierarchy instead of just one global symbol.
Code with lots of namespaces interspersed in the code make for some very long lines that are harder to reason about than code that is not interspersed with backslashes and namespaces everywhere. I propose if we are going to use namespaces that we set the coding standard that all namespaces need to be declared at the top of the file with an optional alias so the rest of the file. The following is an example of the top ~25 lines of code I am using for a client that illustrates this:
<?php
/**
* Filename: feature-archived-posts.php
* Description: Add 'archive' status for post type
* Author: Mike Schinkel
*/
namespace RPLib;
//
// THIS IS WHAT I AM PROPOSING:
// ALL NAMESPACES USED WOULD BE
// LISTED HERE AT THE TOP OF
// THE FILE.
//
use RPLib\Traits;
use WP_Query;
use RPLib;
use RPLib\Old_Url_Redirects as Redirects;
/**
* Class RPLib\Archived_Posts
*/
class Archived_Posts implements Feature_Module {
use Traits\Feature_Module;
const POST_STATUS = 'archived';
I also suggest we seriously look into using Traits paired with Name-only Interfaces, too. But that is another topic…
I like this idea. My plugins’ autoloader method (which can also be used by their extensions) is ~50 lines of code duplicated across (though not within) plugins.
re: Cons
See #3…
It can be maddening in cases, but observing these pros/cons, we can avoid most of this.
Agree. This keeps lines much shorter and easier to learn/use.
Agreeing with most of that. Specifically the usage of namespaces - that would be similar to the declaration of header files in C, thus a pretty solid standard.
And yeah, whatever idiot came up with the “grand” idea to use backslashes in the namespace implementation, hopefully is now in Windoze hell FOREVER