This space hosts concepts, the roadmap and the backlog. It is not meant for content related to developing projects with Magnolia. For this kind of information the community space should be used.
The Team Blog
Time-based campaign pages using Magnolia's personalization (Part II)
In part I of this post, I showed basic use of Magnolia's personalization features for time-based campaign pages. In this post, I'll write about more advanced usage of the approach and outline some of its limitations.
Use cases and issues
Managing multiple campaigns with multiple pages. The approach I outlined in part I (assigning dates to a page variant using individual trait) works well enough if you have a small number of campaigns that involve a small number of pages. However, when you need to manage multiple overlapping campaigns that involve multiple pages, you need to use a more structured approach.
Managing campaigns with uncertain dates. If you primarily manage campaigns with certain dates – such as holiday-based retail campaigns – you probably won't need to adjust the dates of your campaigns once they are set up. If your campaigns are instead driven by less certain things like funding drives, playoff outcomes or ski seasons, you may need to adjust the display dates of many variants. You really don't want to this for every page variant (as you'd be forced to do if you used the simple method from the first part.)
Different assets per campaign. While many of the assets will be shared across pages (or content app items), each campaign may also have many unique assets. For example, your Nowruz campaign may involve holiday-specific versions of most common assets for your site. You need ways to make it easy to manage all these different assets without confusion.
Use short and consistent names for your campaigns. First, choose short and understandable names for your campaigns. If the name would work as a non-ironic hashtag, then it's about the right length.This will help you easily understand what page variants are a part of which campaign. You should use the same short name in all relevant contexts – audience names for page variants, asset folder names and segment names.
Create one segment per campaign. For the multiple page/campaign and uncertain date use cases, it's best to create a dedicated segment for the campaign.
Once you've created a segment, add a date trait and set the appropriate start and end dates for your campaign.
As you create page variants for your campaigns and set an audience for them, just use one of your campaign segments (instead of setting a date trait for the audience.)
Using one segment per campaign:
If you need to change the date for a campaign, you only need to change it in a single place to update every associated page variant.
Group assets using folders. In the Assets app, create one folder per campaign and put all campaign-related assets in it. This will make it much easier to avoid update conflicts (where one person overwrites another person's changes.)
Campaign dates are based on server date and time. When Magnolia decides what date and time to use for selecting a variant to show to a visitor, it uses the date and time on the server. You can make Magnolia use the visitors date and time by creating a custom personalization trait.
Day-level granularity. The default date trait doesn't let you specify times. The start time is 00:00:01 on the start date specified and the end time is 23:59:59 on the end date specified. If you need more granular control, you'll need create a custom personalization trait.
Mix carefully with Scheduled Publishing. Using personalization this way allows editors to see the state of the site at any future point in time using the Preview app. However, any pages that have been scheduled for publishing with the scheduled publishing feature will be invisible to editors using the Preview app. It's best to avoid mixing the two approaches.
Beware of auto-generated content. If parts of your site structure only exist for certain campaigns, you may find that auto-generated content – such as menus – may not work quite as you expect. In these cases test to make sure you don't have unexpected results. Alternately, it may be wiser to use microsites for certain campaigns.
Webinar retrospective: Building modern responsive sites quickly with Magnolia
Early in November, I presented a webinar that was (mostly) for Magnolia front-end developers.
Based on the feedback they gave, participants appreciated how the webinar combined many practical topics and techniques into a 30 minute live demo. Also, the whole demo was done with just an installation of Magnolia and without any IDE or Java coding. Developers could work with just the command-line and their favorite text editor.
During webinar attendees learned about these topics:
Magnolia’s content apps
Light development / configuration by file
In addition to these key points, I also provided tips on how to speed up Magnolia development by using the Neat Tweaks JCR configuration app instead of regular JCR configuration.
Watch the full webinar here.
If you have any follow-up questions or ideas for next front-end oriented webinar, please share them with me at tomas.gregovsky(at)magnolia-cms.com . Thank you!
Bringing more modern frontend goodness to Magnolia
Once upon a time there was CSS. It was plain and wonderful and everyone said it was good. But as projects grew in size the limits of CSS became clear. Heroic developers who were pushing the frontiers of what was possible struggled with massive selector lists and tangled nests of code that both obscured structure and hampered maintainability.
From this struggle, Sass, Less andother CSS pre-processors were born. These tools gave you ways to structure, organize and simplify their CSS. Now, nearly a decade after Sass was introduced, there are many other tools to make frontend work easier and faster.
Grunt and gulp are two of these powerful tools. They make frontend work so much easier that no developer who knows them would want to leave them out of a project. But in the past, you couldn’t use them inside of Magnolia’s development environment. Yes, you could use an external build script, but this isn’t a clean or easy way to add Grunt and gulp to your deployment process. About a year ago, the team at Arvato started investigating an integrated solution.
We wanted an easy solution to integrate the build process in our deployment process without using external tools other than Maven. We also wanted the solution to fully integrate Node.js – which would give us use Bower, gulp, Sass, Less, Grunt, require.js, watch tasks and more. It was also important that the solution:
Our solution was to use the frontend Maven plugin to install Node.js inside of our theme module. Now we can configure goals via Maven. In our case, we use gulp to build our projects, but it is also possible to use Grunt or other tools. We can define all node modules in our package files and use Bower to get vendor scripts from elsewhere. It is also possible to setup watch tasks to use gulp tasks without using Maven.
We now have a modern frontend tool chain running inside of Maven that is flexible enough to work in a lot of ways and really makes development easier. Because of the full integration, it is easy to deploy and doesn’t require you to check generated code into your Git repositories. You can use what you want from Node.js without touching anything inside Magnolia, and you can use any IDE that you like. If you don't want to compile with Maven, you can still run Grunt/gulp the way you're used to.
There is still more work to do on the solution. We have other approaches to test and still a lot of open todos. We’re very happy for your questions and for feedback on our solution. Maybe together we can find a way to be heroes that make development in Magnolia much easier.
Marvin Kerkhoff is an expert Magnolia developer who is the author of the Deadlink and Form2DB apps. He is the Manager of E-Business Solutions at arvato Systems Switzerland AG, a Magnolia partner located in Zürich.
Why digital transformation has to be strategic
If you work in business, you’ve heard about digital transformation. It’s likely that your company has invested in it heavily.
But does it actually know what it’s doing? According to recent research from MIT Sloan Management Review/Deloitte, less than 1 in 6 correspondents from companies at the early stages of digital maturity feel that their organizations have a clear and coherent digital strategy.
One of the key problems is that, in the rush to join the digital train, companies are concentrating on tactics rather than on strategy. In fact, the 2014 Altimeter report on the state of digital transformation found that some organizations confuse digital transformation with increased technology spending. Even worse, others see it as a mere extension of their website development.
So the key learning is that companies need to plan for next year rather than next quarter. They need to move from individual technologies to broader strategies. They also need to align their internal structure and processes with their stakeholder needs and interests. This means being ready to implement new processes and technology to optimize this journey.
Cross-functional collaboration has to happen first
One of the reasons for the disconnect between strategy and tactics is the fact that there is often a divide between the business and technology elements of a company. However, digital transformation can’t happen without cross-functional collaboration.
The companies who succeed at digital transformation are those who consider future possibilities rather than just current functionality. This means that integrations functionality is very important.
Organizations that use a flexible digital business platform will have an advantage, as they have the ability to quickly integrate new tools and data whenever they need to.
As Gerry McGovern pointed out, the digital revolution is cultural, not technological. If organizations truly want to succeed at digital transformation (and there really is no choice if they want to survive), then they have to learn to evolve culturally. In my next article, I’ll be writing about some top strategies for digital transformation.
Head over to CMSWire if you want to read the full article on digital transformation strategy.
20+ life-changing tweaks for Magnolia editors and developers
Yes, I recognize the clickbaity nature of the title...But users have reported these tweaks to be quite helpful indeed!
I've been with Magnolia for almost a decade now, so I have come to know a number of people who work with our product as editors, developers or integrators. I feel very lucky to count many of them as friends as well.
These friends have all been a great source of inspiration for enhancing the product. From time to time, they approach me with ideas or requests that might not exactly fit in with officially endorsed plans for the product, might be too specific to their use case or might only work on certain subsets of product functionality or in certain browsers.
Because I really like to tinker with things (and I'm such a helpful person), I usually try to help them. Sometimes, they're even nice enough to contribute some of their tweaks in return :)
In those cases, the code doesn't get to be included in the product and so far, I've mostly kept it private. Recently though, a few other people approached me independently and asked if I was willing to share this code collection.
If you decide to use the code in your projects as well, please remember that this is not official Magnolia code, meaning it's not supported and I won't guarantee that it works for you.
I would also ask you to contribute back any fixes or enhancements that you might make to the code - or even just reports on conditions in which a tweak doesn't work properly.
The enhancements can be grouped into two different categories - those for editors and those for developers.
As it often happens with me, I wrote much more code before I got to post about it, so right now the tweaks come in 2 major branches - 1.0.x (compatible with Magnolia 5.3.x) and 2.0.x (compatible with Magnolia 5.4.x)
#E1 Full screen width page editor
The action bar is still present in the editor view, but instead of taking up your screen real estate, it is semi-transparent and on top of the page.
#E2 Duplicating components
Not a fully fledged copy & paste, but a simple tool to duplicate a currently selected component into the area in which the component already exists. This makes it super easy to fill up the page with extra data.
In version 1.0.x, the duplication will place the duplicated component at the end of the list. In version 2.0.x, the duplication will place the new component right after the original one.
#E3 Change the component type for existing components
I was surprised to find that what might look like a complex thing to implement only took me about two hours. When using this one, you might sometimes see errors in the page if your templates were not written with the possibility of missing up mandatory data in mind. The edit button should still work, so those cases are easy to fix, just a bit scary when you encounter it for the first time.
For developers (that would be me, so the collection of tweaks is much longer :))
#D1 Linking from the page editor to the template definition
How often do you see a component in a page and want to check its definition? Happens to me all the time. For obvious reasons, this only works for JCR configuration, not for YAML (there was no YAML in 5.3.x, for which this was written in the first place).
#D2 Links to dialogs in a page or components template definitions
What started as simple "link this" or "link that" actually developed into something I like to call the "one click away" concept - you should only ever be one click away from where you want to go. And yes, the links below really are clickable and will open a tab with the linked data.
#D3 Links to extended nodes in the configuration
Same story as above. It is extremely useful at times to check out the node you are extending. Also, please note that the property value will turn into a link only and only if the linked target is valid, so you have immediate feedback for the value you entered and know if it was entered correctly or not. Side effects? As soon as a property value becomes a link, the only way to edit it is via dialog. No more inline editing ... personally, I don't mind, but if you solve this, please contribute back.
The true beauty of all the linking, which you will come to appreciate only after working with the feature for a while, is opening all those new things in tabs so you can always go back or even switch between tabs to look back and forth.
#D4 Links from definition to template script
And of course, when editing templates or dialogs, I often want to edit the template itself as well. Again, there's a difference in version 1.0 (for Magnolia 5.3), where the action will directly open the script for editing. In version 2.0 (for Magnolia 5.4), the action will open the resources app and select the script for you - and you need to either open it for editing if it's already loaded in the JCR, or make a "hotfix" first to be able to edit the script.
#D5 Action to build dialogs
This one is very experimental and still needs quite some love, but it will already create a skeleton of a dialog for you.
#D6 Action to build fields
Follow up on the above. Rather than building a complex action to do a dialog with all fields, there is a special dialog just for adding fields to existing dialogs. I never manage to get all the fields initially anyway.
#D7 Action to build a REST client definition
This one was just a quick time-saver for my presentation at the Magnolia conference, designed so that I didn't have to create multiple nodes when I knew I'd be short on time. If you work with REST end points, it will help you too.
#D8 Full width template script editor
Similar to the full width page editor. As a developer, I want to use all my screen estate for editing the code I need to edit online. Not just in resources, but really everywhere. And yes, I know I can make it wider with an extra click, but honestly, when would you not want to use full screen width?
#D9 Action to add anything
Building up on the syntax Magnolia uses for listing a path in the format node/node@property, you can now use the same syntax to create a node path and properties in one go ... Often I end up copying the path I want to create and then just pasting it in another location in the dialog. And yes, you can even specify it so that the node types for all parents are different from the last one in the hierarchy (not that you would need to do this very often).
#D10 Action to create a property
Really, how often do you want to create a property without naming it and giving it a value? Me? Never. I always need to set them up, so rather than doing that in multiple steps, there is now an action to do so in one go.
#D11 Action to create apps
Remember my script for creating apps from more than year ago? Yeah, I got tired of running the script, so there's a simple UI for it now as well (just in version 2.0, but it's backportable if anyone's interested). If you are missing the option for selecting the module in which to create the app, it's because the app will be created in the currently selected module.
#D12 Extends stats in config
Ever wanted to know how many extends you have? If any are broken? How many overrides you have? Well, now you can :) (again, just in version 2.0, and a tad harder to backport if you want to try). The styling isn't ideal for this one, but hey, you are free to contribute a fix for that. The best part though? It's clickable. Just click on the broken extend - it will open and you can fix it straight away.
#D13 Action to find usages of nodes
Sometimes it gets hard to know if I can delete a dialog or a template definition. Albeit a bit slow (due to the complexity of the query behind), this action can help you to find usages of dialogs, or templates or any other nodes (in case of extends) in the config.
#D14 In app bookmarks
Since version 5.0, Magnolia offers you favorites to create shortcuts to just about anything. This tweak does something similar, but on a smaller scale and closer to you - you can now add bookmarks directly in the action bar in the config app ... add with one click, scroll & expand to the place where you want to be. Just like that.
#D15 Action to open node in a tab
Sometimes you simply don't want to lose a reference and don't want to be scrolling up and down all the time. Now you can simply open it in an extra tab with a single click.
#D16 Ordered module nodes
Last but not least: 2nd and 3rd level nodes under /modules are alphabetically ordered now (and you can still choose your preferred nodes to be listed out-of-order on top for easy access).
And a few extra bits for good measure
#X1 Rounded icons in app launcher
This was really the result of a remark I heard from someone that the app launcher looks too little like Apple and too much like Windows ... That aside, I have to agree, I like it rounded more :)
#X2 More icons per line in app launcher
Once you get the app concept and start creating your apps for just about everything, you will see why it's necessary :)
For now, and also because a picture is worth a thousand words, please just sit back, relax and watch a few silent videos showing each of those tweaks.
If you liked what you saw and want to try it out too, here's the link to the modules themselves. One module contains all tweaks for editors, one has the tweaks for developers (and one commons jar they both share).
Please remember that the code in question was only tested on 5-10 different installations and just a couple browsers, so if it doesn't work for you, I'm sorry in advance, and would ask you to report back the problems you encounter.
You should be fine if you use magnolia 5.3.7 or higher for the 1.0 branch and Magnolia 5.4.2 or higher for the 2.0.x branch. It might even work on older versions, but the older the version you use, the more likely you are to encounter some weird problems.
Another few words of caution:
Have fun! And until we have comments enabled on blog posts, let us know your feedback on the forums.
Work in progress
- The current work can be found in the Greenhoper Kanban Boards on our JIRA.
- We move gradually concepts into documentation. Consult our Changelog page and sub pages
- This information is then integrated into the official documentation and release notes
Magnolia team members are blogging (contributors in alphabetical order):
Andreas - Revisiting the Magnolia UI
|Magnolia app design guidelines are go!|
|Magnolia 5's Editing Flow|
|Favorites: your personal space in Magnolia 5|
|Can a User Experience be designed?|
|Never miss a beat with Magnolia 5's Pulse|
Boris - BetterFasterBigger
|The curious case of the missing "management" in content management systems|
|Jackrabbit Oak – the revenge of the JCR API|
|What does Magnolia do?|
|Happy 10th Birthday, Magnolia|
|The future of content management: industry insider predictions|
Federico - The joys of craft
|Magnolia, REST and angularjs. A proof of concept.|
|Magnolia Apache Solr integration|
|Magnolia Groovy module 1.0-m2 video|
Jan - rah003's blog
Philipp - Magnolia CMS and beyond
|Magnolia Turns Ten: 7 Tips for Creating Long-Lived Software|
|Magnolia CMS 5.0 - Milestone 3|
|Magnolia CMS 5.0 - Architecture manifests|
|Groovyness - the agile paragraphs|
|Magnolia CMS 4.4 - Milestone 1|
Teresa - Teresa @ Magnolia
|Magnolia Blossom Module, STK Module or both?|
|JCR search text ignoring umlauts, accents|
|Importing tags with Groovy|
|Localized 404 errors|
|How To Export Website Content To Excel|
Tobias - Tobias Mattsson (Magnolia)