Staging and production will both do SSI if you tell them to via a top-level .htaccess file. Trafficserver does this right now with the CMS.
----- Original Message ----- > From: Dave Fisher <[email protected]> > To: Joe Schaefer <[email protected]> > Cc: Daniel Shahaf <[email protected]>; "[email protected]" > <[email protected]>; "[email protected]" > <[email protected]> > Sent: Thursday, January 5, 2012 1:37 AM > Subject: Re: suggested CMS workflows for ooo-site > > > On Jan 4, 2012, at 9:57 PM, Joe Schaefer wrote: > >> ----- Original Message ----- >> >>> From: Dave Fisher <[email protected]> >>> To: Daniel Shahaf <[email protected]> >>> Cc: Joe Schaefer <[email protected]>; > "[email protected]" <[email protected]>; > "[email protected]" <[email protected]> >>> Sent: Thursday, January 5, 2012 12:45 AM >>> Subject: Re: suggested CMS workflows for ooo-site >>> >>> >>> On Jan 4, 2012, at 5:00 PM, Daniel Shahaf wrote: >>> >>>> Joe Schaefer wrote on Wed, Jan 04, 2012 at 16:55:02 -0800: >>>>> ----- Original Message ----- >>>>> >>>>>> From: Daniel Shahaf <[email protected]> >>>>>> To: Joe Schaefer <[email protected]> >>>>>> Cc: "[email protected]" >>> <[email protected]>; [email protected] >>>>>> Sent: Wednesday, January 4, 2012 6:57 PM >>>>>> Subject: Re: suggested CMS workflows for ooo-site >>>>>> >>>>>> Joe Schaefer wrote on Wed, Jan 04, 2012 at 09:52:39 -0800: >>>>>>> ----- Original Message ----- >>>>>>> >>>>>>>> From: Dave Fisher <[email protected]> >>>>>>>> To: [email protected] >>>>>>>> Cc: >>>>>>>> Sent: Wednesday, January 4, 2012 12:40 PM >>>>>>>> Subject: Re: suggested CMS workflows for ooo-site >>>>>>>> >>>>>>>> >>>>>>>> On Jan 4, 2012, at 9:29 AM, Joe Schaefer wrote: >>>>>>>> >>>>>>>>> Also Dave get in the habit of checking > buildbot for >>> the >>>>>>>>> build status of sledgehammer commits instead > of >>> waiting >>>>>>>>> for svnmailer to figure out what to do with > the >>> massive >>>>>>>>> diff it's trying to make sense of. The > url is >>>>>>>>> >>>>>>>>> >>>>>>>>> > http://ci.apache.org/builders/ooo-site-site-staging >>>>>>>> >>>>>>>> I do do that, but tend to wait for the email > anyway. If >>> there is no >>>>>> reason to >>>>>>>> wait that will save time. >>>>>>> >>>>>>> Buildbot performs the commit back as the final step in > the >>> build, >>>>>>> so if buildbot thinks the build has completed > successfully, you >>>>>>> do not need to wait for svnmailer to send out a notice > to that >>> effect. >>>>>>> >>>>>>> My experience is that the turnaround between > sledgehammer >>> commits >>>>>>> and eventual publication is about 1 hour: ~20 min for > each step >>>>>>> along the way, all because of svn committing or merging >>>>>> >>>>>> Instead of: >>>>>> >>>>>> % cd production-wc >>>>>> % svn merge $URL/to/staging >>>>>> >>>>>> can you: >>>>>> >>>>>> % svnmucc -mm rm $URL/to/production cp $somerev > $URL/to/staging >>>>>> $URL/to/production >>>>> >>>>> Not too fond of that approach as we'd lose the history of > the >>> production tree >>>>> in the process. Not every change to staging winds up being > promoted. >>>>> >>>> >>>> No we won't. Just run 'svn log -qv' on the parent of > the >>> production tree. >>>> >>>>> There is an alternative approach that I am reluctant to mention > but >>> might >>>>> be the best solution for everyone: to use SSI as part of your >>> templating system. >>>>> The downside is that it adds a bit of conceptual complexity to > the CMS >>>>> as well as to people doing local builds as they will now need > an >>> SSI-enabled >>>>> server to inspect their build results. >>>>> >>>>> The upside is that sledgehammer commits would be a thing of the > past as >>>>> the Django templates would rarely need to be altered directly. > >>> You'd just >>>>> be altering individual files in content/ containing >>> (markdown-converted) >>>>> html fragments that the server would dynamically include into > every >>> page >>>>> based on the SSI calls in the Django templates. >>> >>> I can see your vision. Each file in templates and content get converted > into >>> content in the staging and production repos either assembled via SSI or > as >>> static "sledgehammer" content. >> >> All I'm saying is that by adding a bit more indirection (ala a C-style > pointer) >> we can get better mileage out of the CMS for everyone. So in templates/, > you >> no longer put any extensive html/markdown prose directly in there, just > point >> at it with an SSI include directive with a url path in say content/ssi/... >> The prose goes in content/ssi, which can be included directly into the file >> by httpd which will scan your template-generated content for those include >> directives. >> >> Changes to lib/* and templates/* will always have widespread effects on the > generated >> content and there's no way around that. But we can stabilize those > files a lot >> more quickly, and reduce the need for such changes, if we can get the > ever-changing >> header and footer and nav *content* back into content/ssi/* and out of > templates/*. >> >> Do you see more clearly how I'm thinking now? > > I think so. Essentially we would move out most mdtext and html content from > templates leaving skeleton.html more of a list of includes. It would totally > be > possible to pull almost all the changeable content out of templates and lib. > > How would you mix using SSI vs. static content on the staging and production > servers? Or does production also do SSI? > > Regards, > Dave >
