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

Ronald Heft ron at cavemonkey50.com
Fri Feb 29 06:17:03 GMT 2008


Thanks for the valuable feedback Eric. I agree, this would be an
excellent opportunity to start fresh with a new caching system. If anyone
has any examples of a PHP-based caching system in they feel is better than
WP Super Cache, I would love to see it.
Regarding things like APC and memcache, correct me if I'm wrong, but I do
not think the majority of web hosts would be able to support those
solutions. Very few people would benefit.

Regarding module caching and creating an API for plugins to easily do
caching, both of those thoughts crossed my mind. Should this idea take off
amongst the WordPress community, I will certainly look into those options.

Jacob, I'm right there with you on the complex factor. However, complex
tasks have to undertaken some time, and I feel this is a project that could
potentially benefit the WordPress community immensely. I admit, I don't know
everything right now I would need to complete the project, but that's part
of the Summer of Code. It's a learning experience for the student, and shows
the true power of the open-source community. If I get stuck, I have the
backing of my mentor, the WordPress community, and the open source community
at large. I'm not saying a student should undertake a project without
knowing a thing about it, but they certainly don't have to know everything.

On Thu, Feb 28, 2008 at 11:46 PM, Eric Marden <wp at xentek.net> wrote:

> 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
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>



-- 
Ronald Heft, Jr.
Information Sciences and Technology
Pennsylvania State University

cavemonkey50.com
9rules Network


More information about the wp-hackers mailing list