Before you go on The changes described in this article are primarily for educational and learning purposes. The current logic used when renaming websites and assets in Magnolia is not a bug, it’s wanted behavior. There still might be cases when a customer requests pre-existing functionality, so the solution described here might be helpful for you - but as always: Do extensive testing when changing core Magnolia configuration and use the samples at your own risk!
Recently I had to provide several web services for creating application data in a Magnolia CMS app by using REST interfaces. If you haven’t already, I would suggest you first read the excellent official documentation about REST based web services available from Magnolia (see end of article for resources). You can find the code on GitHub, everything is contained in a Magnolia module based on Maven. Use cases provided In this article the following use cases will be covered:
What to achieve In the days of Magnolia 4.5 the publication dialog did contain both the fields for scheduled publication and un-publication. This way, publishers could define in advance to remove a specific page or page tree at a predefined date and time. Though the un-publication feature still exists in the Magnolia 5.x series, some publishers don’t like the complete visual separation of the publish/un-publish actions, because this way it can happen easily to forget about un-publication of a specific page if you have many tasks to handle as editor/publisher.
History This humble blog previously was based on an Amazon EC2 instance running Debian 8 as operating system. For creating and serving the blog posts, several incarnations of the Ghost blogging software fronted by the NGINX web server were used. At the time of releasing this article, this site is served by an Amazon S3 bucket holding a statically generated version of this site. See below for technical details.
I was going to start this article with the question: do you still remember Microsoft Access? But then I found out that this boil of a “database” system still exists. In my former life as a developer, this pseudo database product caused me so much pain because it was constantly abused for uses not really feasible for this kind of product. MS Access is a perfect product for Windows users managing their catalog of movies or contacts, collections of whatever kind or, to say it in a simpler way: for local personal usage of low volume data.
I recently discovered a problem when creating a provisioning script for Ghost with Ansible 184.108.40.206 on Debian 8 Jessie. The problem happened after providing the init script for Ghost and starting the service. The shell code would look like this: sudo update-rc.d ghost defaults sudo update-rc.d ghost enable sudo service ghost start The representation of the above in Ansible: - name: install - enable Ghost service service: name: ghost enabled: yes state: started become: yes On my Debian 8 based Vagrant testing instance starting the Ghost service always failed - starting the service only worked after restarting the Debian system.