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 ?
“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.
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
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)
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
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 !
Good news: Magnolia CMS 4.4 has just been released!
If you’re here, you’ve probably already seen the official announcements, be it in the newsletter, the user-list, the forum, Facebook, or even press releases, so you know all about the new features and improvements.
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 helped tremendously; 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 !