One of the issues hotly dicussed in Drupal community, is the process of relating the dev server with the production. Imagine, you need to make some changes to the web site. You make a snapshot, and create a dev server. You make changes on a dev server, and then you want to move them to production. But, doh! On the production, you have some new users and content. What is the optimal way to implement the changes and merge the data back, keeping the data and config loses minimal?
SiteHound Drupal Distro has been updated to version 7.2. In this release, core and modules have been updated. A few modules have been removed, and a few more added.
SiteHound Drupal is a 'turnkey' distribution, that comes with a pre-package database import file, and is aimed at coming up with a most common set of modules and settings, that would unwrap a generic Drupal site easily.
With Drupal 8 coming, Drupal 6 will be deprecated. Many wary Drupal 6 site owners upgrading. Which steps should you follow?
With Drupal 8 becoming closer and closer, there has been a revival of interest of upgrading Drupal 6 sites to Drupal 7. The reason is simple - site owners don’t want to end up with an unsupported Drupal version. With the coming of Drupal 8, Drupal 6 version will be outdated and no longer supported. And, as a matter of fact, you can’t upgrade skipping versions, like Drupal 5 to 7, or 6 to 8 directly. This explains the resurgence of interest. Even with Drupal 8 not yet ready, many are willing to upgrade 6 to 7 not to lag hopelessly behind. And that is wise.
Here are a few suggestions, or, steps, that will help you upgrade Drupal 6 to 7.
Drupal 7.20 update changes the way image styles are handled. Now, a security token is added to an image style url, without which, it will not show. This makes
image_style_path() virtually useless, and call for usage of
$url = file_create_url(image_style_path('style', $image['field_image']['#items']['0']['uri']));
$url = image_style_url('style', $image['field_image']['#items']['0']['uri']);
As you most likely know, Drupal 8 will have not only PHPTemplate, but also Twig for it's templating engine. In the future, after support of Twig is deep and polished, PHPTemplate will most likely be deprecated. All developers, who have been theming for Drupal, have either already learned Twig, or are actively in the process of doing so. Here are the basics of applying Twig in Drupal context.
When writing this article, I especially kept in mind Twig team documentation, currently only available as a Google doc file. I am also thankful to FabianX for answering my questions in irc about current Twig template engine caching and to jenlampton for a valuable update. There is also a good Twig documentation to look at. Below are the patterns we used in PHPTemplate, and their Twig counterparts.
This blog post is not an advertisement. Moreover, I must admit, I do not happen to be a big fan or Oracle. Having said that, I want to thank them for NetBeans, which happens to be my favorite Drupal IDE. In this post, I am not doing an overview of the NetBeans IDE - an overview can be found on its web site. What I hope to do here, however, is to show the top 10 benefits that make NetBeans the tool of choice for my Drupal development.
The screenshots I made are from NetBeans 7.3 beta. Still, most of that functionality bas been around for all 7.x releases.
A few words about the Migrate module. Migrate module is a powerful tool that allows to move content from other CMS into Drupal. Migrate module allows you to map sources to Drupal destinations, and import them in a batch script. Currently, there is support for pages (nodes), categories and tags (taxonomy), media (images, audios and videos), addresses and geodata, and field collections. Some pieces of content work out of the box, some require additional modules (like migrate_extras), and some require patches (field collections). Migrate module is the most powerful of existing tools to handle complex sites and supports multiple source formats, most common being database and xml.
Now to the point. There are two basic ways to import complex data. One is an "onion-skin" migration, and another is a per-node type.
Some sites are quite complex. And some complex sites also have complex pages. A good way to group data on those pages is to use Field Collection module. Field Collection module utilizes Drupal 7's entity interface to store your field collection as an entity, rather than a field directly attached to your node. The benefit is obvious - you can manage little 'sub-nodes' for your node, like company's houses, or person's quotes, without having to create a whole new node for them. And for multi-value field groups, it's just a prodigy!
I have been searching for something like that for a long time - a service that is cheaper than Rackspace and Linode, and no traffic fee. It's high time, if you ask me - RAM costs coppers these days. Such servers are great for testing purposes, and sandboxes for clients. But such services usually have some cons as well. Here are some pros and cons of such hostings: