So far I haven’t done much more than register a Twitter account (@greenwichtweets) and domain name (greenwichtweets.co.uk) and browse some of the API documentation. Updates on progress will be available on the Greenwich Tweets site (which at the moment is just redirecting to a page on this site!). I’m hoping to start work in earnest around July.

At the moment I’m looking at Python and Zope (possibly Plone) to manage the back-end stuff, although I’m hoping to keep it all reasonably lightweight.

The number of steps I’ve had to go through to get this working seems to get larger every time I do it. I’ve now got to stage where I’m not 100% sure if a step is needed or not, but what the hell I’m going to do it anyway. To be honest, I’d probably recite incantations backwards over a boiling cauldron if I thought that was going to help.

Here’s a summary of what I’ve had to do:

• Export the content from the old Zope 2.6.4 site
• Create a new CMF site on a Zope 2.9.7 instance
• Run through a load of Zope upgrade routines,  including fixing the catalog and adding a load of new folder actions
• Export the folder(s) containing the content you want to migrate
• Create a new Plone site somewhere on a trashable Zope 2.9.7 instance
• Set this up with a theme / policy product
• Import the converted Zope/CMF folders
• Clear and rebuild the Plone site’s portal catalog
• Go to portal_atct / Type migration and click on “Fix” under “Fix portal names”
• Click on “Migrate” under “Type migration”
• This should fix all old CMF documents, links and files
• Now, I’ve got the fix the old CMF Folders. Oh, this is a good one. The only way to get these into the catalog is to go to portal_catalog and go to “Find Objects”. I leave the search fields blank to get absolutely everything into the catalog, even stuff that doesn’t really belong there
• I create a migration script that handles the transfer of old “Portal Folders” to Plone Folders (not at the ATFolders stage yet). It also does some other minor migrations I need to do (e.g. converting ATDocuments to a custom content type)
• Here’s another great one: now make sure your folders don’t contain any objects with the IDs of “language” or “subject”. This causes the migration to fail (I found this out by trial and mainly error). There may be some more IDs that cause this problem, I don’t know.  Rename any verboten IDs.
• Go back to portal_catalog and do a Clear and Rebuild
• Go back to portal_atct and re-rerun Migrate Types. My Plone Folders now become ATFolders (woohoo!). Oh hang on, they don’t have any titles!
• I write a script that gives the folders the same titles as their index_html documents. Luckily, by and large the titles of folders and their index pages are the same, so this usually works.

That’s it. Simple and pain-free it’s not. But it is a good advert for not leaving it so long between upgrading your Zope/Plone versions, or being a better programmer.

The lovely folks at SWFObject helped to identify why this was happening — nothing to do with SWFObject at all but the fact that Flash Player 10 implements some new security “features”. I managed to isolate it to the fact that Plone serves up ATFiles with the header, “Content-Disposition: attachment”. Flash Player 10 ignores files served up with this header, so you need to override this and set it to “Content-Disposition: inline;”.

I came up with this solution which may not be overly elegant but at least it works. I created a skin-level Python script that sets response headers before returning the file:

showflash.py

request = container.REQUEST
RESPONSE =  request.RESPONSE
flashvid = request['flashvid']
cd = 'inline; filename=%s' %(context.id)
RESPONSE.setHeader('Content-Disposition', cd)
return context[flashvid]

Then, when I embed the video with SWFObject I call it thus,

<script type="text/javascript">
   swfobject.embedSWF("&dtml-portal_url;/path/to/flash/showflash?flashvid=myflash.swf", "my-dom-id", "435", "290", "9.0.115");
</script>

This may be better handled by a product like Plone4Artists Video but it certainly works as a fix for us.

It’s quite easy to set a property in the request object using request.set(’key’, ‘value’) in your Python script. However, if you then redirect to another page this property is lost. What you need to do is something along these lines:


request = container.REQUEST
RESPONSE = request.RESPONSE
request.set("my_new_key", "my_new_value")
response = context.id_of_page_to_call(request)
return response


You can then use this new request object property in the page you “redirect” to. The URL won’t change, i.e. if the script you’re doing all this in is called something like “myscript”, “myscript” will remain in the URL after the new page “id_of_page_to_call” has been called.

So, plonetheme.simplicity has now been checked into the Collective SVN repository and, barring a couple of fixes which I’ll hopefully make this weekend, is almost ready for testing. I’ve installed a example of it on my Plone 3.0.3 site at littlewebcreations.co.uk. This highlights one of the problems I’m currently experiencing: the calendar expands outside its container box as in Plone 3.0.3 (and presumably some other earlier versions), the days of the week render as three characters as opposed to two in Plone 3.0.6 (the version which I developed the site in). At the moment I’m not sure if there’s a configuration setting I can make to change this, or whether I’ll need to customise the calendar portlet or use a bit of Javascript to sort the problem out.

Installing my theme product into a different Plone instance threw me for a while. I managed to install it using “setup.py install” from the appropriate Python path but couldn’t see it listed in my available products within the ZMI. I then realised I had to create a plontheme.simplicity-configure.zcml in my Zope instance’s etc/package-includes directory. Or, I could have copied the one that was generated for me in the root directory of my theme. Of course I could have read the generated install.txt file which explained all, but that would have been too easy.

As with the first one in Bristol in May 2007, it was very useful. We had a number of presentations on various themes covering all aspects of Plone development and roll-out (customisation, performance, testing and end-user training). It was also great just to chat to other Plone developers and compare notes; not to mention reassuring that others were experiencing the same kind of issues as us.

I’ll put a summary of my presentation up on this blog, but we’re hoping the integrate the presentations and other notes into the Plone4Universities site (we had the logo designer for this site as one of our delegates) which seems like the natural home for this kind of thing.

The problem: basically, you need to replace some text or code using a regular expression in Python, but you need that regular expression to contain a variable reference so it can be run within a loop etc. How do you do this?

The example below is the actual one I was working on — I needed to replace a <div> tag with a changing id with the actual contents of a file within Zope, in order to insert HTML snippets (YouTube video, Google code etc.) into a page. The page editing tool we use (EditonPro) sensibly strips out this kind of stuff, but this was a special case where the site editor really needed to do this. The inserted tags looked something like this:

 <div id="snippet-123456">
   [snippet: YouTube video of something]
 </div>

Then I defined a method (getSnippet.py) with the following code:

import re

def getSnippet(self, content):

   content = content.replace('\n','')
   pattern = re.compile(r"""(<div id="snippet

-)([^"]*)(">[^<]*)(</div>)""", re.MULTILINE)

   reg = re.findall(pattern, content)

   if reg:

      count = len(reg)

      i=0

      while i < count:

         snpid = str(reg[i][1])

         sr =  r"""<div id="snippet-%s"[^<]*</div>"""

         src = re.compile(sr % snpid)

         srch = src.findall(content)

         srch = srch[0]

         try:

           repl = self.aq_parent[snpid].data

         except:

           repl = ''

      content = content.replace(srch, repl)

      i=i+1

   return content

Briefly, this is how this works: in the document_view page template a call is made to getSnippet thus:

<div tal:define="content here/CookedBody"
     tal:replace="structure python: here.getSnippet(content)"/>

The page content is passed to the getSnippet External Method which first does a regex to find all the relevant bits of code. If anything is returned in the variable “reg”, a while loop is initiated.

The div ids, which map to file names of the Zope files, are extracted from “reg” while this loop runs. We use them to construct a regular expression which will match the relevant snippet code. The key lines are these:

sr =  r"""<div id="snippet-%s"[^<]*</div>"""

src = re.compile(sr % snpid)

We use the %s syntax when defining our regular expression and pass the variable to it when compiling it.

It works, great stuff.

RewriteEngine On
RewriteBase /

RewriteRule ^/plone($|/.*)
http://myplonesite:9080/VirtualHostBase/http/www.littled.net:80/VirtualHostRoot/_vh_plone$1
[L,P]

So littled.net/plone would lead you straight into the Plone site. When I finally got the .htaccess file syntax correct which took a few passes (like getting the RewriteBase set properly) it kind of worked, except my hosting company don’t have mod_proxy installed (I guess for security reasons which is reasonable).  When the flags were taken out, the redirect did work, rewriting the URLs on the Plone page, but leaving the hideous Virtual Host Monster URL in the browser location bar. So, what I learned is this:

Even if you are using Rewrite rules and not using mod_proxy directly, you still need mod_proxy enabled for it to work properly.

Never mind, my Plone site is now going to be separate site from this with its own URL.