I started playing with Pico CMS this weekend. I converted everything that is on my Concrete5 based site into the Pico site on my development box. I am pretty happy so far with the system.
Struggles:
Markdown syntax
Including “widgets”
The markdown syntax is not hard, it is just unfamiliar to me. However, I can already see how it simplifies content entry. Once I get up to speed it will be fast and quite fun. Creating links with []() as a syntax is cool.
I also was not aware that tabs in your formatting makes Markdown misbehave. I am quite certain it is a feature, so that if you want to show code in pretty formatting you can just tab on a new line and it will output HTML rather than rendering the HTML. The same is true if you want a list and you press tab and then use an asterix, no list appears just an asterix and your content on the screen.
I have not yet determined the best way to include a “widget” in the markdown syntax. For instance, I have a display of recently read books generated from Good Reads and the HTML/JS/CSS that is generated for that is bulky. I would love to be able to include that chunk of code with something like
<?php include ('goodreads.html'); ?>
That may be possible but I haven’t figured it out yet as the include would be in a .md file not .php. For now, I just pasted the chunk into the page and it works but it does not seem to be maintainable.
Triumphs:
It is simply awesome to be able to create directories and have that become a path that is responded to by the CMS.
The system is so raw it lets me really see the web as a canvas again for playing and experimenting on.
In Drupal, it is very easy to create new paths using path-auto and alias. However, where that page lives is in the database. When it comes time to do a redirect it updates the database. Within the Pico paradigm, you just move the file or directory and the paths are updated. An Apache rewrite rule I am sure would be needed for continuity but there is no admin interface to go into, no menu structure to explain, it is simple. That is refreshing.
The default theme is not responsive but it doesn’t do anything with the content either. It is plopped onto the screen. As Pico is based on Twig I am excited to build a simple Twig and Singularity based theme. The theme will also have some classes built in to support slideshows. It will be a good adventure.
My website is powered by Concrete5 and WordPress. I develop professionally sites in Drupal. Now, I am considering migrating my blog and site to Pico. It is an interesting landscape, these “flat-file” CMS systems. There are a few very exciting looking pay-to-play products, Statamic and Kirby. However, Pico is free, uses an MIT license, and is built by the folks at Dev7 who seem to make nice products, and frankly it looks good out of the box as well.
I am a happy vi user so using a product name pico has a bit of an internal dig built into it. There are several other free flat-file systems out there as well. What I find intriguing about Pico is that it uses the twig template system. The twig system is what powers the themes in Drupal 8 so there is a good chance what I learn in Pico will be applicable to my D8 theme modifications and vice-versa.
What all of these systems use for text entry is Markdown. I am slowly beginning to see the convenience of it though HTML isn’t difficult for me, learning Markdown has been a process. Making lists with an * or headings with ## is quite cool. I’ll be able to adapt.
Pico’s code seems to be fairly stable too. The github issue page is fairly active and folks are making pull requests. This is what makes choosing a new system difficult, trying to answer the question of will it be around in the future? One way to make sure it sticks around is to take the plunge and give it a try.
The 2013 Drupal Summit was a great event. This was my third such summit and it was another solid Drupal event. I wanted to list the key ideas I took away from the conference as well as some modules and software that I am unfamiliar with but heard about over the two days.
Key Ideas
Testing is becoming a major part of the Drupal development process.
This is awesome! There were fantastic sessions on PHPUnit and several on Behat. It is certainly a positive direction. There is no requirement to write tests but there is tremendous upside if you are creating reusable components, building from an install profile, or have mission critical components. Testing has been around for a long time with SimpleTest and other methodologies. However, there seemed to be a big focus on it at the summit.
Treat your site, service, component, etc… as a product.
I really enjoyed this concept. It appeared in several sessions as an underlying theme. The main concept is that whatever you are building, try hard to make it as if it was a standalone product. It should obviously work well, but how is the UI, is there documentation, tests, versions, etc… If we try for the above with each project or anything we are developing the finished piece should be better overall.
You have code on a production server that does not allow Drush to be running and you do not enjoy the idea of copying over live files. If these sites are already tracking a git repository that is great, simply do a push and pull and you are done. It gets more complicated though if the repositories are woefully out of sync or if they have never had a git repository configured.
Proposed Solution:
The solution I devised allows you to update the site locally, make a nice commit, and then fetch it on the remote server and reset the filesystem to the fetch that was just made. Here are the steps:
Create a git repository within your development site (skip this step if you already have git enabled).
$git init
Use Drush on your development site to update Drupal core.
$drush pm-update drupal
Test your site and then add and commit the files you have just updated.
$git add -u
$git commit -m"Upgrade to Drupal version x.yz"
Create a remote repository if you do not have one already configured. Once that is created link your development repository to the remote and push your updates.
Now, go over to your production site and create a git repository like in step 1 above. Next, you will add the remote, fetch the update from that remote, and then reset your file tree to what you just pulled with the following commands.
That last command will rebuild the file system based on repository and from now on you can do normal push and pulls. Make sure to run update.php to get your database in sync with the new Drupal release.
Reflection:
I know the above is quite unorthodox. You also need to be careful as it will only rebuild the files you are tracking. I do not normally advocate for tracking entire Drupal installs but if you are in a situation as detailed above, it may be one of the few ways to have a sane update mechanism. For working with remotes I find the git-scm reference pages very handy.
Monitoring one or two Drupal sites can be done by logging into the status report every few days and reviewing settings, looking at your watchdog log, and reading the emails the sites send you. However, as you run more and more sites that process becomes overwhelming and can take up a large amount of time. A few services exist to help monitor all of your sites in one place, Droptor, Drupal Monitor, and Acquia all provide really slick solutions. However, if you want to roll your own due to cost, corporate security, etc… the Drupal community has developed several tools leveraging Nagios.
I wanted to set this up to monitor the sites I manage and chose to use Icinga, a fork of Nagios and openSUSE 12.2 as that is consistent with our environment. Currently I am doing this as a proof of concept project and it is running inside of VirtualBox on an older Mac. The Drupal projects that I am using are the following:
These two modules first let us talk with our Nagios server but also provide most of the stats you can find in the paid services. On initial install the results are not all that pretty to look at but I believe there are ways to fix that and I would rather have comprehensive than pretty any day.
Installation was inspired by the post at awebfactory. There is currently no write-ups on how to do the install if you are using Icinga but since it is a fork of Nagios all of the steps are quite similar. I still know very little about Nagios so if you see a goofy config file please improve upon it. The readme file that accompanies the Nagios Monitoring module is fairly comprehensive and if using Icinga use the Nagios 3 style configuration options. Here are four tips that I wish I had known while setting this up.
4 Tips
You must define a host in your .cfg file you create for monitoring the Drupal sites. The README assumes you have done this already but if you are creating a monitoring server from scratch this is news. Add the following at the top of the hostgroups.cfg file the instructions ask you to create.
define host{
use linux-server
host_name domainname.edu
alias DevVM ; You will see what you put here in Icinga
}
The unique string you generate for use in the module and within Icinga goes where the instructions have the words unique identifier.
Initially my Drupal check was not returning any results. I got an error “Service Check Timed Out.” My dev server is a little pokey so I needed to edit the service_check_timeout line in icinga.cfg from 60 to 600. I chose 600 because this article uses it, very scientific, I know.
The SUSE Icinga package places Icinga in /etc/icinga, /etc/init.d/icinga check_verbose checks your settings in the .cfg files you have edited/created and /etc/init.d/icinga restart restarts the service.
Installing Icinga
Thankfully there is a package for Icinga in the openSUSE repositories. I installed this using the GUI tools but if I move out of a proof of concept phase I would do this with an openSUSE box run level 3 so I will try to show the command line install options rather than how to use Yast. This generally just involves following the documentation at http://docs.icinga.org/latest/en/quickstart-icinga.html.
Install the dependencies:
$ zypper install gd gd-devel libjpeg libjpeg-devel libpng libpng-devel
$ zypper install net-snmp net-snmp-devel perl-Net-SNMP
Create a user named icinga, please follow the instructions at the link above.
$ zypper install thttpd
$ sudo vi /etc/icinga/etc/objects/contacts.cfg
Change the email address associated with icingaadmin to one that you can receive email at. ESC : wq ENTER to exit.
Set the password for icingaadmin
Verify everything is good with your initial configuration.
$ sudo /etc/init.d/icinga check_verbose
Start Icinga
$ sudo /etc/init.d/icinga start
Navigate to http://localhost/icinga/ and login with icingaadmin and the password you set earlier.
Install the Nagios Drupal Check service
The steps in the README file are correct for openSUSE. Just use the Nagios 3.x version of the commands and follow tip number 1 from above.
Final Result
A nagios alert showing issues with a site I have in dev.
I started monitoring a site I have on my devVM and it shows me a boatload of issues. Core is out of date, stuff is turned on that shouldn’t be for a production site, modules need to be updated, etc… The beauty of this is that I simply need to turn the module on for each site I want to monitor, update my hostgroup definition in hostgroups.cfg and I have instant monitoring. I hope to provide further details such as NRPE on the remote host, selective alerts, and a prettier interface.
