Wordpress 2.6 features that Drupal should have
Submitted by Robert Douglass on Wed, 06/25/2008 - 08:53.
The Wordpress 2.6 Beta 1 is now available. Hats off to the Wordpress team. Here are some features that we should have in Drupal, too:
- A new and improved image editing dialog that offers lots of control over the images in your posts: This is interesting and worth checking out. Whoever makes it easy to post images and integrate them into posts will attract massive numbers of users. Drupal lags here.
- Better SSL support for the Admin: It should be easy for the (non-technical) admin to have either all of a Drupal site or just the admin and login portions go over https.
- The ability to move wp-config.php out of your web root: This would be settings.php for Drupal and (optionally) moving it out of the webroot is probably a “Good Thing”
- Drag-and-drop sortable galleries: We should be able to do this, too. It would require ordering node listings within a taxonomy vocabulary. There is a module for this: http://drupal.org/project/nodeorder
The rest of the stuff on the features list is either already in Drupal (caching, Check box range selection with shift-click), or is uninteresting (to me) (Built-in word counting in the post editor).
.thumbnail.JPG "Brixen/Bressanone 2005")
A good start would be getting ANY image handling in core!
IMO it doesn’t make much sense to start talking about Drag-n-Drop galleries in core when even basic image handling isn’t there. Hasn’t there been an almost CONSTANT stream of blah-blah-blah about getting image handling in core for the last X number of years? Why is this STILL not a priority?
Image In Core
Part of the issue is that there’s a billion different ways to handle images. Some people want an image gallery and image module handles that just fine. Some people want more flexability in their creation of images and use imagefield with CCK. People who want to sell things might want an imagefield or three attached, but no image gallery. Others still will want to associate their flickr account with Drupal.
Because there is no one way to do things, there is no image module in core, instead you get to pick which one(s) you want.
Maybe now that CCK (lite) is in core, imagefield will become the most popular method and as such, will ship in the next core of Drupal. But keep in mind, it isn’t even out for D6 yet. The fact that CCK (lite) just started shipping with core was why it hasn’t in the past. It just wasn’t possible.
Maybe you could pitch in and help?
Constant paradigm
It is one of the few things that appears to be a bit failure by design in the drupal community:
Doing the esoteric, forgetting about the obvious. Hopefully you prove me wrong.
esoteric sometimes means new obvious
Some of the things that would have been considered esoteric in their time (taxonomy) seem obvious now.
But yeah, images in core would be a good one
my 2c
Actually, it is a priority – or at least part of it is…
There’s http://drupal.org/node/142995 that has seen a lot of debate (and a bit of work as well). Hopefully, that will make it into core soon, then we’ll have a much better standpoint for developing a better image system.
The current problem is that neither of the two most popular approaches we have today is good in all cases.
Images-as-nodes (image.module) has lots of overhead to it – and images-attached-to-nodes (imagefield.module) makes it perilous and infeasible to share the images amongst nodes.
So, there is hope.
Post image editing dialog
Can anyone grab more description / screenshots of this “new and improved image editing dialog that offers lots of control over the images in your posts”?
I happen to be making a module to let users select location (the four corners, anyway) and more especially imagecache preset size for CCK imagefield uploads directly from the post.
Ideas for user interface implementation or feature enhancements of that plan would be appreciated.
(The second or third generation of this module would use Panels, but it probably needs the underlying engine of Panels 3, not the current Panels 2, to be done reasonably.)
Thoughts appreciated!
benjamin, Agaric Design Collective
Screenshots (4)
Here are some screenshots from my installation…
Immediately after uploading an image:
http://img205.imageshack.us/img205/4721/wpimageeditkl3.png
After uploading a number of images and viewing the Gallery tab (notice the drag & drop):
http://img395.imageshack.us/img395/5127/wpgalleryeditqi7.png
Viewing the final post:
http://img205.imageshack.us/img205/8840/wppostviewxc7.png
After clicking on one of the thumbnails:
http://img395.imageshack.us/img395/8704/wpgalleryviewgh8.png
How since Wordpress been out?
Wordpress 2.5 introduced most of these features in April yet it takes us 2 months to get it posted on the planet. I think we should put way more effort into looking at competitors, most of them have specific interface elements that are very nicely thought trough by great designers, yet we don’t pay attention to them.
I agree with Eigentor, we focus way to much on doing the esoteric, forgetting about the obvious.
I played around with WP’s
I played around with WP’s new image handling to see how it compares to Drupal’s current offerings with contrib modules.
WP simply has an icon in the TinyMCE editor that launches an inline popup with the ability to upload an image or insert a URL. It doesn’t reprocess the images to generate different sizes, but instead just changes the HTML dimensions.
I wouldn’t call the image management intuitive, it was confusing to create a gallery and you don’t seem to be able to add already-uploaded images into a gallery (which is tied to a post). The way the gallery is presented to the end user is adequate, however it’s not too pretty due to the scaling.
For the moment Drupal works well enough with TinyMCE and IMCE for adding images to posts, and there are millions of ways to set up galleries.
image field addons...
Imagefieldcrop and Imagefieldgallery both give estonishing image manipulation capabilities.
These together with Asset module will give a very nice coverage of the image upload process and gallery creation on the fly.
The challenge here is to detangle the upgrade of this stack to drupal6.
With cck not rock solid for drupal6 the dependent fields have stayed out of the game till now - now when we have modules that depend on these dependent modules we have to upgrade the whole lot of dependencies.
Even if the module maintainer is willing to do the upgrade (like yhager in imagefield_crop for instance) he still needs to wait for the underlaying modules to stabalize.
This is the double edged sword of drupal contrib - these modules SHOULD rely on each other but if the big chunks of functionality does not make it in to core we will still see this situation (in which there isn’t a decent support for images in drupal 6 months after it was released).
Asset Module?
For your first point I wonder if the asset module is a starting point conceptually. It is massively lacking in some areas but it accounts for managing files, inserting them inline, working with imagecache, and even access controls.
There would need to be a lot of work done but I wonder if this is a good starting point.
Drupal vs. WordPress
I’m starting to get pretty disgusted with Drupal. I have 4 Drupal sites, one of them going all the way back to 2004. I haven’t upgraded any of them to Drupal 6 yet because it breaks too many features. Every Drupal upgrade is a major trauma that breaks most of my modules & themes.
With WordPress, on the other hand, even a major version upgrade is painless. I was able to upgrade my blog from 2.3 to 2.5 in less than 10 minutes and it didn’t break any of my plugins or themes.
Also, WordPress’ post editing screen is so much more attractive and so much less cluttered than Drupal’s form. With Drupal, you have a half dozen collapsable sections (depending on the options & installed modules) for specifying post options, attaching files, input format, etc.
That’s just the inevitable
That’s just the inevitable side-effect of major improvements to Drupal between versions, as well as the Drupal developer’s decision to keep Drupal as lean and mean as possible by not weighing it down with layers of backwards compatibility with all of its past versions. Some upgrades cause more serious upheaval to the way modules and themes work, with the result of them being much more efficient, powerful, and easier to use/develop than in previous versions (e.g. adding the FormAPI, etc). The delay between many modules for Drupal 5 and Drupal 6 is (by my understanding) more due to the redevelopment of CCK and Views module which have become integral parts of so many modules now, and not as much due to changes in Drupal core. That particular delay (according to Earl Miles, developer of Views) won’t be happening in future Drupal upgrades, as this is to be the version of Views done solidly enough not to require such an overhaul in the future.
If Wordpress major upgrades were as progressive as Drupal upgrades (regarding the underlying APIs and developer-centric functionality) then it would break modules and themes just as much as Drupal. In the mean time unless you really require the new features of Drupal 6 on your current Drupal sites, there’s not much reason for you to be in a hurry to upgrade to 6 on those sites - Drupal 5 is very mature and well-supported. True some people dislike how rapidly new versions of Drupal arrive on our doorstep, but I think everyone pretty much agrees about being progressive and abandoning archaic backwards compatibility that would weigh Drupal down.
Regarding simplifying Drupal’s post editing screen, have a look at this module, which offers 2 alternative displays that make the editing screen more space efficient and usable (the side tabs option is similar to the new Views 2 UI): http://drupal.org/project/nodeform
Drupal node edit forms could still use various other improvements (e.g. I’d like more control in Drupal to selectively choose what to show end users of various roles exactly what options to display on a given content type), but it’s a great step forward in my opinion, and I hope something like this makes it into D7 core.
Good luck with your sites, and hope you keep using Drupal :D
not in core
I don’t think image should be in core, as drupal is not about blogging like wordpress, it’s about building all sort of websites, so flexibility, and some might just not want to have images :)
But it should definitelly be a module.. and I agree, there is not a lot of module out here that are really good solutions..
I actually spend a lot of time trying to find solutions on how to make image handling easier in drupal, and am working right now on a futur image gallery module.
Here is the project higlights : http://www.scribd.com/doc/3110492/Ajaximggallery
I blogged about it here : http://raincitystudios.com/blogs-and-pods/hubert/outline-ui-design-ajax-...
There is a discussion going on about his on IRC every monday morning, find infos about he discussions here : http://groups.drupal.org/node/11750#comment-40001
We need help !
Interesting perspective
Conversely, if you could pick 4 things from Drupal that should be in WordPress, what would they be?
Wordpress Theme Generator
I found Wordpress Theme Generator, another very interesting project done for Wordpress which can be source of inspiration for Drupal:
This online generator creates your own custom unique WordPress Theme. Without any need for HTML, JS, PHP, or CSS knowledge.
http://www.yvoschaap.com/wpthemegen/
OK it’s more easier to do new themes in Drupal 6, but there is some place for big improvment as Wordpress Theme Generator show us : example real time adjustment and automatic generation of .info, .css and page.tpl.php files
There is a starting project done with Adobe Aire. Unfortunatly it’s rather basic : you are only able to generate .info files, which is the simpliest part among all the files needed for a Drupal 6 theme. But it’s a good starting point.
http://xtnd.us/drupal/themestarter
Great post - image handing
Great post - image handing in core would be a nice idea but a lot of the functionality can be added with modules such as imagecache.
Post new comment