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 22.214.171.124 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.
The need for monitoring Many software projects are constructed out of many components which sometimes can be hard to monitor. Especially during the development phase of an application, it can be crucial to gain information about possible bottle necks that may prevent successful production usage of your project very early. One possible performance metric may be the amount of possibly unnecessary SQL statements executed while using your application - this is a real use case I had in a large Magnolia project to increase performance.