The ultimate Magnolia website launch checklist

Datetime:2016-08-22 22:20:20          Topic: XML  Bootstrap  Tomcat           Share

Published on August 5, 2016 byMatteo Pelucco

It’s 2am in the morning, IT team and devops are launching the new website. Ok, we're ready.. 3..2..1.. no, wait a minute: Have we considered everything ? Are we really ready to launch our new Magnolia-based website?

When launching a website it's 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 has its own, and during my last website launch, I tried to get that written down (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 handle 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) is available in XML for quick restoring
    • Have your data ready. You can be doing it at 2AM and you could have someone behind you that tries 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 they  must stay there..). So, importing XML on publicInstance can be a quick solution for those circumstances.
  • 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 it is quite easy to write a scheduled job that periodically exports XML files on some filesystem path.. but once done, please.. test them! You don't want to 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 it happened to me to find a low-visit website still running on Derby after 2 years, due to a wrong Magnolia.properties configuration. Moving that data to MySQL was 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 and 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 projects, you cannot export XML data; it is simply.. too big. 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 file from JCR, that file is first placed on the server filesystem, then served to you via http. And sometimes never removed. The same happens for DAM upload zip files..
  • Stress test  on author instance
    • How many editors do you have? Each of them requires some RAM (and CPU) on the author instance. Ask 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 your 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 broken links. Let a URL scanner ( XENU is very simple but effective!) find all your broken links and fix them
  • 404 / 500 pages are set up
    • I strongly prefer static pages. Imagine you have a broken query on site navigation, and a 500 error is thrown.. Tomcat (or any other container) wakes 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 an 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. It's easy to have it out of the box, just configure it. But try it and check if sitemap url is the same as what is present on robots.txt
  • Search result is working and is searching actual content
    • Probably a 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 disallows any remote access to Magnolia key features (login, activation, command execution..)
  • superuser password has been changed and is strong enough
    • You can't imagine how many live websites 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 calendar a week before, to avoid website degradation once license expires.
  • SMTP config has been successfully set up , test e-mails 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 allows 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.





About List