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.
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.