Drupal 8 is approaching beta. Everybody is excited, some are displeased. Here are some of my concerns with Drupal 8 as a front end dev, and a note of encouragement as well. If you are a front dev, you are also involved in writing Drupal modules or parts of modules, that do theming and preprocessing of entities, and formatting of data for output. Some disturbing news and some good news for you are...
Wikipedia says, that "In software engineering, a project fork happens when developers take a copy of source code from one software package and start independent development on it, creating a distinct piece of software. The term often implies not merely a development branch, but a split in the developer community, a form of schism." Drupal has been forked.
“I’ve installed that Drupal 8. Yes, that went easy, but not much easier than Drupal 7. What’s that ado about Drupal 8 anyway? For two years you people have been building that CMS intensely - and what gives? A slightly better version of Drupal 7? Except that modules and themes don’t work with it, and there is a complete mess in the folder, I checked!” A Concerned User.
Dear Concerned User,
To explain it simply, let me compare. The first working locomotive was built in 1804. It ran on coal and was powered by steam. Now compare it to one of those luxurious trains of today. Now, If all you did were to enjoy a short ride in a coupe, you could say something like “The interior looked a bit more modern, but overall, just the same”. Still a locomotive up front. Still a car where you travel. But if you open the panel, you will see a ‘mess’ of wires. And what have they been doing all these 110 years!
- Adherence to Drupal design and coding standards.
- Making every newly built theme responsive.
- Keeping data, function, and presentation separate.
- Free sharing of professional knowledge, helping others to grow.
- Giving back to the community with encouragement, code, and support.
- Teachability, always learning.
- Aspiring to give maximum per available resources.
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.
Where is my page data?! Should you want to get the current page data, you will find, that Drupal stores 'page' data in a number of different ways.
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.
- Give reasons why and when you should use Drupal.
- Create a website with Drupal.
- Migrate a website to Drupal.
- Upgrade a Drupal 6 or 7 website to Drupal 8.
- Create a responsive theme for your Drupal site.
- Optimize, update, and do maintenance on a Drupal website.
- Rescue a crashed or infected Drupal website.
- Extend and edit Drupal functionality. Write and edit modules and themes.
- Estimate and architect a Drupal project.
- Consult and Educate Drupal users and teams.