plonewars.com

It’s all a big party — several high-profile sites have revealed that they run Plone over the past week, and now we can add Akamai to that list.

Alexander Limi: Akamai runs Plone

Originally from Planet Plone by limi

Google Calendar

Originally from del.icio.us/tag/plone by easement

Copying sites has recently gotten a lot better since 2.5.2 fixed some bugs with modification times getting reset but still you generally can’t use copy &amp; paste to copy sites as I have found it doesn’t retain the review state of your documents (and this is by design actually I think).<br /><br />Another approach is to import/export. This actually works great so I put together a script that will automate this process.<br /><br />You need to call this from either an External Method or from zopectl debug (or ipython). That’s an exercise up to the reader…<br /><br /># moveSites.py<br /><pre># Move a Plone site without losing the modification times and workflow status<br /># we rely on export/import to do this<br /># You need to provide a valid REQUEST so that the import doesn’t fail<br /># if running from zopectl debug you can use makerequest to wrap your app object<br /># with a fake request<br /># Author: Jordan Baker (jbbNOASPM@scryent.com)<br />import tempfile<br />import os<br /><br />def moveSite(portal, new_location):<br /># export the site to a tempfile<br />f = tempfile.NamedTemporaryFile()<br />portal._p_jar.exportFile(portal._p_oid, f)<br /># re-import in the correct location<br />f.seek(0)<br />new_location._importObjectFromFile(f, verify=False, set_owner=False)<br /># delete the old site<br />oid = portal.id<br />portal.aq_parent.manage_delObjects(ids=[oid])<br /># update the catalog in the new site<br />new_location[oid].portal_catalog.refreshCatalog(clear=True)<br /># NamedTemporaryFile should delete the underlying temporary file<br /># when its object is garbage collected<br /></pre>

Jordan Baker: copying a plone site

Originally from Planet Plone by hexsprite

How annoying is it to deploy an application? How prone to errors due to the sheer repetitiveness of the common deployment? Buildouts to the rescue!<br /><br />What is a buildout? It’s a automated set of steps for creating a deployment environment. This could mean one little application, or it could be several and they would setup to talk to each other.<br /><br /><a href=”http://cheeseshop.python.org/pypi/zc.buildout”>zc.buildout</a> came out sometime last year and I’ve had my eye on it since then. I’d wanted to do Jim Fulton’s tutorial on it at Pycon this year but wasn’t able to schedule it in!<br /><br />I’ve had the opportunity in the last couple weeks to start using a bit more and I really appreciate the conceptual basis for this framework.<br /><br />The idea that a deployment consists of parts is something you can explain to anyone, for example.<br /><br />A web app needs a webserver, some kind of storage backend, the application code and some preexisting data:<br /><br /><span style=”font-family:courier new;”> parts=apache mysql application-data application</span><br /><br />or full Zope-based solution:<br /><br /><span style=”font-family:courier new;”> parts=apache zope zeo plone mywebsite mywebsite-data</span><br /><br />What I’ve noticed so far is that for a particular application even though someone might have already wrote a recipe for it actually getting it configured the way you want usually requires extending that recipe slightly.<br /><br />If the recipe was written with this in mind its easy enough to extend. I did have a bit of problems extending some of the plone.recipe.* recipes because they were old style classes and so I couldn’t use super() to extend the default behaviour. Easy to fix though!<br /><br /><h2>ZOPE / ZEO buildout recipe with multiple database support</h2><br /><br />I created a branch that adds the ability to configure multiple databases in your configuration files which I needed for a project, so this should be a fairly decent example for anyone else needed to something similar.<br /><br />See the <a href=”http://dev.plone.org/collective/browser/buildout/plone.recipe.zope2zeoserver/branches/jbb666-storage-config”>jbb666-multiple-dbs branch for zeo instance</a> and the corresponding branch for the zope recipe.<br /><br />For a lot of the Zope recipes the config knobs that need to be exposed will be determined and you won’t need to touch the underlying recipe except in well exceptional circumstances.

Jordan Baker: Buildouts

Originally from Planet Plone by hexsprite

The book <span style=”font-style: italic;”>Web Component Development with Zope 3, 2nd Ed.</span> by <span style=”font-style: italic;”>Philipp von Weitershausen</span> has been on my wishlist for a while now and I finally got around to ordering it.<br /><br />I only got it last night and already I’ve made it half way through, though certainly I will re-read it all several times.<br /><br />The book offers very excellent descriptions of the component architecture and its applications throughout the rest of the Zope 3 framework.<br /><br />The progression of chapters in the book shows the reuse of the basic building blocks of interfaces, adapters & utilities.<br /><br />And one of the things I also liked was the “Rocky says” section where the relevant technologies of J2EE were constrasted with those of Zope.<br /><br />The explanation of ZCML in the book finally made it clear to me. ZCML is on purpose <br /><br />It forces a separation of roles and make sure that things that would be considered ‘configuration’ are easily accessible to a non-programmer like a system administrator or integrator.<br /><br />My impression so far the from the book is one that really showcases Zope 3 as a enterprise-grade framework that is solidly Pythonic.<br /><br />For more info you can check’ the website for <a href=”http://worldcookery.com/”>Web Component Development with Zope 3, 2nd Ed.</a>

Jordan Baker: Zope 3 Book Arrived!

Originally from Planet Plone by hexsprite

<p>Applying <a href=”http://code.google.com/soc/plone/about.html”>through the Plone Foundation</a>, I have been awarded funding by Google through their <i>Summer of Code </i>programme to improve the <a href=”http://plone.org/products/quills”>Quills</a> weblog solution for Plone.  This is just a brief post to say that I’ll be posting updates on my progress to this blog.</p>
<p>In the interests of eating my own dogfood this is, of course, a Quills blog.  More specifically, it is a fresh instance based on Quills 1.5RC3.  In the interests of continuing to eat my own dogfood, I hope that it won’t remain as such while I develop…<br /></p>

Tim Hicks: Summer of Quills Code Begins

Originally from Planet Plone by Tim Hicks

Thanks to Tres Seaver (who <a href=”http://svn.zope.org/Products.Five/branches/1.5/browser/metaconfigure.py?rev=77057&amp;view=rev”>applied my fix</a> to the various Zope and Five branches), the <a href=”http://quills.sitefusion.co.uk/blog/archive/2007/06/21/developments-and-barrier-to-merging-to-trunk”>barrier to merging</a> the maurits-traversal branch to trunk is now gone.<br /><br />Also, as <a href=”http://lists.etria.com/pipermail/quills-dev/2007-June/002530.html”>Jon Stahl pointed out</a> on the Quills-Dev mailing list, it would be a good thing if quills.remoteauthoring was made to work with standard Plone content types, not just the specific Quills Weblog type.<br /><br />I’ll be working on the merge-to-trunk and extending the application of quills.remoteauthoring soon.<br />

Tim Hicks: Ready for merge to trunk

Originally from Planet Plone by Tim Hicks

<p>My first step today was to fix the plonetrackback bug for deleting received trackback pings (<a href=”http://plone.org/products/quills/issues/90″>issue 90</a>).</p>
<p>After deleting a trackback ping, it gets uncataloged.  However, the way that the pings are stored in the catalog is rather convoluted and hackish.  As a result, the standard unindexObject call didn’t work as expected, and instead also uncataloged the actual WeblogEntry instance to which the ping was attached.  I <a href=”http://dev.plone.org/collective/changeset/42906″>resolved this</a> with a change to uncatalog_object(trackback.getPath()).<br /></p>

Tim Hicks: plonetrackback bug fixed

Originally from Planet Plone by Tim Hicks

<p>For the past couple of days, I’ve been working on updating my main development branch (<a href=”http://dev.plone.org/collective/browser/Quills/branches/maurits-traversal/”>maurits-traversal</a>) to be compatible with Plone 3.  This means being compatible with Zope 2.10, which in turn means that I have had to change the traversal mechanism applied to URLs like “[weblog]/topics/…” over to use the new IPublishTraverse interface and design.  As IPublishTraverse is not available in Zope 2.9.x, this amounts to a new hard dependency for Quills (1.6+) on Zope 2.10 – which presumably means a hard dependency on Plone 3+.</p>
<p>A few notes on the new IPublishTraverse mechanism are in order.</p>
<p>First, it took quite a long time to swap things over, although this was largely because it took me a while to figure out what I was supposed to do.  Maybe there are docs, but I coudn’t really find them.</p>
<p>Second, the IPublishTraverse is, for my purposes, not as nice as what went before.  My goal was to be able to intercept all URL segments below “topics” in “[weblog]/topics/Football/Tennis/Zope”, and thus get the kind of traverse_subpath behaviour that “Script (Python)” objects have.  In the old setup, your traversal adapter was passed “furtherPath” as a parameter, and this would look like “['Football', 'Tennis', 'Zope']“.  Easy enough to intercept the rest of the path, then.  In the new setup, the IPublishTraverse.publishTraverse method only gets the individual URL segments one at a time.  To get around this, you have to grab hold of “request['TraversalRequestNameStack']” directly – and that feels a little bit wrong.  It appears I’m <a href=”http://www.nabble.com/Specialized-URL-traversal..-Best-way–t824862.html”>not the only one</a> who thinks this.</p>
<p>Ho hum, traversal (at least) seems largely to be working now.<br /></p>

Tim Hicks: IPublishTraverse and a Plone 3 dependency

Originally from Planet Plone by Tim Hicks

<h3>Weblog</h3>
<p>First, following the pattern used by plone4artistscalendar, provide a
TTW/TTP facility to mark individual content objects – like “Folders”
and “Smart Folders” – with an interface that causes the default view
for the object to switch to a weblog-ish view based on the “IWeblog”
interface. Further, such a marker interface could/should cause extra
options to become available for the purpose of providing more
weblog-specific configuration options. I propose to store this
configuration data in “IAnnotations”.<br /></p>
<p>Second, provide adapters for those types that are markable as a Weblog
to an IWeblog interface. The major part of the implementation would be
fetching those (sub)objects that should form part of the weblog. Each
of those (sub)objects would, in turn, be adapted to an “IWeblogEntry”
interface. Thus, the use of arbitrary (and standard) Plone content
types as weblog entries would be made possible simply by providing
adapters for each to the “IWeblogEntry” interface. The implementation
would provide such adapters for the “Page”, “Image”, “Link”, “Event”,
“News Item”, and “File” standard Plone content types.</p>
<p>Third, provide a traversal adapter that allows such a repurposed
container-ish content object to use archive-by-date URLs of the form
“[containerish]/2006/05/06/[weblog-entry-id]“. This is a standard
weblog feature. As an intermediate step, the implementation would also
require the provision of a non-persistent WeblogArchive class.
Instances of this class would be injected into the traversal path by
the Smart<br />
Folder traversal adapter, and would then allow for archive listing
views to be used on URLs of the form “[containerish]/2006/05/”. I have
worked on a partially complete branch of Quills implementing this
traversal feature already exists on the <a href=”http://dev.plone.org/collective/browser/Quills/branches/maurits-traversal”>maurits-traversal branch</a>.
It has issues at the moment, but provides a good base to build from.<br /></p>
<h3>
Trackback</h3>
<p>
Completion of the <a href=”http://dev.plone.org/collective/browser/plonetrackback/”>plonetrackback</a> product that allows for trackback
pings to be sent to and from arbitrary Plone content objects. The core
implementation is largely complete, with just unit tests and more
complete integration with the CMF/Plone catalog required. However, the
major impediment to the usage of trackback is ping spam. In order to
make the product truly usable, some kind of moderation queue system is
a necessity. (This is true to a large extent for commenting in plone,
IMHO.) Optional integration with the Akismet service would be desirable
- and very possible given the two python <a href=”http://akismet.com/”>Akismet</a> wrappers and the
<a href=”http://myzope.kedai.com.my/blogs/kedai/61″>Akizmet Zope product</a> – but is probably reliant on implementation of
moderation to be effective. Simplistic moderation for trackbacks should
be fairly trivial to implement, but I wonder if there is a more generic
approach that could/should be taken. The existing workflow machinery is
an obvious candidate for reuse here, but the current plonetrackback
implementation probably doesn’t play nicely with that. I’d be grateful
for guidance from a mentor in this area.<br /></p>
<h3>
Update Pings</h3>
<p>Provide a component-enabled tool/utility that allows for update pings
to be sent to services such as Technorati. This would be equivalent to
the functionality offered by <a href=”http://projects.quintagroup.com/products/browser/qPingTool/”>qPingTool</a>, but implemented in a way that
is agnostic to the object types that update pings should be made for
(by using adaptation). With the introduction of workflow transition
events in CMF 2.1, I propose to listen for “publish” transitions and
send pings as appropriate. This will require some TTW/TTP configuration
for the object types and locations to listen for.<br /></p>
<h3>
Remote Blogging</h3>
<p>Provide remote authoring functionality with Zope3 views. The current
Quills implementation of “MetaWeblogAPI” works as a persistent
attribute on weblog objects, which makes it more complicated than it
should be to disable the feature. Migration code is also potentially
more complicated, and a hard dependency on the “RPCAuth” product (to
provide authentication) is introduced to the Quills product. The latter
relies on something of a hack to achieve its goal. None of this is
desirable, and none of it is necessary. Non-persistent views that
authenticate via a custom PAS plugin offer a way around all of this,
with the added bonus of considerably enhancing the potential for reuse
by other products.</p>
<br />p.s.  On the issue of motivation for getting Plone blogging software up to date, see Jon Stahl on <a href=”http://theploneblog.org/blog/archive/2005/12/29/marketing-mindshare-and-blogging”>how blogs can capture users for plone</a>.<br />

Tim Hicks: My SoC Proposal in Full

Originally from Planet Plone by Tim Hicks