will you create a pro wordpress?

it’s your hosting, uyon. I moved from godaddy to bluehost and the speed came back. the hosting company has to supply decent servers for the SQL databases.

Yeah, I went from so-so VPS to a pretty good VPS; and the difference is profound. I would recommend shopping around.

but all these features make wordpress slower.

Unused features do not slow down WordPress. If you don’t use widgets, then they are never executed.

Otto, unused features still require conditional code to decide if they are being used or not. While the loss is low, extra code is always executed to check to see if these things are used.

kevcombs: The idea of “throw more hosting at it” is the answer only if the product didn’t work before either. For many people, the move from 2.3.x to 2.5.x was a performance downgrade, especially in the admin panel. If you have to add more hosting just to keep performance the same as it was before, then there is an issue, no?

The move from 2.3.x to 2.5.x has barely even changed load times for me. Most often its server performance which is causing slow downs for people etc etc.

Just interested, who are you hosted with oyun?

Otto, unused features still require conditional code to decide if they are being used or not. While the loss is low, extra code is always executed to check to see if these things are used.

What? No, they don’t. Sorry, but that’s simply not how PHP (or WordPress) works.

Otto, example: If you have widget code in the system, when your theme checks for widgets, you add this:

if ( !function_exists('dynamic_sidebar')
        || !dynamic_sidebar(_g('Left column')) ) : ?>

Now, last time I checked, that is extra code that exists and is executed on every page view because of widgets, otherwise you would just run the code.

On the admin panel, pretty much the same thing. It counts the number of widgets in your current theme. There is code to do that, it doesn’t just magically appear.

30 odd years of coding… you can’t snow the snowman.

I would say there is overhead but personally I think it is insignificant at least for me.

Otto, example: If you have widget code in the system, when your theme checks for widgets, you add this:

Your theme is not part of WordPress, because it is your theme. And if you don’t use widgets, and don’t want it checking for widgets, then remove that code from it. No overhead at all.

When I say “unused features”, I mean just that. If you’re checking for widgets, then widgets are a *used* feature. Code that is not called adds no overhead except in the reading of the file from the disk.

I am reposting this comment I made over on the “Ideas” forum:
(Note that a few things may have changed in 2.5.x, but the general speed issue with wpautop still exists. Just give this a whirl and see if it speeds things up for you. It did for me.)

“One quick way to speed it up a good bit is to comment out the ENTIRE innards of the function “wpautop” in /wp-includes/formatting.php. It contains about 20 regular expression (regex) matching/replacing calls, each on potentially the entire post content for e.g. each post on the blog index page.

Regex is resource intensive, and this can be 200 such calls for someone that has e.g. 10 posts showing.

[Also note that since wpautop is called for every comment_text, on the single.php “single-post view” screens it will slow things down as well if you have a good number of comments.]

Here is the line in default-filters.php that does this call:

add_filter(‘the_content’, ‘wpautop’);

1) It’s really not necessary to do what amounts to a syntax check EVERY TIME the post gets displayed. If anything, call it on update… if you must…

2) In general, I have found 0 adverse effects from cutting out this entire function that is rummaging through and trying to correct your HTML (and there are a few unintended errors in there where some of the “greedy operators” run amuck and replace valid div tags with p tags, stripping put valid embeds on etc. when using the post editors, which is what first alerted me to this function).

Everything seems to work faster and better…

If people use the editor, they can’t really screw up the HTML compliance too badly anyway, if they use hand-coded inserts, etc. just let them be… if they screw things up, that’s their problem… and they’ll likely know right away anyway…

(end of reprint)

Long story short:
Comment out ALL of “wpautop” function in /wp-includes/formatting.php except the “return $pee;” line

See how it’s running on one of my blogs, response time is usually good even though it’s pretty graphics heavy on first load. Running on Bluehost.com

https://businessmindhacks.com/