I'm just playing with KSS for the first time properly today - a quick note for myself and anyone else out there who may get bitten by this one. If you are in the habit of using console.log() in your jQuery (or MochiKit, or whatever). Somewhere in the internals of KSS console becomes a KSS object, and calls to console.log() cause Firefox to hang. Just a warning :) If I track down what's going on I'll follow up on this post...
There is a risk that this is going to sound like a bitch. It's not, I promise. Getting the release notes right when you are tracking tens or even hundreds of developers is nigh on impossible. That said, I need to get this off my chest...
One of my niggles with Plone over the 2 years that I've been using it has been that upgrades to apparently minor versions have sometimes had major and unexpected effects. Unexpected because the release notes simply haven't made it clear that particular changes have been included. The one that leaps immediately to mind was the change from 2.1.2 to 2.1.3. All sorts of things changed not only under the hood but also in the UI, making what appeared to be a fairly minor release suddenly a blocker on the project we were working on at the time.
Since then I've been very wary about changing versions of Plone mid project, even when the documented release notes show very few changes. The problem for me is that the release notes do not show every change. Even the relatively detailed release notes for the 2.1.3 release didn't include all of the changes that were made that directly impacted our project, and the notes for later releases contain even less (see, for example, the ones for 2.5.4).
We recently found a nasty bug in Plone 2.5.3, where users couldn't register if their desired username was contained within the username of another user. E.g. if a user with username freddy already existed the usernames fred and eddy would both cause the The login name you selected is already in use or is not valid. Please choose another message when a user tried to register with them. The bug appears to have existed throughout the Plone 2.5.x releases until 2.5.4, when it was identified and fixed.
This is major bug. Any Plone site at 2.5.3 or lower with a medium number of users is going to hit this problem. Here at Isotoma our first port of call is to start hunting down the bug, but most Plone deployments aren't done by people with such intimate knowledge of the code base. Most people's first port of call will be to see if this bug is fixed in later versions. In this case it was, but the release notes didn't mention it.
So. If I'm a Plone deployer (rather than developer) who's not comfortable with the source do I a) upgrade in the hope that my bug might be fixed in the latest version (and not knowing what else might have changed), do I b) stick with the version I've got and work around the problem, or do I c) think seriously about an alternative CMS that tells me when my bugs been fixed?
What I'd really like to see is a simple list of all tickets that have been closed and all the commit messages that have gone into a particular release. Trac (which the Plone team uses at dev.plone.org) has this ability to do this right now (here are the tickets for 2.5.4, for example) - all we need are the links on the release page so that those users that aren't developers and aren't comfortable with the tools we use have easy access to the information they need to assess if and when to upgrade.
Limi (the Plone project lead) recently posted 18 Things I wish were true about Plone. Number 1 is Simple development should be possible entirely through the web interface. This really talks to the pretty much constant discussion within the Plone community that the product can be hard to get started with and that it feels like you need to be a developer to use it.
I can't help but feel that incomplete release notes are a part of this problem. For the want of just a little extra Trac magic and the judicious placement of links this wouldn't be a problem.
As an aside... While writing this post I wondered how the Drupal team handle it. They do, indeed, do it differently. They provide detailed ticket based release notes for each release and easy links into their CVS for each main branch. I kind of wish they didn't, to be honest...
So. This has been just about the most frustrating search for a "bug" I've been involved in.
First, the reporter was miles away, and it was only her computer and other unspecified machines that exhibited the problem.
Second, I couldn't replicate the problem. It appeared to be related to a combination of IE7 and Norton 2006 Internet Security Suite. IE7 I've got - Norton 2006 I couldn't, despite being willing to pay for it, just so I could see this problem for myself.
Third, it was something infrastructural in Plone that wasn't working, yet I could find no reference to anyone else reporting the problem.
Fourth, she was signing off the project, and there was no way we were going live until it worked, even though it appeared to only affect a tiny proportion of users.
The problem as described to me was that the document action drop downs had "stopped working". Just stopped. Some time in November, apparently.
It's a long story, and I won't bore you with the hideous details of how I finally got to the answer, but for anyone else who's got the same problem (and surely someone else must have?) here's what you do to fix it.
The problem is described as follows:
To fix it:
Lo! the drop downs will now work.
Why?
Plone 2.1.x ships with three different copies of sarissa.js (one in Archetypes, one in CMFPlone and one in kupu). For Plone 2.1.1, Plone 2.1.2 and Plone 2.1.3 they are all the same. All of them seek to instantiate Msxml2.DOMDocument.5.0 as their first choice of MSXML component.
In Plone 2.1.4 the version in Archetypes has been updated to remove the attempt to instantiate MSXML5.0 but this doesn't actually matter, because if you have kupu enabled it is the one from kupu that your users get (due to the order of skins resolution by default), and that one still tries for MSXML5.0.
MSXML5.0 is "bad", (see this post by one of the Microsoft XML team for a detailed explanation) and will generate a 'gold bar' in IE7 (i.e. the user will be told of a security risk and asked if they want to proceed). Norton kindly just throws this message away, so things just stop working without the user being informed, leaving you scratching your head.
By upgrading kupu you will get the right version of sarissa delivered to the user. Why am I using kupu from the Plone 2.5 distribution, rather than downloading it from kupu.oscom.org? Well, at the moment at least, the latest version available for download from the kupu site is 1.3.5 (which still uses the old version of sarissa), while the version that ships with Plone 2.5 is 1.3.9 and has the correct sarissa version.
An aside...
It's worth also noting the version of sarissa.js (0.9.6) that ships with kupu 1.3.9 (and hence Plone 2.5) still tries for MSXML4.0 and doesn't try for MSXML6.0, something that was changed in Sarissa 0.9.7. Not that this doesn't work, but it's not recommended practice.
Because of this it might make sense to upgrade your version of sarissa.js to the latest version, particularly if you're making use of boilerplate code from the Plone Javascript or you expose some of the standard dropdowns to a very wide audience. It's quicker and more stable, and the versions of MSXML that it relies on are still well serviced by Microsoft. I've not tried this myself though, so YMMV.
You can get it from http://sarissa.sourceforge.net/
I know that Javascript is a major point of focus for the Plone 3.0 development team, so hopefully these sorts of problems should pass soon enough.
I'm currently working on the latest version of our Business Directory product for Business Link Kent (it should be going live on 8th Feb, in fact).
Because of the complex searching requirements plain old ZCTextIndex or TextIndex just aren't enough, and we've incorporated the very powerful TextIndexNG3 instead.
Unfortunately the installation documentation and so on doesn't really deal with implementing new indexes using the product. Nor does it show how to programatically convert the pre-existing indexes upon installation of your product; instead it is described as manual steps.
Manual steps do not play nice with either our automated testing strategy or the fact that we blow away and rebuild our development environments 3 or 4 times a day.
In your Install.py (yes, this is a Plone 2.1 site and no, I'm not using Generic Setup for this one) put the following function (I'm using stemming here, so don't copy this blindly if you don't want the effects of stemming):
Then call updateIndexes(out) from your install method and lo! your indexes are converted by your install script, rather than having to do it manually each time.
To implement new TextIndexNG3 indexes from within your Archetypes schema definition is very simple. I'm still debating whether I should be making use of the broader ability of TextIndexNG3 to search across a subset of the fields that it indexes (meaning that I might not need to create multiple TextIndexNG3 indexes), but for right now I'm going the simple route and defining them on the schema as I would for any other type of index.
Once you've installed TextIndexNG3 have a look at Products/TextIndexNG3/src/config.py. In there are all the parameters that you can pass at the point of index creation. To do this in Archetypes it's exactly the same as it would be for any other index; any non-default creation parameters should be comma separated after the index type is specified. For example:
So far the product looks very powerful, and it's definitely sorted all my complex searching requirements (ranges, booleans and so forth) that until now had me completely stumped.
We’ve just launched our first Plone 2.5 site for Gentleman’s Relish Amateur Cricket Club, and rather nice it is too. Admittedly we have put zero effort into skinning it - but it hardly needs it really.
I seem to be spending a lot of time inside Plone's workflow engine at the moment. This time I'm moving items around the portal depending on their workflow state (using workflow for archiving in this particular instance).
It's a fairly common use case and there are a few recipes out there ([1], [2], so I won't replicate them here.
That said, it's not made wholly clear in the first (from Andy McKay's excellent Definitive Guide to Plone) or at all in the second that when raising the state_change.ObjectMoved exception the first object passed is the object affected by the workflow (after the move), while the second is where you want the user redirected to.
So rather than automatically passing new_obj twice you can always pass a different second object (say the original location's parent folder). This makes a lot more sense in my case, for example, where my users are likely to be archiving a number of items simultaneously.
DateIndexes do not behave quite as you expect. They are only calculated to the nearest minute and they display incorrectly in the ZMI, both of which can throw you off the scent. This makes 10:58:58 on the 8th January 2004 a very special time…
Guard conditions in DCWorkflow (the workflow engine shipped with Plone) allow you to control whether a transition is available to the user depending on external circumstances. Usually these are simply based on permissions or the role of the logged in user, but in some cases you want to get cleverer. Provision is made for you to write TALES expressions that will be evaluated whenever the actions are shown, allowing for quite complex conditions to be written fairly simply..
However, there is one thing that you need to look out for… The predefined variables available to those workflow TALES expressions are not the usual ones available within page templates or other actions, and in fact things you absolutely expect (like context and member, for example) aren’t available at all. It’s therefore very worth reading this introduction to DCWorkflow (PDF) which lists all the available variables at the end. Should save you 15 minutes or so!
We’re deep into yet another very heavy customisation of Plone. No bad thing (it’s the kind of thing we like really), but we’re (yet again) getting bitten by acquisition. So, as much for my reference as anything else, here is a link to the very useful Untangling Acquisition page on zope.org.
I’m going to post something longer about the cool new things that will be available soon through Five in Zope 3 - but MrTopF has quite a good summary here. More later…
A much better day yesterday, with a lot of progress on the UberSelection Widget. Also the whole javascript thing looks like it is panning out OK - we are having some real discussions now, and I am a lot more optimistic that we’ll have a good solution to the many issues in integrating a lot of javascript into something like Plone. Hopefully I’ll have a good report on that tomorrow.
The Selection Widget has mutated into a project to produce a new query architecture for Plone, to support cross-datasource querying in a standard manner. It’s looking pretty good, even though it’s only roughly sketched out, and it could be a useful addition to the core. Alec has some ideas for a more advanced query syntax, supporting various sorts of conjunction across terms, so I’m going to look into how we can generate parse trees useful for real querying, as well as rendering queries as ZCatalog or LDAP queries, as it does now.
I think I’ll probably steal some of the excellent query stuff from Divmod’s Axiom which has a very nice implementation already. Generating parse trees from that should be straightforward, and I think it should be possible to generate ZCatalog queries too, although the existing ZCatalog implementation can be a bit weird.
One of the issues is how to collapse queries that can’t be rendered precisely - a tolerant implementation that does it’s best is probably the most useful.
I spent some time last night with Danny too, looking at refactoring the Sharing page, one of the use cases for mass selection. We iterated over the designs a few times, and managed to make it even simpler than his already very good design. Getting that prototyped is another task for today. I’ve got a very simple implementation of how the widget might work, using the LiveGrid widget from Rico, and we’ll be working on that today to show end-to-end querying of the catalog and of members, integrated with a mockup of the Sharing page.
On Norwegian cuisine, fire alarms and maybe a little on AJAX.
Oxfam has recently deployed Plone. They, their developers and the Plone Foundation have put together a one day conference on leveraging Plone for NGOs. Some interesting speakers across a range of topics. Definitely looks worth checking out if you can be in Oxford on 25th May.