[wp-hackers] GSoC Proposal: Integrate WP-cache / WP Super Cache
into WordPress
Jacob Santos
wordpress at santosj.name
Fri Feb 29 03:20:39 GMT 2008
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.
More information about the wp-hackers
mailing list