Mustache support in Magnolia

Earlier today, I was in meeting where I mentioned Mustache to partners. They looked at me: “yeah, but does it really work?”. I kicked myself in the butt, because all I could say was, “in theory, yes”.

Well, I’d kicked myself enough about this and couldn’t take it anymore.

It’s now more than theory, and is on Git: http://git.magnolia-cms.com/gitweb/?p=forge/mustache-rendering.git
… and Jira, because really, at this stage, it’s just a proof of concept. I was still happy to get that under just a few lines, but I’ll now need help to get it to the next level. Please contribute !

If you’re wondering what Mustache is, it’s just a great templating language that exists on several platforms (javascript, ruby, php, java to name a few), with a proper spec and a battery of tests to validate every implementation.

Mustache: http://mustache.github.io
Mustache.java: https://github.com/spullara/mustache.java

Magnolia turns 10 – turns out I’m a 7 year old Magnolian, too !

There seems to be a trend among some old timers at Magnolia to write about what Magnolia turning 10 meant to them. I followed suit; other than making me feel old, here’s what I came up with.

I joined Magnolia in 2006. Unbeknownst to me at the time, I was joining a company that went through a bunch of hoops, ups and downs, and was just on the verge of taking a huge bet by releasing its first “Enterprise Edition” – a paid-for version of an otherwise free and open-source piece of software, which was a fairly new concept at the time. Oh well, what could go wrong ?
Continue reading

Magnolia CMS and PHP – a lovable Frankenstein !

“Yikes”, I hear some say. But put your curious hat on, and read on. The possibilities are endless.

Back in late 2011, we were contacted by the fine folks at Liip – they were hard at work on PHPCR, and were looking at creating synergy with the JCR world. It took a little while before we got our hands dirty, but one day in April, I went to meet Lukas, David and Alain – they showed me what PHPCR was about, and what they’d done with it so far. We proceeded to look into integrating their work with Magnolia.
Continue reading

Getting the “real” URL of a Maven project in a Velocity template… should have been easy.

So, it’s Friday evening, and all I’m left to do if fix our generated NOTICE.txt files.

We’re using the Maven Remote Resources Plugin to generate all sorts of files, like a README.txt, NOTICE.txt and a LICENSE.txt.

The Notice file is supposed to contain a list of all other software used by the one in which the file is built; typically, libraries, etc. It is meant to say who wrote that software, what license it’s using, and provide links to all those resources.

Now, we realized a couple months ago that this in fact did not output the expected URLs in all cases. Here’s an example:

This product includes/uses software(s) developed by 'Magnolia International Ltd.' (http://www.magnolia-cms.com)
  - magnolia-core (http://www.magnolia-cms.com/magnolia-core)
      License: GPLv3  (http://www.gnu.org/licenses/gpl-3.0.txt)
      License: Magnolia Network Agreement  (http://www.magnolia-cms.com/mna.html)
  - magnolia-gui (http://www.magnolia-cms.com/magnolia-gui)
      License: GPLv3  (http://www.gnu.org/licenses/gpl-3.0.txt)
      License: Magnolia Network Agreement  (http://www.magnolia-cms.com/mna.html)

And what I’ve been spending the last couple of hours fighting, is those two completely bogus URLs to magnolia-core and magnolia-gui. They don’t exist. They’re certainly not referenced as such in our POM files. So what’s going on ?
Continue reading

Git at Magnolia – now a reality !

Back in December (I had to look it up), we decided to switch Magnolia’s codebase to Git. As far as I can recall, there were mostly 2 factors that drove our decision:

  • popularity. That might seem shallow, but when thinking about ways to attract contribution and participation, it really makes sense. If a tool makes it easier to contribute, for newcomers and seasoned Magnolians alike, then we should go for that tool. Git is that tool, and GitHub’s success quite likely largely contributed to the fact that many developers are now familiar with the concept of a “pull request”.
  • branching. Veterans (gosh I sound old) in the core team have been scarred by, and scared of, branches in Subversion for quite a while now. We hardly ever branched for anything else than maintaining older releases, and that made “innovation” difficult, for a ton of reasons that I suppose are fairly obvious.

With that in mind, we started thinking about when and how to migrate. Continue reading

Customizing mod_dav_svn’s output

It’s one of those things I’m pretty sure I’ve done before and couldn’t put my hands on anymore, so I’ll just leave it here. Hopefully it serves someone else, or myself, at some point.

I was looking for a way to add a “warning” banner, such as the one which is now up at http://svn.magnolia-cms.com/svn.

mod_dav_svn, the Apache mod used to serve Subversion repositories over HTTP, can also be used as a minimal front-end for html-based browsing of repositories. Unfortunately, its output is not very customizable, if at all: all you get is a directive that lets you specify an xslt sheet (yuck) for transforming the output; and if you do decide to go down that route, the transformation happens on the client side.

So I thought about using another Apache mod to modify the content served by mod_dav_svn. At first, I was going to go for a crude User-Agent detection, but realized that, when requested via a browser, the content was sent as text/html, while when requested via a proper SVN client, it was sent as text/xml. Good, then all I needed was provided by mod_ext_filter. All that was left to do was figure out the command I’d want to run with this filter…

Continue reading

Magnolia CMS and semantic technologies – follow-up on the SalsaDev webinar

Back in August, I introduced the “External Indexing Module” for Magnolia CMS. Just last week, we had a webinar with salsaDev, where they introduced their technology stack, and I demonstrated how to use it with Magnolia and the External Indexing Module.

For those who missed it, it’s now available on our website. Unfortunately, we didn’t have time to address all questions asked by the audience. We usually send a follow-up email to the audience of webinars, but why not publish those unanswered questions as well ? Well, we decided to go ahead and just do it. It provides some interesting insights and different perspectives on the problem and the solution. (Questions were anonymized, some questions were slightly rewritten or merged when they touched on similar topics. The answers were written collegially by salsaDev and myself)
Continue reading

Git at Magnolia

You might have heard or read about it, Magnolia is finally moving to Git.

The main reasons for this move are the pains of merging and branching (i.e we just don’t branch as much as we should because Subversion makes it painful) and pull/merge requests as a way to make contributions simpler for users as well as for us to integrate.

I’ve been investigating tools for a while and I’ve come to a few conclusions… and more questions. Some of the requirements for having our codebase moved to Git make this choice a little more complicated than I’d like.
Continue reading

Follow-up on Magnolia User Group in Prague

On November the 24th, almost 3 weeks ago, a few lucky people met in Prague, Czech Republic. The second ever Magnolia User Group meeting was held. Chances are you heard about it if you follow Magnolia posting, but please read on. While this is my first blog about the concept and the event, I tweeted a lot about it and sent a couple of emails around.

What’s a Magnolia User Group? What happened in Prague? Why should you care? Read on!

Continue reading

Don’t deploy Magnolia: deploy your project.

In the previous episodes of this series of posts, we have built a Magnolia CMS-based project, and learnt about how to make it self-configurable. It’s deployable as-is, in your container of choice, but it is not production-ready: for example, you probably want to use an external database instead of the built-in Derby. In this article, we will see how to make this possible, without having to configure anything manually before each deployment. Continue reading