Ultimate Magnolia Website Launch Checklist

It’s 2.00 in the morning, IT team and devops are launching the new website.

Ok, we are ready.. 3..2..1.. no, wait a minute: did we considered everything? Are we really ready to launch our new Magnolia-based website?

When launching a website is a good practice to have a well-planned checklist to follow, step by step: if you Google a little about that, you can find a lot of ready-to-use website launch checklists. I’ve found this one, quite well structured and general enough to be applied to any website.

But every CMS / website engine has its own, very specific, checklist to follow: Magnolia CMS has its own, and during my last website launch, I’ve tried to have that written (and saved for later!). Here is my Ultimate Magnolia Website Launch Checklist, v. 1.0

• Magnolia project is installable from zero
  • This is crucial. Every Magnolia project should have self-configurable modules, generating servlets, creating repositories, bootstrap tasks.. every module configuration must be saved in module (and on source repository!!). Special modules (“core” modules) should handled system-wide configurations (cache, filters, app personalizations..). Any instance must have its own bootstrap files on filesystem WEB-INF/bootstrap/* folders.
• Magnolia project data (JCR ones) are available in XML for quick restoring
  • Have your data ready. You can be at 2.00 AM and you should have someone behind you that try to unpublish (maybe from Website JCR utility app) some content at root level.. and you have no time for a selective activation (yes, there are also red pages on author and must stay there..). So, import XML on publicInstance can be a quick solution for that circumstancies.
• Magnolia backup is set (and a restore has been succesfully tested)
  • Remember: Magnolia backup is available only for specific versions (e.g.: 5.x backup is available only for EE version). But is quite easy to write a scheduled job that periodically exports XML files on some filesystem path.. but once done, please.. test them! You won’t be in a situation were you must import a broken backup.. for sure!
• JCR is writing on productive databases, not on Derby (or InMemory!)
  • One time happened to me to find a low-visits website still running on Derby after 2 years, due to a wrong Magnolia.properties configuration. Moving that data to MySQL have been mandatory, but not straightforward.. and took me extra (unpaid) time.
• Subscribers are working fine
  • They should rely to internal addresses, directly on server container (e.g.: Tomcat), without passing through web server / reverse proxy
• Load balancer is working properly
  • If you have more than one public instance and your website supports user actions (forms, login, sessions..), you need a sticky (or syncin’) session. It needs to be tested in depth.
• Default sample websites (/demo-project,  /demo-features) have been removed, both from website than from DAM
  • Just remember: if you upgrade Magnolia, STK modules sometimes require those nodes to be there.. in that case, please, re-import the XML backup for a while, perform the installation and then remove them again..
• DAM is well structured and you can easily export as XML
  • Having a single-root DAM is not a good choice. For medium-to-big project, you can not export XML data, it is simply.. too big (really, it can lead to Heap Space!). And forget about activations.. A good and simple strategy is to structure DAM tree into small nested sections.
• Put Big Data downloadable files static on /docroot
  • For instance, if you have 1GB of video to stream as a background on your 4k layout website, place it outside JCR. In this way you can also eventually stream it with mod_h264_streaming..
• Cleaning script have been tested
  • Magnolia sometimes leaves garbage on filesystem. Please be sure to clean temporary download / upload files. E.g.: when you export an XML files from JCR, that file is first placed on server filesystem, then served to you via http. And sometimes never removed. The same happen for DAM upload zip files..
• Stress test on author instance
  • How many editors you have? Each of them requires some RAM (and CPU) on author instance. Test them in concurrent workflows, to see if your iron (server..) is big enough.
• Analytics is tracking, but only on public instance
  • Yes! We have 2 instances! And we don’t want to have dirty tracking.. so, enclose you analytics code in [#if cmsfn.publicInstance] … [/#if]
• Link analysis (broken links)
  • Magnolia internal links (based on STK templates / dialogs) are well handled. But unfortunately, CK Editor links are not under link integrity checks and can lead to a broken links. Let a URL scanner (XENU is very symple but effective!) find all your broken links and fix them
• 404 / 500 pages are set up
  • I strongly prefer static pages. Imagine you have broken query on site navigation, and a 500 error is thrown.. Tomcat (or any other container) wake up, forwarding that error to another configured Magnolia page, reproducing the same error.. avoid loops, use static pages.
• robots.txt is well configured and is pointing to actual sitemap.xml root
  • Let robots.txt be served with a simple VirtualURI, then configure it statically on /docroot folder. Update the default sitemap.xml reference, using an absolute link (with protocol, domain and ports!). Remove any information about Magnolia (e.g.: Disallow: /.magnolia*)
• sitemap.xml has been configured. And activated.
  • Try that. Is easy to have it out of the box, just configure it. But try it and check if sitemap url is the same of what is present on robots.txt
• Search result is working and is searching actual content
  • Probably stupid point. But check if the keywords “test”, “lorem ipsum”, “magnolia”, “asdasd” are found on your search results
• UTF-8 in URLs (Tomcat URIEncoding parameter)
  • Another key point. In Tomcat, you have to configure it (URIEncoding=”UTF-8″). And check also if UTF-8 is enabled in Magnolia (magnolia.properties)
• https (if enabled) is working fine, certificate is genuine
  • Try it! Port is 443.. but you don’t have to type that 🙂
• /.magnolia disabled on public instances, via proxy (you still have to access from internal network)
  • This disallow any remote access to Magnolia key features (login, activation, command execution..)
• superuser password has been changed and it is strong enough
  • You don’t imagine how many productive website are open to superuser/superuser pair..
• superuser has been cloned to provide a backup access
  • You share superuser access with IT people involved in the project. They set up a monitor link to check authorInstance sanity. You periodically change that, but for some reason, monitoring script is not updated. Your superuser access is gone in 1 minute. Having a backup one allows you to fix that. Keep it secret!
• Cache is well configured
  • Double check cacheFactory settings and includes / excludes voters. Remove from cache members areas login pages, dynamic session-based pages (logout, profiles..) and everything should simply.. be fresh!
• License
  • If you are on a EE, don’t forget to place your license key on instance bootstrap (-webapp). And of course, add a reminder to your caledar a week before, to avoid website degradation once license expire.
• SMTP config has been succesfully set up, test e-mail have been sent
  • You can find it on /modules/mail/config/smtp
• Magnolia property “magnolia.update.auto” is set to “true” on public instances
  • This allow final web users to see “Magnolia need to be installed..” message when you deploy a new release of the project

For sure this list is not the ultimate one. But I’ll keep it up-to-date, guaranteed.