Skip to Content

Planet Drupal

Syndicate content
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 3 days 22 hours ago

Open Source Training: A Sub-theme of a Drupal Sub-theme

1 April 2014 - 8:42am

The best way to design and modify your Drupal site is with overrides.

If you're not sure how overrides work, read our introduction to Drupal overrides.

One of the most powerful ways to override Drupal is with sub-themes and sometimes even with sub-sub-themes. These allow you to safely override any themes you download from Drupal.org.

Categories: Drupal

Drupal Association News: Defining Our Roles in the Drupal Community

1 April 2014 - 8:41am
We need a better way to work together

This is a dense topic, and this post is very long. So, let me provide a short summary here before you all tl;dr me, which would be deserved. The long and short of it is that Association staff and other community members have to figure out a better way of working together.

Categories: Drupal

Kris Vanderwater: On pursuing new things.

1 April 2014 - 6:58am

It is with a mixture of bitter and sweet that I am officially announcing that I'm leaving Commerce Guys for a new position elsewhere. I have really enjoyed the last 3 (nearly 4) years at Commerce Guys. They have been an amazing place to grow both as a person and as a programmer. During my time there I've had the opportunity to work on numerous big projects and interesting technical challenges. Commerce Guys funded me to work full time on Drupal 8 as an initiative owner for months on end, and without that investment of time, I personally wouldn't have grown so much, nor would I have been able to contribute to Drupal 8 to the same degree. I cannot stress how great of an experience working there has been for me, and I'm thankful to all the people there who made that possible and made my own time there so enjoyable. I look forward to seeing them do great things.

As for my future, I am actually moving to Acquia. An interesting job position opened up there that will allow me to be the interface between Drupal's developer community and Acquia. This is especially interesting to me because it makes me part of the feedback loop that is intended to help Acquia understand what portions of Drupal developer experience are in need of improvement. In this role, I'll work in whatever capacity I have at my disposal to help mitigate these issues and improve Drupal from a developer experience perspective. In addition to this I'll function in the same capacity for various Acquia product offerings, and I find that very exciting as well.

In truth most developers want to escape client work, and despite what you might think, that is impossible if you want to continue development. We can only strive for better clients, whether that is literally a higher quality client, or whether you manage to make yourself your primary client, we always have clients. In many ways I think this move makes YOU my client, yes you. The whole of the Drupal community will be my singular client. I’ll interact with you at different levels, we’ll talk personally, we’ll talk corporately, we’ll interact at camps and cons. I’ll try a few things and I’ll probably fail at a few things, but I took this position because Drupal is really important, and I want to be a part of crafting its future in whatever capacity I might have available to me. This job opens that up in ways I hadn’t considered before, and that’s very exciting. Technically speaking, this is a marketing position, and I know that’s weird for a developer, but this is no mistake, I’ll just be marketing DX improvements, and gathering information about where DX is lackluster so that we can craft a better solution, together. I look forward to this role and this work, and I hope you do as well.

Kris “EclipseGc” Vanderwater

Categories: Drupal

Drupalize.Me: Questionnaire Confirms: Designers Aren't Clear How To Help Drupal 8

1 April 2014 - 5:15am

As mentioned in my previous blog post "Catching the Community Train" Lisa, Bojhan and myself will be working on a website to better facilitate the process of designers contributing to Drupal. Following my last blog post we sent out a questionnaire to current and previous contributors in order to gain some valuable insights that will help us move forward. In this blog post I will analyze the answers we received and share what they mean to me and how they will be instrumental in our success of helping designers more easily get involved in Drupal.

Categories: Drupal

Drupal Easy: DrupalEasy Podcast 126: Where is Yugoslavia? (Théodore Biadala)

1 April 2014 - 3:40am
Download Podcast 126

Théodore Biadala (nod_), technical consultant with Acquia, and one of the Drupal 8 JavaScript maintainers, joins Andrew, Ted, and Mike to talk about the current (and future) state of JavaScript in Drupal core. Also discussed is Acquia’s new certification program, DrupalCon Latin America, and picks of the week that you’re not going to want to miss!

read more

Categories: Drupal

Wunderkraut blog: Taking the Acquia Certified Drupal Developer exam

1 April 2014 - 1:59am

In the very recent period this new thing popped up in the Drupal community that has everybody talking: the Acquia certification for Drupal developers. I'm writing this article minutes after actually taking this exam to share with you my impressions.

Why did I take the certification?

One of the things that prompted me to it was Angie "webchick" Byron's article about her experience taking the exam. It sounded interesting but also relevant to me as a Drupal developer. It announced an exam that could determine my value in this field.

A second aspect I'd like to mention is the fact that I work with Drupal but do not have an IT background. I am, what you call, a self-taught. Therefore the idea of having a certificate to prove my worth sounded good to me. So I took the opportunity and the exam that came with it.

Impressions

There are 2 ways you can take the exam: on site (physically) or online. To deliver its online exam, Acquia collaborates with Web Assessor, a secured testing environment.

I chose the second option which meant I had to install some software onto my computer and go through a substantial verification process. This included biometric baseline recording of the face and keystrokes in order to be able to authenticate when I start taking the test. I know, advanced stuff.

To a certain extent I understand the need for this highly secure exam taking environment that prevents people from cheating. However, Web Assessor could have made things easier for people to take these necessary steps. What do I mean by this?

For one, there are contradictory instructions on the site. In one place it says you don't need an external webcam and microphone and in another it says you are not allowed with the built in computer ones. So which one is it? In the end, I did it with my internal ones, so it is possible.

I finally got through the hurdles of installing the software, closing all my apps, creating the biometric baseline, etc to arrive to the booking of the exam. It was very flexible and I could book a time in the same day: that's what I did. I liked that very much. However, I had to wonder about the timezone, just select an hour and hope it corresponded to my timezone. There was no indication as to which one was being used. Luckily, it was the right one so there was no problem. Therefore, in case you are wondering, it will be the timezone you are in when you book.

The whole process of preparing for the exam with Web Assessor took about an hour. Not so much the settings themselves but reading and understanding what I have to do, what I can do and what I can't do.

But what about the test?

I'm going to go right out and say it: the test was hard. But I was expecting it to be hard because otherwise it's pointless. It had only multiple choice questions with only one correct choice most of the time. For the others, you have checkboxes instead of radios.

Timewise, I had 90 minutes which for me was enough. I even got a chance to review some questions to change the answers and submitted the exam with some minutes to spare. And I appreciated the option to flag questions I'd like to review later.

I can't really go into what questions I got or how they were formulated but they were well balanced with regards to the domains covered by the exam.

One problem I had though was with the code formatting. Some of the questions contained code snippets that were a bit tricky to read / understand. I believe a bit more effort can be dedicated to making them more readable - especially when they are in the available choices. I recommend therefore, if possible, putting all code snippets in code blocks and properly spacing them.

I submitted the test and immediately got my result. Passed. It gave me a very good feeling and made me happy to take it. One thing I was disappointed with was the fact that I couldn't see which questions I got wrong. This may be just me but I was left a victim to obsession over which were those battleground questions that made me think so much. But anywho, we move on and develop some more Drupal sites.

Congrats Acquia on this great new initiative!

Categories: Drupal

Amazee Labs: Amazee Labs - first agency to relaunch its website on Drupal 8

1 April 2014 - 12:00am

Today we are proud to announce that amazeelabs.com, our main website, has been re-launched ON DRUPAL 8.

After countless hours of emotional debate we came to the conclusion that we required a bold move to communicate our position as Switzerland’s #1 Drupal agency. To put this straight we actually are the proud owners of the first company web presence on Drupal 8 - on the entire web!

We strongly believe that a website isn't the final destination after all, it’s just the medium for the creation and promotion of a site’s content.

Gregory Gerhardt, Managing Director and Founder of Amazee Labs, commented: ”For too long our brilliant design has fought an uphill battle against the evil work of copycats. Our new website design shall rest uncopied - simple, authentic, close to its roots."

We hope you like our new face.

Categories: Drupal

Metal Toad: Pond Life - Pt.1

31 March 2014 - 2:09pm
Assimilate and Elaborate!


Categories: Drupal

Web Wash: Using Environment Indicator in Drupal 7

31 March 2014 - 12:46pm

Every Drupal site builder will at some point experience the dread of accidentally making configuration changes on production thinking it's their local site. This sort of thing can easily happen when you have 20 tabs opened and forget which site you're currently browsing.

Luckily there's a module you can use to indicate which environment (local, staging, production, etc.) you're currently viewing and it's called Environment Indicator.

The module helps to separate each environment by displaying a coloured indicator. The indicator itself is fully configurable. You can change its colour, position and text.

In this tutorial, you'll learn how to create an indicator in two ways: through the module's UI and with some code in settings.php.

Categories: Drupal

Drupal core announcements: Drupal 8 alpha 11 on Apr. 23

31 March 2014 - 12:19pm

The next alpha for Drupal 8 will be alpha 11! Here is the schedule for the alpha release.

Apr. 20-22, 2014 Only critical and major patches committed Apr. 23, 2014 Drupal 8.0-alpha10 released. Emergency commits only. Apr. 24-27, 2014 Disruptive patch window
Categories: Drupal

Drupal Commerce: Quick and Dirty Price & Stock Updater with Editable Views

31 March 2014 - 10:01am

Have you ever wanted to be able to have a single page where you could update pricing and/or stock for your entire store? Look no further! Today you'll learn how to create a price and/or stock updater in 5 minutes with Views and the Editable Views module. It isn't perfect, but it can save you a bunch of time!

Read More

Categories: Drupal

Mediacurrent: A Guide to Drupal Terminology

31 March 2014 - 9:51am

Getting started in Drupal can be daunting.  The first hurdle most people encounter is the terminology Drupal uses.  Some terms may be completely unfamiliar while others have a different meaning depending on the context.  The faster you learn to understand and speak Drupaleze, the easier it will be to communicate with other Drupal developers more effectively. To that end, here are a list of terms commonly used in the Drupal world:

Categories: Drupal

Blink Reaction: Being the Best Drupal Shop on the Planet

31 March 2014 - 9:47am

Preview of: A Complete Guide to Being the Best Drupal Shop on the Planet  - A session delivered by Kenny Silanskas at NYC Camp 2014

Categories: Drupal

Blink Reaction: Drupal for the .NET programmer

31 March 2014 - 9:46am

For years Drupal has been known for its powerful content management capabilities. Many large companies leverage Drupal for its rich features and vibrant community of contributors. More recently Drupal has caught the eyes of many developers as a viable framework for web application development. Enterprises shifting from a .NET development environment may find some of Drupal, PHP’s, and the LAMP stack in general a bit challenging to fully adopt.

Categories: Drupal

Drupal Association News: Thank You, Supporting Partners!

31 March 2014 - 7:51am

We’ve been sharing lots of big news at the Drupal Association lately. From hiring a CTO to lead the Drupal.org Tech Team, to implementing a content delivery network (CDN) for parts of Drupal.org, we’re making big, exciting improvements at the Association — and they wouldn’t be possible without our Supporting Partners.

Categories: Drupal

Commerce Guys: 5 Ways to Prepare Your eCommerce Site for Globalization

31 March 2014 - 7:28am
Thanks for Calvin Scharffs from our Marketplace partner Lingotek for sharing some industry insight. Globalization is all about planning. One forgotten detail can mean major headaches down the road—you end up replicating content across languages, and hit a “garbage in, garbage out” situation that could take a long time to clean up. Here are five ways to prepare for smart, tidy global growth.   Set the right foundation. Be sure to launch your globalization efforts on an adaptable content management system that is designed with extensibility in mind. Drupal is the perfect starting place, with its community-generated add-ons that accommodate the versatility crucial in international eCommerce.
  Go multilingual. Your biggest markets are most likely non-English speaking. To maximize your online presence, offer at least two language options. Find out if any of your systems aren’t equipped with multilingual capabilities, so you can address the challenge before you transition.
  Accommodate many currencies. Check to see if your currencies are converting correctly. Make sure that the currency and date displays always reflect a user’s local currency, so that they’ll have the simplest possible path to purchasing from you.  
  Be agile. Time is of the essence when it comes to penetrating potential international markets. Strategize your globalization with an eye for efficiency. Adopt the tools that will help you stay fast, including translation management, which enables companies to capture, reuse and recycle their online content—providing the best efficiency for current, consistent content for all customers, everywhere.
  Localize. When you translate content, make sure that you also localize—use the appearance and colloquialisms that your audience is familiar with. Otherwise, you risk alienating your customers with cultural faux pas, such as using a color that signifies bad luck, or translating a phrase that works in English, but means something unbecoming in your target language.
  By addressing these five aspects of global-ready eCommerce, you’ll jump on the fast lane to effective globalization. 






Categories: Drupal

DesignHammer: Testing Drupal data migrations with CasperJS

31 March 2014 - 7:02am

At DesignHammer, we've used the Migrate module on many projects, with a variety of use cases: Drupal-to-Drupal migrations; importing content from CSVs or XML to populate a new site build; importing XML from an eBook as nodes for an online version of the book content, and so on. It's a flexible, stable module that provides a great API for getting content from point A to point B.

Categories: Drupal

drunomics: Drupal Dev Days Szeged wrap-up

31 March 2014 - 6:26am

Last week was a packed experience of sprinting, presenting & exchanging at Drupal Developers Days Szeged 2014. Here are our favorite picks.

Categories: Drupal

Web Omelette: 10 things you should be doing on your Drupal site

31 March 2014 - 12:10am

This article comes as a continuation to the previous one in which I exemplified 5 things you should not do on or with your Drupal site. Today, however, I'll double up, take a more positive approach and go with 10 things you definitely should be doing. So let's begin.

Turn on caching and aggregation on production

When you develop locally you'll most likely disable css/js aggregation and turn off the caches. This makes it easier to quickly see changes as you make them and allows for a more efficient development. However, you have to make sure that these are turned back on when you move to the live site.

Drupal comes with a few powerful performance related settings that greatly improve the speed of your site. Page caching and compression for anonymous users is one of them. CSS/JS aggregation is another. And there are a bunch of contrib modules that enhance performance and I recommend you also look into those.

Disable development modules and functionality on production

If the previous point was about performance, this one is about security. There are various things you'll use locally while you develop or debug your Drupal site. The Devel module is something you'll probably enable and the error reporting will most likely be turned on so you can see what's going on.

This is all good and well but make sure that when you push your changes to the production site, these get turned off. Keeping the Devel module enabled on a live site is a big security risk. And although it constitutes security by obscurity, disabling the printing of errors to the screen is also important. Not to mention user friendly.

So either you create a checklist of things to do or automate these processes however you want. Drush will be a very good friend with this.

Use Drush for shell tasks like updating and installing modules

Speaking of Drush, any respectable Drupal developer will know how to use and will use Drush for one thing or another. It is a very helpful tool to run tasks related to Drupal from the command line. A Drupal shell basically.

I'm not even going to enumerate all the cool things you can do with it but I will refer you to a couple of articles I wrote before on how you can begin with Drush and some of the basic things you can use it for.

Keep regular backups of your production environment

The best backups are the ones you don't ever need. That being said, you'll need to keep regular backups of your site and server in order to revert if the worst should happen. There are many tools you can use for this (both manual and automated) but I'm not going to go into that right now. I will however share a story to scare you straight into opening your MySQL interface of choice and taking a database dump.

A while ago, I hosted a site for someone on a shared server from a random hosting company. One day I notice the site is down and in about 24 hours (of the site being down) I get an email. Someone hacked into their datacenter and deleted everything (both live servers and backup server). Apparently both were kept in the same place and their access was solely protected by the act of sending an email to the datacenter from the hosting company's email address asking for access...

The resolution was the following: no more data, ever, retrieved. Nobody got anything back. Luckily, I had backups and so should you. The moral of the story is obvious I think.

Find a good balance between contrib and custom

In the previous article I strongly advised against using too many contrib modules. I mean if the site is huge and needs them, it's fine. As long as they are accompanied with performance related enhancements to compensate for the load.

In this point I would like to stress the importance of finding a good balance between using contrib modules vs your own custom code. The rule of thumb is to use contrib modules as much as you can. This means do not write custom code that is already present in a module. This is because there are multiple people looking at that module and can spot problems, make updates and you'll be also better off.

That being said, you also have to be careful of (1) what modules you use and (2) what problem they solve. First of all, the module can be of bad quality or not performant, so you'll need to investigate a bit (how many people use it, how does the issue queue looks like, etc). Second of all, it can be an overkill. If you need a tiny piece of functionality offered by a module that does a bunch of other stuff you don't need, it's maybe time to think about whether or not you can implement that yourself. It's a judgement call depending on the case.

If you don't expect users to create accounts, disable this functionality

One of the things I kept forgetting and paid the price later was to disable the right for anonymous users to create user accounts on the site. By default on a fresh Drupal install, anonymous users can create accounts and you as an admin need to approve them. The problem is that if you forget, you can wake up in 6 months with a huge spam user list that you need to take care of.

This piece of advice concerns those who create new websites that don't need people creating accounts of course. If you require users to be able to create them themselves, make sure you implement some anti-spam techniques like Captcha, Mollom or Honeypot.

Employ Drupal coding and security standards

One of the important things that beginner Drupal developers need to learn is how to respect the Drupal coding and security standards in place.

The coding standards represent a particular way of writing, formatting and structuring code. Aside from syntactical rules, you also have readability rules and implementation rules (where and how should I use this function or hook).

The security standards represent the rules the respect of which ensures that you will write secure code. This means using helper functions and techniques that actually make Drupal a pretty secure system.

So make sure you got these down before attempting to write enterprise code for Drupal production sites.

Keep your code in Git

Using version control is a must with any web application. In this day and age you cannot write code without keeping it in some sort of versioning system like Git, Mercurial, or SVN. The Drupal community adopted Git and it's awesome. It's also one of the most popular ones out there.

If you want to develop Drupal modules, themes or contribute to existing ones or even core, you can't get around using Git. So make sure you start using it for all your projects if you don't already.

You can also use Git to deploy your code between environments. Keeping a central repository from which you can pull provides a fast and easy way to deploy code. This is of course if you're not already using some automated tool like Jenkins (that also integrates with Git by the way).

Update core regularly

It's recommended that you update your site when there are updates issued by the core maintainers, especially when they are security updates. Yes, it can take some time to perform these updates, but it's worth it.

Why? There is no getting around the fact that security updates need to be done. Once they are public, the vulnerabilities are as well. So if you haven't deleted the CHANGELOG.TXT file from your Drupal root (which you can do), potential attackers can find out the version of Drupal you are running. And the risk of exploiting those vulnerabilities increases. This is not to say that deleting the CHANGELOG.TXT file is enough and you shouldn't update.

Additionally, if you leave it for later, you'll end up having to do a big update across many version numbers which makes it much more difficult. It'll take much more time to do and the risk of breaking some functionality will increase as well.

So take the time regularly to do the updates, look at what is affected by them and test your site to make sure it won't break (locally!). If it does, fix the custom code (or update contrib) that no longer functions due to this. The problems should however be minimal with incremental updates.

Keep the modules in the right folders

There is a best practice in Drupal regarding the way you organise the modules on your site. We know that they must be kept in the sites/all/ folder but we can better organise them inside that as well.

Contrib modules need to go in a folder called contrib/ and custom modules in a folder custom/. Trust me, when you will have plenty of modules (of both types), finding them will be much easier.

Additionally, if you use the Features module, you should put all your features into a features/ folder. And if you patch any of the contrib modules, it's best if you move them from contrib/ to a folder called patched/. This way you have an overview of which modules you need to pay extra attention to when doing updates. After moving the module make sure you run a registry rebuild to update Drupal as well that the location has changed. With Drush this is easy: drush rr.

Conclusion

There you have them: 10 things I recommend you do on your Drupal site. Again, there are more of course, but here are 10 of my most important ones. By the way, do you know that saying: do as I say not as I do? :)

In Drupal var switchTo5x = true;stLight.options({"publisher":"dr-8de6c3c4-3462-9715-caaf-ce2c161a50c"});
Categories: Drupal

netsperience 2.x: Connect Drupal to Multiple Remote Databases via SSH Tunnel

30 March 2014 - 10:42pm

I'm working on a site that stores data in separate mysql databases, and updates them frequently from Salesforce via nodejs scripts run through CouchDB.

The extra mysql dbs are 16+ GB and it's not practical nor necessary to keep them locally since I only want to read the latest data in local development.

Wouldn't it be cool if the local Drupal site can read from the remote database servers?

In some cases you can just use the connection you find in the remote site's settings.php:

'otherdb' => 'mysqli://username:password@hostname/dbname'

(note: it's a Drupal 6 site so that's why you don't see an array - I will give a Drupal 7 example below)

However, there's often a twist: I must create a SSH tunnel to connect to this particular db server, based on information clearly presented by Engine Yard.

First, you need to have configured and installed SSH keys on your local and remote machines.

Then fire up your terminal and create the SSH tunnel to forward the remote mysql port to a local port. Keep this connection alive as long as you need to connect to the remote database.

ssh -L [local port]:[database host]:[remote port] [ssh-username]@[remote host] IMPORTANT: use a different port for your tunnel [local port] than the one you normally use for mysql; for example, if you connect to mysql locally on the default port 3306, use 3307 (or any other unused port) for your tunnel. You should use the correct [remote port] which is typically 3306, and you can see if it is different by looking at settings.php in the remote site. ssh -L 3307:[database host]:3306 [ssh-username]@[remote host] Then you can test your connection (in a different terminal instance): mysql -u[dbuser] -p -P 3307 -h 127.0.0.1 Here is the connection in settings.php for Drupal 6: 'otherdb' => 'mysqli://username:password@127.0.0.1:3307/dbname' What's cool is that you can mix local and remote databases. For example, I want to use a local copy of the Drupal database, which is smaller and easier to sync, and read the data from the second (and third, in my case) remote dbs. $db_url = array(  'default' => 'mysqli://local-dbuser:password@localhost/local-dbname',  'otherdb' => 'mysqli://username:password@127.0.0.1:3307/dbname',  'otherdb2' => 'mysqli://username:password@127.0.0.1:3307/dbname2'); You can also connect Drupal to the default remote database, but it makes sense to use a local instance for development. And in Drupal 7: $databases['default']['default'] = array(  'driver' => 'mysql',  'database' => 'local-dbname',  'username' => 'local-dbuser',  'password' => 'password',  'host' => 'localhost',  'prefix' => '',);$databases['otherdb']['default'] = array(  'driver' => 'mysql',  'database' => 'dbname',  'username' => 'username',  'password' => 'password',  'host' => '127.0.0.1',  'port' => '3307',  'prefix' => '',); 

WARNING: 

If the db user for the remote db has all privileges, your application may alter the remote database. Therefore, you should create a "read-only" user for the remote database which will prevent you from altering it. THINK 
Categories: Drupal


about seo