Category: plone

Scenario: I added a new attribute “orderPriority” to a few different archetypes based content types. These attributes had default values. As this is an existing site, there were 400 or so existing objects that had not picked up these default values – i.e. they would only pick up the value after they had been re-saved. To make sure these objects picked up the default value I created a skin script, which I proxied as manager (watch out for indentation here, really must find a better way to display preformatted code):-

catalog = context.portal_catalog

# objects are all in folder /directory/listing/

listing_folder = getattr(context.directory, 'listing')



for brain in catalog(portal_type = ['NameOfMyContentType']):

print brain.portal_type + ' ' + brain.id + ' ' + brain.Title



listing = getattr(listing_folder, brain.id)

#this gets the default vakue from the schema

order = listing.getOrderPriority()   #this sets it

listing.setOrderPriority(order)



return printed

I needed to be able to sort by this field in a catalog query/ Topic/SmartFolder/Collection so, so I then added the field as a fielindex in the portal catalog, reindexed the catalog (ZMI) and used the collection edit options in site setup to add it as a field

Something I always forget to do when I override the title attribute in an archetypes schema (plone) is to specify accessor=Title (with a capital T). Omitting this leads to odd results, such as the ID of the plone objects created from the schema not being created from the title field, but something else (hmm.. the parent object’s title maybe?).

(updated 10/6/2008 – to reflect Dan’s corrections below)
pdb has long been on my radar, but I had kind of dismissed it as something for “proper” programmers, rather than a web monkey like myself. However, i’m pleased to say i’ve actually finally used it during some plone development! The trick (for me) involves running the plone site in foreground mode so you can see messages in a terminal, and then with pdb you can interact with it. In your python script you need to add:-

import pdb
pdb.set_trace()

when the script reaches this set_trace() statement, you get a pdb prompt in the terminal allowing you to interact with the script and it’s variables at that point. e.g. print myvar to get the value of a variable or myvar.__class__ to find out what type of variable it is. You can also use ‘n’ to step through the script or ‘c’ to continue to the end.

Up until this point I relied on adding print statements in the scripts to try to work out what was happening – a bit like i’ve done for all my web dev over the years – a common mistake for me is to leave these in, then get confused clients asking why the word “here” and “foo=[1]” keeps appearing on their website!

You can also use a similar tool to debug zope skin scripts. This uses a similar principle – run your site in foreground mode, and you can interact with the skin script from the set_trace statement.

from Products.zdb import set_trace
set_trace()

If you are anything like me, you might be nervous about installing the recent plone hotfix in case you either break something or are under the impression it involves some unix command line foo. Don’t worry, it is much simpler than that – the hotfix comes in the form of a product – download it, unzip it (well actually untar/ gunzip it) ,and drop it in your products directory and restart zope. Of course you will need access to your products directory, and the ability to restart zope to do this. If you haven’t then it is probably safe to assume that it isn’t your responsibility, so go and nudge whoever it is that deals with that stuff for you 😉

Hot on the heels of the Bristol Drupal Users group I set up recently, comes the Wessex Plone Users group, aimed at Plone users in the Bristol, Bath and surrounding area.

Even though I seem to have slipped off planet plone recently (design or accident? – must find out!), i’m fascinated by the current debate about Through The Web (TTW) support in Plone. I must admit I have noticed a general “TTW is bad” vibe from hardcore Plone developers – in fact i’ve heard it said outright on many occasions. As a Plone integrator/ general web developer I can see the pros and cons of TTW, but i’ve certainly seen it as a selling point of Plone – people commissioning a CMS, even for a large corporate site or intranet often get excited at the possibilities of being able to make customisations and additions themselves without having to get expensive developers in to make changes – and why shouldn’t they? I’ve also been a position where i’ve taken on a few customisations of Plone sites where the most of the site lives in the custom skin layer, edited TTW and it is a great way to make minor amends on the fly, and something that i’ve always liked about plone, even though I am fluent with file system development.