Personally I think the best option at this point is WordPress’s built-in resizer. It has its limitations, but it also has a lot of advantages (security, no extra configuration, no need to keep up with the latest version since it’s part of the core). I’m going to save myself the headache of using third party resize scripts in the future

sevenspark said
Personally I think the best option at this point is WordPress’s built-in resizer. It has its limitations, but it also has a lot of advantages (security, no extra configuration, no need to keep up with the latest version since it’s part of the core). I’m going to save myself the headache of using third party resize scripts in the future

Thank you for such valuable opinion sevenspark! But do you mean image_resize() function? or vt_resize (as it uses wp’s built-in resizer)? Just want to know if anobody has any issues with the built-in function.

The only differeance in results I can see that TimThumb can output the image in bigger size if you want, but wp’s built-in function (and vt_resize) uses the max height/width only. But what about server requests for example?

Timthumb and similar solutions serve images using php which is just a useless waste of servers resources. WP standard behaviour is to resize once and serve the static image directly via the webserver (apache/nginx/whatever)

Timthumb and similar solutions serve images using php which is just a useless waste of servers resources. WP standard behaviour is to resize once and serve the static image directly via the webserver (apache/nginx/whatever)

exactly. Few weeks ago i developed WP site for one company, they didnt want to spend much money so instead of creating theme from scratch i told them to buy some template here and ill just customize it for them. Template was using thimthumb and after 2 days of working, they got email from hosting company that they were using to much server resources and their site got suspended…Even tho they had like 3000 visits. After i checked logs, i saw that timthumb script was using 70% of resources… so i just replaced it with WP image_resize and now images are made once you upload it and served as static.

So if u plan on doing site with much or some traffic, i say go with image_resize.

sevenspark said
Personally I think the best option at this point is WordPress’s built-in resizer. It has its limitations, but it also has a lot of advantages (security, no extra configuration, no need to keep up with the latest version since it’s part of the core). I’m going to save myself the headache of using third party resize scripts in the future

Thank you for such valuable opinion sevenspark! But do you mean image_resize() function? or vt_resize (as it uses wp’s built-in resizer)? Just want to know if anobody has any issues with the built-in function.

The only differeance in results I can see that TimThumb can output the image in bigger size if you want, but wp’s built-in function (and vt_resize) uses the max height/width only. But what about server requests for example?

Sorry for not being more clear. I’m suggesting using the standard WordPress solution as bitfade described. Basically, the process of defining image sizes using add_image_size and then grabbing the appropriate image size using WordPress’s core functions, like get_the_post_thumbnail.

The downsides are several, but outweighed by the positives in my opinion:

1. You can’t scale the image larger than its original size. (I think if you have to, just let the browser do it).

2. Every image will have a copy in every size, whether it needs it or not (if your size choices are well thought out, I don’t think it’s much of a problem – and server space is less expensive than server processing power).

3. If you add or alter an image size in the future, you’ll need to regenerate those thumbnails with a plugin (a little annoying, hopefully they’ll be add some core functionality to do this in the future).

The positives:

1. You’re using core functionality. That simplifies things.

2. Like bitfade said, you’re processing once and serving static files from the server; that’s more efficient in the long run (and easier on your server).

5. Functionality is automatically upgraded with Core releases (if you use a third party script, you have to upgrade when they upgrade – dependencies can be bad). Also, you can expect the functionality to continue to work with future releases, whereas third-party scripts may lose compatibility and may or may not continue to be supported.

6. Coding this way would make your theme more compatible with plugins that affect image thumbnails (potentially).

Having worked with WordPress for a while now, my opinion is that diverging from the standard WordPress functionality with third party replacements often creates more problems than it’s worth. Generally, working within the system creates fewer headaches for everyone.

A nice solution would be to use mod_rewrite: serve if images exists, generate it if not.
downside is, adding rewrite rules can sometime be tricky if buyer already has some of them

another one is to use a custom 404 wordpress page to do the same thing, it doesn’t require mod_rewrite but it returns a 404 header when generating the image.
though, almost all browsers would display it anyway.

Post Reply

<strong></strong> to make things bold
<em></em> to emphasize
<ul><li> or <ol><li> to make lists
<h3> or <h4> to make headings
<pre></pre> for code blocks
<code></code> for a few words of code
<a></a> for links
<img> to paste in an image (it'll need to be hosted somewhere else though)
<blockquote></blockquote> to quote somebody