In the previous installment of this series of posts, we have created a new Magnolia-based project, including a reproducible build. We have a webapp that can be started in an IDE, or outside of it.
You might remember we added an STK theme to our project. And you might remember that it didn’t go all that well when we tried to view the first page we created. Continue reading →
This is the first of a series of posts, where I will attempt to consolidate a set of practices for creating, building and deploying Magnolia projects.
Why, you ask ?
Over time, Magnolia has grown into a fairly complex, but beautifully flexible product. There are a number of features, techniques and tricks that can make one’s life much easier. Unfortunately, I still see a lot of folks building or deploying their projects in ways that make me cringe. Not that they’re doing awful things, no, but it seems it’s high time to gather a few tricks here that will hopefully make a few folks go “aaaaahhhh”, and perhaps even a few others cursing me for not telling them about all this earlier.
In the past couple of months, by pure coincidence, we have been in contact with two independent companies providing semantic search services. Less coincidentally, customers have been asking for semantic search features in Magnolia for months. Trending topic ? Yeah, pretty much. While it can sound like a mishmash of buzzwords, “semantic search” can mean a lot of different things, but generally provides different – or new – ways of looking at, and navigating, your content.
In this blog post, I’ll expose a few of the problems we have with regular searches in Magnolia, and how we’ve implemented a module that allows using the above mentioned services, bringing semantics into Magnolia !
This release contains the biggest ever number of Magnolia modules (a whooping 41 for the Enterprise Edition), and 4 new modules (if I count well). Fixes span 16 Jira projects and amount to 145 issues.
The 4.4 release of Magnolia is also interesting for a number of not-so technical reasons: it is the first release where I’m not directly involved in development (more on that later), and the first major release where the team grew significantly: Federico joined us just before we released 4.2, but since then, Ondřej, Daniel and Tobias joined us too (this is their first major Magnolia release, woop woop!), and Antti helpedtremendously; last but not least this is also the first major release developed from the comfort of our awesome new offices !
We hope you’ll enjoy using it as much as we enjoyed making it.
4 months ago, I was whining about the fact that I couldn’t find a good-enough forum software.
In the background, we always wanted to improve our own forum; there were many shortcomings and the task seemed daunting. Well, that was without counting on help from the fine folks at Openmind. We’ve been hard at work to figure some of the big issues out, and long story short, our forum has been online since more than a month ! Check it out at http://forum.magnolia-cms.com.
Now, there’s still a lot of things to do there. One of them being improving the OpenID support. One silly bug, for example, is that if your Google account name contains accent, you won’t be able to login (I had to go and edit mine). And up until a few minutes ago, many users had wrong permissions for some silly reason I won’t disclose here (although you can find details on our issue tracker as usual)… so if you’ve tried it in the past, and gave up, please give it one more chance !
Another thing I’m hoping to get done is a bidirectional integration with our mailing lists, and improve the RSS feeds.
Let me know what you think in the comments, and share your ideas !
Since a couple of weeks, I’ve been looking, on-and-off, for “the” perfect forum software. The Magnolia community needs a (new, better) platform. At the moment, we’re relying on a wiki (good for draft documents, not so much for discussions), an issue tracker (again, good for tracking bugs and work progress, not so much for discussions), and a mailing-list; we have two mailing-lists: the developers mailing list, which is flooded with notification traffic, and the users list, which is gaining some traffic since the last few months. That extra traffic is a good thing (more users, more interest, more help and more feedback!) but can also drive some people away. (they’re not necessarily interested in getting emails from the Magnolia community all the time)
Update (2010-03-30): I finally revamped the “concept” page on the wiki, and it should now be up-to-date (more than this post), and provide some more insight on what’s next.
If you’ve been doing any templating with Magnolia, you probably know our tag library (the bits with <cms:). Some of these “tags” are responsible for rendering the “green bars” on your Magnolia pages.
This tag library been around since pre-3.0 times, and somehow has not evolved much since. Over the years, and especially the last, many concepts have been introduced in Magnolia which make large parts of this tag library irrelevant, and too complex, both to maintain and use. Content inheritance and i18n, for instance, are now supported at much higher levels in Magnolia.
Built-in support for different templating languages is also something we’ve introduced a while ago, and have been improving since 4.0; so far, we’ve been lucky that FreeMarker has support for tag libraries (and that contributors have helped improved, too!), but supporting other templating engines has always been a burden with regards to the tag library. Porting it to different languages is something we’ve always put off.
Since Magnolia 4.0, template scripts also have access to a bunch of objects, which make, again, parts of the tag library obsolete.
So, all this, to introduce yet another new feature of Magnolia 4.3. Not one that will make me the most popular kid on the block, but one I’m hoping users, templaters especially, will embrace nonetheless.
Oh, the bad puns one could make in the title of such an article.
Two weeks ago, we released the first milestone of Magnolia 4.3. Amongst other things (see my team mates’ blogs in the side bar!), we introduced Groovy support. It’s something that’s been done before (most notably by the folks at openmindLAB with their Groovy shell module), but we wanted to take things a few steps further.
I recorded this video (my first attempt at doing so – an experiment, really. Be forgiving) to try and show the basic features.
Now that the 2nd milestone for Magnolia 4.3 has been released, there’s more. Scripts are storable and editable in the repository, amongst other things! Edit your templates, your models (scripts), all from within the browser (or WebDAV), and publish it all, without manipulating jar files. Woohoo.
This new module is available with the Community Edition bundle (see the /add-ons folder). The sources are in the /community/modules section of our Subversion repository, and it’s also available in our public Maven repository. Discuss it on our mailing lists, and report any issue you might have on our issue tracker (patches welcome as always). But most importantly… ENJOY !
It’s been a while now (since I’ve posted here, yes, but that isn’t my point) that we’re undertaking agilizing our development practices at Magnolia. (yes, I make up words. It’s friday.) Every now and then, we’ll try something new. It’s always a challenge, since we can’t even do stand-up meetings (given that 25% of our small team is in another corner of Europe). One of the latest things we’ve started using is… a webcam; so that we can actually use a whiteboard, for instance, and have it visible by the whole team. It’s one of those fancy gadgets which you can rotate and zoom remotely. The little noise it makes when it turns its head towards you is a little creepy. And I’m not sure I’m ready to share these images with the world just yet. Which is a good thing, because that wasn’t the point of this article, at all.
Another thing we’ve also started using and sharing recently are mind maps. We need to track work items and their progress in our Scrum sprints, and we’ve realized it works much better for us than the whiteboard/cork board (remoteness problems), or the g–gle spreadsheet we’ve also been using until recently. But we’ve also realized it was a pain in the rear to get burndown charts out of that without manually counting items – which inevitably led to outdated charts.
We’ve been using mind42.com over the last month or so, and it’s worked pretty well, even when editing the map concurrently. We use some of its icons for each of the map items, particularly the “progress” icons, which we use on what would otherwise be story-items; a simple click on the icon increases the progress from 0 to 100% in 25% steps. And those burndown charts ? Ah, well. There’s an export-to-xml function on that thing. So, enter some http headers snooping, curl magic, regular expression fairies, python pixie dust, jquery hoodoo, and voilà !
For the curious amongst you (it’s fairly frustrating to talk to a completely impersonal and possibly absent “you”), here are some more details:
It’s all just one python script that fetches the exported xml (I lied above, I switched back to liburl once I realize I couldn’t install the correct version of pycurl on our server), does some regex magic to pick the interesting info out of the xml (absolutely no need to parse it), stores timestamped data everytime it’s executed, does some not-so-fancy calculations and generates the html page you’ve seen, based a on simple template. (gotta love the %(foobar)s)
This script is executed by Hudson every 12 hours, once during the night, once just before our scrum meeting, so that we don’t have to worry about updating any charts anymore, nor use our fingers to count the “done” items. Wooh.