[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
...etc
> 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. :)
-e
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