[wp-hackers] GSoC Proposal: Integrate WP-cache / WP Super Cache into WordPress

Eric Marden wp at xentek.net
Fri Feb 29 04:46:10 GMT 2008

I'm all for the idea of including a caching solution into the Core,  
but I don't think that we should utilize a plugin, that has another  
plugin as a dependency. I'm not discounting their work -- I use one  
or the other of those plugins on all of my WP sites.

But there is an opportunity here to create a WP wide caching  
mechanism that could be utilized throughout the code to speed it up.  
The 3 step cache that WP-Super Cache does is fantastic, but its not  
complete nor is it an example of the very best caching solution ever  
-- again this doesn't detract from its usefulness or how great it  
performs, and is just my opinion.

Additional things I'd like to see in a 'core' caching solution:

Additional Cache back-ends (apc, memcached, etc)
More granular control over what gets cached (header & sidebar are,  
but posts on page aren't, etc)
Ability to use the cache api in my plugins

 > How often are you going to edit a past post from 1 week, 1 month,  
3 months, 6 months
 > or one year ago? Probably never.

I do it all the time. In fact, I highly recommend going back and  
reading your old posts... it will make you a better writer, and let  
you fix obvious mistakes you totally missed before, but you'll also  
get an interesting look at yourself from an angle you may have never  
seen before. :)


On Feb 28, 2008, at 10:20 PM, Jacob Santos wrote:

> I was about to disagree, when I remembered the hell of a past  
> project that involved caching. I still think that the object  
> caching should always be enabled. However, any solution that is  
> accepted in to the Core will require test cases. I say this not to  
> discourage, because really, it isn't up to me to decide.
> I say that only because recently the current disk solution was  
> stripped out of the object cache and any solution adding it back in  
> will require support from not only the author of the solution, but  
> the whole of the WordPress community. If there are test cases, it  
> will improve the quality of said solution, and hopefully pinpoint  
> where issues might come up in the future.
> It is very interesting and as an user of WP Super Cache, I can say  
> that most projects I've used it, it didn't give me any problems.  
> (There was that one weird problem on GoDaddy that I was never able  
> to figure out and since the site is high priority, may never find  
> out). My host seems to accept WP Super Cache with very few problems  
> (I remember none, but I have a feeling there was once upon a time).
> I think the solution that WP Super Cache offers is a good one. It  
> answers the question: How often are you going to edit a past post  
> from 1 week, 1 month, 3 months, 6 months or one year ago? Probably  
> never. Also, in the best case, if the database ever did go down,  
> the solution should keep most of the cached pages up for visitors  
> to see. What I mean, is that in most cases (barring plugins, which  
> can use the hooks), you could just serve the static HTML pages  
> instead of making the trip to the database. Changing the theme  
> wouldn't require "rebuilding," because only the post portion would  
> be cached, also allowing for comments to be made and updated.
> WordPress 2.5 is increasing performance in some areas. Perhaps, the  
> root of the problem (another GSOC WordPress project) could be done  
> first or side by side of this project if a student accepts it.  
> There is only so much you can do for decreasing overhead and  
> optimization. At some point APC or friend will have to be used for  
> performance.
> I do like the idea of caching, so good luck!
> Ronald Heft wrote:
>> Agreed completely. Should this idea be accepted, I would investigate
>> potential web host issues. I also agree that caching should  
>> absolutely be
>> disabled by default, because no matter how slick the caching  
>> solution, there
>> are always disadvantages to using caching.
>> On Thu, Feb 28, 2008 at 9:55 PM, Matt <speedboxer at gmail.com> wrote:
>>> The problem is, said crappy hosts are also likely to have poor
>>> configerations that will cause even more problems. Sounds like a  
>>> good
>>> idea, though. However, it should be disabled by default.
>>> On Thu, Feb 28, 2008 at 6:52 PM, Ronald Heft  
>>> <ron at cavemonkey50.com> wrote:
>>>> Hello everyone. This is the first of at least few project  
>>>> proposals from
>>>> myself for the upcoming Google Summer of Code 2008. I will be  
>>>> bouncing
>>> ideas
>>>> off the WP-hackers list, so I'm looking for people's opinions of  
>>>> the
>>>> project. Also, if any particular project excites you, feel free to
>>> volunteer
>>>> as a mentor for the project.
>>>> * Abstract *
>>>> As WordPress accelerates in usage, more and more people are become
>>> exposed
>>>> to WordPress-generated database error messages on popular social
>>> websites
>>>> such as Digg.com. These error messages are by no means the fault of
>>>> WordPress, just crappy shared hosting services. However, people are
>>> seeing
>>>> WordPress as the perpetrator of these database crashes.
>>>> Many of these crashes can be avoided by using a caching plugin  
>>>> such as
>>>> WP-cache or WP Super Cache. Unfortunately, not everyone is aware of
>>> caching
>>>> solutions, or only find about about them when it's too late. My  
>>>> proposal
>>> is
>>>> to integrate a caching solution directly into WordPress, making  
>>>> regular
>>>> WordPress users more aware of caching, while making it more  
>>>> convenient
>>> to
>>>> use.
>>>> * Solution *
>>>> - Talk to existing developers of WP-cache and WP Super Cache  
>>>> about there
>>>> willingness to have their plugins included directly in core.
>>>> - Investigate disadvantages to caching. Does caching require  
>>>> increased
>>>> server requirements compared to a base WordPress install? Does  
>>>> caching
>>> pose
>>>> any security threats?
>>>> - Look over existing caching plugin code and improve upon where  
>>>> needed.
>>>> Ensure adding caching requires no extra steps other than a CHMOD of
>>>> wp-content.
>>>> - Improve existing caching plugin interface, making it easy to
>>> understand,
>>>> and as user friendly as possible.
>>>> - Look over feature requests for caching plugins. Evaluate what  
>>>> features
>>>> would be beneficial to include. See:
>>>> http://wordpress.org/tags/wp-super-cache
>>>> - Provide standardized plugin API, so plugins can disable  
>>>> sections of
>>>> caching, eliminating plugin-related caching issues.
>>>> - Investigate other areas of performance increases, optimizing  
>>>> WordPress
>>>> queries and load times where applicable.
>>>> --
>>>> Ronald Heft, Jr.
>>>> Information Sciences and Technology
>>>> Pennsylvania State University
>>>> cavemonkey50.com
>>>> 9rules Network
>>>> _______________________________________________
>>>> wp-hackers mailing list
>>>> wp-hackers at lists.automattic.com
>>>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>> --
>>> Matt (speedboxer at gmail.com)
>>> http://mattsblog.ca/
>>> _______________________________________________
>>> wp-hackers mailing list
>>> wp-hackers at lists.automattic.com
>>> http://lists.automattic.com/mailman/listinfo/wp-hackers
> -- 
> Jacob Santos
> http://www.santosj.name - blog
> http://funcdoc.wordpress.com - WordPress Documentation Blog/Guide  
> Licensed under GPLv2
> Also known as darkdragon and santosj on WP trac.
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers

More information about the wp-hackers mailing list