MariaDB includes important security fixes, a high performance drop-in replacement for the InnoDB storage engine, named XtraDB, and is a completely compatible replacement for MySQL without the doubts surrounding Oracle's stewardship of the MySQL project. In addition, MariaDB is headed up by the original MySQL project founder and lead, Michael "Monty" Widenius. In short, there is no good reason not to use this exciting fork of the venerable MySQL database project.
We need to add a new repository to our list of recognized package locations and ensure the digital signature is recognized.
Upgrade the packages
This one is very straightforward:
aptitude upgrade mysql-common libmysqlclient18
Aptitude will respond with a bunch of messages and ask you for confirmation before it attempts to overwrite what you have in place. If all goes well you will now have MariaDB installed.
Recently we had to integrate one of our Drupal sites with an iPhone application. A 3rd party was developing the iPhone application so basically we just had to provide the API and give some examples on how to talk to our Drupal site.
'No Problem!' I thought. We could simply use the services module. We did it several times before using the XMLRPC interface that comes with the services module.
JSON, For the Win!
We learned that using the XMLRPC flavor of web services isn't ideal for mobile access applications, because of it's verboseness. Basically, that means all the XML tags used to give structure to the actual data eats a lot of unecessary bandwidth. It turns out the JSON interface is a lot more economical.
Prerequisites
As a client consuming the web service, it's assumed that you already have the following prerequisites set up:
A Drupal user account (username & password) with a role that has access permissions to the web services.
The API key that was created in the system (Site Building > Services > Keys)
Your web services is configured (Site Building > Services > Settings) to
a) Use the 'Key Authentication' Authentication module.
b) Use keys is checked, and
c) Use sessid is checked.
In a nutshell...
With those in hand, the basic conversation goes like:
Broken down...
What do these requests actually look like? They're actually just POST requests made to your Drupal sites' /services/json-rpc URL, with 2 query parameters: method and params.
system.connect
Actually, I lied, the system.connect service is the only one that just takes one query parameter, the 'method'. Send a POST request to /services/json-rpc and you'll get a SESSION_ID in return. Save that for the user.login service call coming next.
Access: GRANTED
After you successfully call the user.login service, Drupal will return to you a new SESSION_ID. Save your new SESSION_ID, and call subsequent web services the same way as the user.login request, but using the new SESSION_ID.
I recently updated some code to use PHP's SimpleXML libraries to generate the XML instead of using templates.
Why?
The main benefit is that by using SimpleXML, you don't have to worry about encoding and poorly formatted XML. Further, using a programmatic approach to building your XML documents helps clarify the intent of your code and makes the code more maintainable.
My first thought was that the function must have morphed into a different function name. Grepping thru the taxonomy module, I couldn't find any functions that took $nid as a parameter. Maybe it got moved to the node module? I couldn't find any node_term* or node_taxonomy.* type function calls that took a $nid or $node as a parameter either.
It turns out that taxonomy terms have evolved into a field in in Drupal 7, so you'll need to use the field api's to access the terms to which a node belongs. Here's the secret sauce to find the taxonomy terms for a given $nid:
Since D7 came out, there are many people who are skeptical about how easy it is to manage media types and files. What if we want to make a gallery only images or a gallery of videos? What modules are best to use to make this job simple?
Some modules needed to make simple image galleries for D7 are already part of core: Image cache as Image styles, CCK as fields and Views. To make the gallery more robust, follow these steps:
To create a lightbox gallery:
Add the fields you want to be displayed in the gallery and exclude all of them.
Add the colorbox trigger in the field > Replacement Patterns and include the thumbnail as the trigger, the entities (ex: video field, image field, description) on the popup and the title on caption.
The width and height will need to be tested depending on how much content is placed on the popup and theme.
Add views paging and sorting, if you want, and save. Now you have a simple image/video/mixed contents gallery.
For a video gallery with slideshow or to imitate Youtube UI:
Add the fields you want to display in the slideshow and exclude all of them.
Add the global custom text > Rewrite > Replacement patterns and include the title and entities (ex: description, extra fields).
On Style Settings of the view, click on Slideshow then its gear.
For slideshow settings, make slideshow type as cycle and choose the effect transition.
Click on View Transition Advanced Options:
To make it auto rotate, make timer delay have a value more than 0 (preferably 5000)
A bewildering array of services and hosting providers are available to host your Drupal site. Which should you choose?
In this post I will discuss the pros and cons of hosting your Drupal site on Pantheon, Rackspace Cloud, and a traditional hosting provider such as Hostgator with cPanel front end, which are three options we support at Sage Tree Solutions. Of course there are even more options available, but that's outside the scope of this article.
Pantheon
Pantheon is a cloud-based hosting solution developed specifically for Drupal. It combines simplicity in administration with best practices for very high Drupal performance and scalability and includes development and test servers alongside the production servers. A true one stop solution for most Drupal projects.
Price
At the time of this writing a standard Pantheon Drop - their terminology for a process space, which equates to a server elsewhere - costs $100 per month.
Pantheon Pros
Rackspace Cloud
In contrast to Pantheon, the Rackspace Cloud represents a completely unmanaged solution. You get a virtualized server in the Rackspace Cloud and are responsible for setting it up and maintaining it, a service we provide at Sagetree Solutions.
Price
At the time of this writing a Rackspace Cloud server with 1 GB RAM and 40 GB of disk, which is a good size for most small to medium size Drupal sites, costs $43.80 per month, and additional costs for bandwidth apply.
Rackspace Cloud Pros
Hostgator
Hostgator and many hosting providers like it represents the previous generation of hosting solutions. I.e. a tried and true setup, trusted provider and long track record. In addition, Hostgator VPS (virtual private server) instances have (optional) WHM and cPanel web interfaces to manage the server.
Price
At the time of this writing a Level 4 Hostgator VPS (virtual private server) with 1 GB RAM and 59 GB of memory, which is a good fit for medium size Drupal sites, costs $79.95 per month.
Which should you choose?
If you need a hands-off Drupal hosting solution with built in security and scaling potential, Pantheon is your best bet and probably also the lowest cost solution.
If you like to tinker with your site and server, you are in good hands in the Rackspace Cloud.
Likewise, if you work with a trusted service partner to monitor and manage your server (such as having a server and site management agreement with Sage Tree Solutions) the Rackspace Cloud represents a good solution with potential to grow with your business and ideas.
Spurred by a completely broken server at one of our clients we are re-evaluating our own backups and disaster recovery plans. As we all know, most people give little thought to backups, and even less to how to use them for recovery. In the meantime our servers quietly hum along and then act up at the most inopportune time. It is not a question whether a server will fail or not, it will - it is just a question of when it will fail and what you will do to recover from the failure.
Know the Risks
Your first line of defense is knowing your site, identifying single points of failure, and placing a probability on the failure. Then you figure out how much mitigation you need to reduce your exposure to risk.
Mitigate the Risk
Code and databases are most prone to break or otherwise get corrupted. Fortunately we have easy solutions in code repositories and backups. The harder problem is how you will make use of those tools to recover from a failure, but we will address this later. For now make sure you create backups on a regular basis and that at least some of these backups do not live on the same server. Also make sure that you have backups for everything, the server OS and its configuration, your site code and the database(s).
The Importance of Offsite Backups
Or maybe we should rather call this "the importance of off-server backups". Regardless, you need to absolutely make sure most of the backups are not stored on the server itself. If the server crashes completely and takes its storage with it - believe me, it happens! I have seen it many times, most recently last week - you need those off server backups. So be absolutely sure there are backups elsewhere and recent enough for your comfort level. You will need them some day.
Develop a Recovery Procedure
Having backups and spare parts in hand is well and good, but you want to be able to do something with them. Moreover, when you need them you will be very stressed or worse, not be there yourself. You need a recovery procedure, fully documented and ready to go. Take your time with this, you will be glad you did. Make sure all steps are covered, that someone only vaguely familiar with the setup can understand it, and most importantly, that it contains information on how to access passwords and other security features in a secure manner.
Test the Integrity of Your Backups
Finally, you want to be sure you can actually get a server back with the help of your recovery procedure and necessary parts and backups. At the very least review the recovery procedure once or twice a year and check for accuracy given the current server configuration, and look through your backups to ensure they are readable and able to be unpacked. Better still is to perform the basic recovery steps and thus test whether it all works as planned.
This is the first in a series of blog posts that provide a guide to integrating Drupal and Solr search. In our series we will provide a quick introduction to using Solr, an in-depth enterprise level deployment strategy, an evaluation of Drupal integration methods and a series of posts on search interface and results presentation.
Why Solr Search?
Solr is an open source project from the Apache Software Foundation that provides fast and efficient site search capabilities. Solr acts as a dedicated search server that operates independently from your site database. The key to Solr's efficiency is the index, a pre-built data catalog, which then can be efficiently referenced against your search terms and filters to quickly return your results. Via its REST-like API you put documents in it (called "indexing") via XML, JSON, CSV or binary over HTTP and you query it via HTTP GET and receive XML, JSON, CSV or binary results.
Understanding the Solr "Stack": Jetty, Tomcat, Solr & Core
One of the keys to effectively using Solr is understanding what we call the Solr stack. Technically, Solr is a Java servlet running on a Java servlet container. What does that mean? At the base level is an underlying Linux (or other) server, on top of that runs a Java container and on top of that runs Solr. There are many Java containers available, but the two most popular are Jetty and Tomcat.
Drupal Solr Integration Methods
Currently there are two main methods for integrating Solr with Drupal that we call the apache-solr and search-api methods. We will give a quick outline of the two options here and in a later post we'll examine and compare them in more detail. The key to the apache-solr method is the Apache Solr Search Integration module, which - as its name implies - provides a direct link between Drupal and Solr. This is probably the most popular integration method and is the one used by Drupal.org.
Solr Quick Start
If you haven't used Solr before, a very quick (and free!) way to explore the technology is to use Pantheon Drupal hosting and their built-in Solr integration. This strategy allows you to focus on using Solr and Drupal, without the need to deal with the full installation and configuration of the Solr search stack. Of the two integration methods, apache-solr is the easiest to use with Pantheon, as it has native support.
What's Next?
Now that you have a basic understanding of Solr and the Solr - Tomcat relationship, our next goal will be to install Tomcat and its web manager app on your Linux server. Then we will move on to Solr.
In our last post we mentioned the complexity of the Solr stack, so in this post we'll outline our strategy for cutting it down to size. Many a blog post has described how to integrate Drupal with Apache Solr and we have learned a lot from these posts.
However, when it comes to setting up the Solr service itself, many Drupalers seem to fight the Java servlet into submission rather than work with it in a smooth and seamless fashion. In the following we will describe how to optimally set up the Tomcat Java servlet container as a first step in building our Solr search solution.
Java Containers
Solr search is a Java servlet, and Tomcat and Jetty are two of the available options for Java servlet containers on which it can be deployed. A full comparison between them is beyond the scope of this article, but a simple description is that Tomcat is solid, well-documented and has an good web UI, while Jetty provides cutting-edge speed but leaves you a bit on your own as far as UI and documentation.
Notes
You will need to be familiar with Solr terminology. If you need a refresher, review our first post in this series.
Since we will be working at the command line level, installation locations and methods vary between Linux versions and distributions. This recipe is for CentOS 6.3, so we will be using rpm/yum as our package handlers.
Tomcat Server Install
First we will install and configure the Tomcat server. Most Linux distributions include Tomcat in their repositories, and it is often pre-installed, so you may not need to do any further installation at this point.
You can confirm installation by checking the default file location: /usr/share/tomcat6/
You can also check the service status, and start/stop with the following commands: service tomcat6 status service tomcat6 start service tomcat6 stop
If Tomcat is not installed: yum install tomcat6
Tomcat Manager Web-app Install
The next step is to install the Tomcat manager web-app. Usually this command will install the required packages:
yum install tomcat6-admin-webapps tomcat6-webapps tomcat6-docs-webapp
Web Manager
To use the web app manager, click on the "Tomcat Manager" link or navigate to address:8080/manager/html in your browser. You should see the Tomcat web app manager GUI, as shown to the left. This will be your main admin interface to set up Solr instances.
If you installed the docs package, you can click on the /docs link and see a great resource to help you in your Tomcat use.
Now that we've got Tomcat and it's web manager app running, it's on to Solr. Our next goal will be to use these tools to quickly and easily install and configure our Solr cores.
