PressFlow related documentation, updates, support?

markus_petrux's picture

I was not sure where to post this question. Appologies if this is not the correct place.

I've been looking at PressFlow and it looks nice that it already comes packaged with several performance related patches. Thanks to those who made it available.

However, compared to latest Drupal snapshot, it seems to be missing latest Drupal core patches. If this happens with minor fixes it's ok, but it seems it could also happen with security related issues?

I'm considering the use of PressFlow for a high traffic site I'm porting to Drupal, but... I'm wondering how often is PressFlow being updated and how PressFlow users get notifications of such updates.

Also, is there any public resource where to ask for support for PressFlow related issues, bugs, or documentation about the patches included in PressFlow so that developers and site administrators can take them further should they need to for their particular use-case?

Would it be possible to release the performance related patches in PressFlow separately? That way we could simply get Drupal when a new version comes, and then apply the PressFlow patches.

Login to post comments

In addition...

tseven - Wed, 2009-08-26 23:54

What is the current "version" of PressFlow?
Does it contain the latest 6.13 security fixes?
How quickly is PressFlow updated after a security release/patch is made public?


In all honesty...

Swampcritter's picture
Swampcritter - Thu, 2009-08-27 18:29

PressFlow is a performance-based modified derivative of the Drupal CMS platform. You should really look at contacting someone at Four Kitchens on these questions.

At Morris Communications, we are currently using the PressFlow 6 platform for a number of sites we are migrating to it, but we are also making a number of changes to the platform as well for working better with load balancing, integrating the memcache/authcache modules and and unique squid/squirm patterns.

Just so you know, you cannot take a D6 patch and apply it to a PressFlow 6 build. It won't work.

-- Michael


Thanks, I already contacted Four Kitchens

markus_petrux's picture
markus_petrux - Thu, 2009-08-27 19:32

I figured I would have to ask these questions using their contact form, but it was after a while of posting this here.


As for maintenance, 4

moshe weitzman's picture
moshe weitzman - Fri, 2009-08-28 01:36

As for maintenance, 4 kitchens has already committed to immediately backporting all drupal.org security patches. economist.com and others have required this level of service before adopting pressflow. as a developer on economist.com, i can tell you that pressflow now has a track record of fulfilling this promise. i would not worry about this.

The pressflow patches are not itemized on the web AFAIK but you can discern them by diffing the code. Note their bzr repository is public. See http://fourkitchens.com/blog/2009/01/17/distributed-version-control-prov...

It would be nice to have a forum for pressflow users. Until we have that, I think this High Performance group is a pretty good proxy.

Pressflow takes great pains to remain API and schema compatible with core. There is little reason to avoid using it IMO.


Moshe, Thank you for your

tseven - Sat, 2009-08-29 03:48

Moshe,
Thank you for your reply. This is exactly what I wanted to hear.

I'm happy to hear the code is being maintained to such a high standard.


Sure, Thanks for the input

markus_petrux's picture
markus_petrux - Sat, 2009-08-29 09:34

In fact, my interest in PF was more from an open source POV than a commercial interest.

About a couple of years ago we launched a site based on Drupal 5 that I had to tweak for performance and to support reverse proxy caching for anonymous users, as well as certain pages for authenticated users. I wrote about it here at g.d.o.

Since then, I participated in several Drupal core issues related to reverse proxy caching, in one way or another (see #147310 Implement better cache headers for reverse proxies). And my focus here was mostly related to Drupal 6. Why? Because we're working to port the main site (which is currently using a proprietary CMS) to Drupal 6 (too early for D7) with additional SN features for our user base. Problem seems to be that it is perhaps to late to apply certain patches to Drupal 6, even if these patches "take great pains to remain API and schema compatible with core", so now that we're at the latest stages of the project, I'm starting to research a way to use a Drupal 6 installation that works well with reverse proxies (Squid in our case). The site gets about 2 million pageviews a day, more or less, and we expect to raise our current numbers with the new site, so these things are pretty important for us.

I have 2 options: work out my own patch to Drupal 6 based on the work done on the Drupal issues queue, or... guess what, this has already been done here for PF, which is great. However, since PF is not a community initiative, I had some doubts about using PF directly or just as a source of stuff that has, more or less, being cooked in the Drupal issues queue.

The problem I see in PF, from my POV, is that it seems to be managed from a commercial approach, which is perfectly reasonable. But I have the feeling it will potentially benefit less people because the features it includes are not openly managed as if it was a community initiative.

I'm wondering if the page caching stuff in PF could be committed to Drupal 6 branch. Maybe it was possible if these enhancements are really "API and schema compatible with core". But I'm afraid Drupal core maintainers are busy with other things right now. Anyway, it would be nice if this approach was analyzed, I think.

If it was possible, then it would also be easy to share additional enhancements other could potentially add, for example to manage page caching for certain pages of the site for authenticated users, or to share the tricks to do so with the currently distributed page caching patch.

[EDIT] Following a link to Drupal.org Now With Caching I've found this issue in the Infra queue (#466444 Reverse Proxy Patch) where the page caching and lazy session patches are being used at d.o. I posted there about the idea to manage these patches using community shared resources, so it's easy for others to benefit from them, as well as to keep contributing back based on experience, fact that could be easily shared, I think. And this could potentially benefit D7 as well. The more of us who use this for D6, the more chances to return value to the community, and that means D7 and beyond.