WordPress Developer News: WordPress 2.9 Beta 2
WordPress 2.9 is currently in beta and is expected to be ready in several weeks.
Major new features for developers:
- comments meta table
- improved support for custom post types
- register_theme_directory() for additional theme locations
- back-ported JSON encode/decode for both PHP and JavaScript
and for users:
- oEmbed support
- “Trash” for posts, pages and comments
- post thumbnails support
- basic image editor
More details are available in the Codex http://codex.wordpress.org/Version_2.9 and on trac.
New feature in the plugin repository: logged in users can enter compatibility information about all plugins – works / doesn’t work for several recent versions of WordPress. It is still in beta and in data collection mode. When it’s released, the collected information will be available from the wordpress.org API.
As with every release there are hundreds of improvements and bug fixes. 410 tickets have been closed so far for the 2.9 milestone.
One significant change is the new “trash” status for posts and comments. It works by changing the post_status or the comment_approved field to ‘trash’. If the post or the comment is restored from the trash that field is set back to it’s previous value. By default items in the trash are deleted after 30 days.
If you use direct SQL queries you may need to exclude posts and comments that are currently in the trash. Simple example: http://core.trac.wordpress.org/changeset/12254
Please ensure that your plugin(s) or theme(s) work as expected in WordPress 2.9-beta-2. If you have questions or comments please post them on the wp-hackers mailing list or in the Alpha/Beta forum on wordpress.org.
Alex (Viper007Bond) 5:02 am on September 26, 2009 Permalink |
You could also just use a shortcode for the image tag, although that may not be as user friendly. Then again, if you move domains, URLs, etc. you wouldn’t have to edit the post.
So instead of this:
[code lang="html" light="true"]<img src="http://blog.com/wp-content/uploads/imagename-thumbnail.jpg" width="150" height="100" title="Cool image" alt="ohai" />[/code]
You’d do this:
[code lang="text" light="true"][image id="123" size="thumbnail" title="Cool image" alt="ohai"][/code]
The URL, width, and height would all be dynamic and change if you changed the thumbnail size, etc. This is opposite of now where even if the filename didn’t contain the dimensions, you’re still left with hard coded width/height parameters in the image tag.
scribu 11:49 am on September 26, 2009 Permalink |
That would be nice. And it’s been requested several times in the past.
Xavier 4:47 pm on September 26, 2009 Permalink |
How would that shortcode handle differences between
http://blog.com/wp-content/uploads/2009/02/imagename-thumbnail.jpg
…and…
http://blog.com/wp-content/uploads/2009/03/imagename-thumbnail.jpg
…?
Beau 9:30 pm on September 26, 2009 Permalink
Since both uploads would have a unique id in the DB, it doesn’t matter if they have the same filename. The correct URL would be output dynamically, based on wherever it was stored (as referenced by the DB)
Andrew Ozz 12:57 am on September 28, 2009 Permalink |
Think this came up when we were doing the captions shortcodes a year ago and was rejected. Perhaps we can look at the pro & con again. Since all movies and other embeds will be handled by shortcodes it may make sense to extend that to include images too.
However I see a possible problem with that. The img tag doesn’t need any processing on display but a shortcode would need quite a lot as it seems we will have to do get_post() for the attachment. Also our shortcode parsing code/API doesn’t seem optimized enough to handle large quantity of shortcodes.
aarondcampbell 8:20 pm on October 3, 2009 Permalink
It is true that it can’t handle really large posts with lots of shortcodes. However, that’s definitely only affecting a very small percentage of people (if we’re really focusing on the 80-20 principle, it’s less than 20%). Do we really think that enough people will be writing stuff this long (and putting enough shortcodes in it) that we should worry about it? (That’s the post where I first ran into the issue…I tried to explain that it was just too long, but apparently it’s quite effective as it is).
I like the shortcode idea.
Andrew Ozz 2:31 am on October 5, 2009 Permalink
True, this is very rare at the moment but turning img tags into shortcodes would increase that number, perhaps a lot.
No, don’t think we can apply the 80/20 principle here. Would that mean we can break up to 20% of all published posts?
The problem is that even a shorter post with a lot of images will reach the backtrack limit or be very slow to display.
DD32 2:58 am on October 5, 2009 Permalink
> or be very slow to display.
Reminds me of the mention of storing filtered post contents along side the raw and serving those up instead of applying the expensive filters every load..
Andrew Ozz 3:19 am on October 5, 2009 Permalink
Yes, post_content_filtered is still in the posts table. Think there are few plugins that do this, not sure how well though as it bypasses all ‘post_content’ filters.
Alex (Viper007Bond) 3:38 am on October 5, 2009 Permalink
Perhaps storing a partially cached version would be best, i.e. just internal shortcodes. You’d break a lot of plugins if you rendered the entire content from a cached copy.
Jonathan Dingman 9:22 pm on October 1, 2009 Permalink |
Would that imply dynamic resizing?
ie, if someone changed the thumbnail size after already uploading the image, would it resize on the fly? (if specifying a thumbnail in the shortcode)
Denis de Bernardy 11:14 pm on October 3, 2009 Permalink |
Using a shortcode here would hammer the DB unless it’s properly implemented.
And this “it hammers the database”, btw, is the reason I had opened:
http://core.trac.wordpress.org/ticket/10882
I use similar code in two plugins of mine, and since you can’t rely on an attachment from being tied to a single post, I check for a post meta to make sure there are attachments (and which ones) before tossing a query.
Alex (Viper007Bond) 6:56 am on October 4, 2009 Permalink |
We also have to not forget about those who use TinyMCE and expect to see the image as is. A shortcode would be there as text.
Perhaps a TinyMCE plugin could AJAX fetch the image (based on ID) and replace the shortcode with the image during editing, then put it back to the shortcode on save. That way it’d still stay a WYSIWYG.
aarondcampbell 9:53 pm on October 4, 2009 Permalink
That’s a good point. It’s easy to forget about those using WYSIWYG
Barış Ünver 6:33 am on September 26, 2009 Permalink |
I’m concerned about the fact that WordPress is getting fatter and fatter each version. Is it really necessary? Couldn’t it be done with a plugin or something?
Or at least, are we gonna be able to se a lighter (official) version of WordPress? LitePress v2.9.0 maybe?
Alex (Viper007Bond) 9:14 pm on September 30, 2009 Permalink |
Filesize (aka fat) is not directly related to performance. The image editor for example has literally zero (no joke on the literally) impact on the front page of your site for example as it’s never loaded except in the admin area.
Andrew Ozz 12:15 am on October 1, 2009 Permalink
On top of that even in the admin it’s only loaded through AJAX so it doesn’t add any overhead anywhere.
aarondcampbell 8:22 pm on October 3, 2009 Permalink |
It’s all about the 80-20 rule. I think more than 80% of the people will use this on a regular basis. I probably won’t, but most of my clients will. I’m all for keeping code as lean as possible, but I’m also all for adding this support in. Let’s trim in other areas. Just my 2 cents.
Andrew Ozz 1:37 am on September 28, 2009 Permalink |
Another solution for the multiple image backup files would be to let the user decide. We can include a checkbox whether to delete the previously edited image (together with all sub-sizes). Since the suffix that is appended to the image filename contains a timestamp, we could do something like “This image was last edited 1 hour ago. If it wasn’t used in a Post since then you can remove the backup files by selecting this checkbox”.
On the other hand even the cheapest hosting accounts seem to come with a lot of storage so deleting backups would be unnecessary. Also a plugin can add a simple GUI to search the db and return a list of unused backup images that can be deleted. Not sure if something like this would be good for core.
Otto 6:07 pm on September 28, 2009 Permalink |
I think the key to this problem is the following: “This is necessary to avoid breaking any posts or pages where the image was inserted.”
Why avoid breaking those posts/pages? If somebody edits an image, then change the image itself. That’s what they will probably expect to happen.
Having to have them go and reinsert the changed image into the page/post is confusing and unnecessary. We don’t need to save the original. The user uploaded the image, presumably they have the original. An in-place editor should simply overwrite the existing files with the new ones, not try to preserve them.
Andrew Ozz 12:30 am on October 1, 2009 Permalink |
True, users that know what they’re doing may expect to break old posts when editing an image. However the majority will most likely complain that “the image editor breaks all old posts!”.
Also we cannot just replace the originally used image with the edited one as images are inserted with “width” and “height” attribs that in most cases will distort the edited image (as Viper007Bond pointed above).