Planet Drupal

Syndicate content
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 12 min 57 sec ago

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

Tue, 01/04/2014 - 4: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 News

Mediacurrent: A Guide to Drupal Terminology

Tue, 01/04/2014 - 3: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 News

Blink Reaction: Being the Best Drupal Shop on the Planet

Tue, 01/04/2014 - 3: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 News

Blink Reaction: Drupal for the .NET programmer

Tue, 01/04/2014 - 3: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 News

Drupal Association News: Thank You, Supporting Partners!

Tue, 01/04/2014 - 1: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 News

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

Tue, 01/04/2014 - 1: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 News

DesignHammer: Testing Drupal data migrations with CasperJS

Tue, 01/04/2014 - 1: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 News

drunomics: Drupal Dev Days Szeged wrap-up

Tue, 01/04/2014 - 12:26am

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

Categories: Drupal News

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

Mon, 31/03/2014 - 6:10pm

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 News

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

Mon, 31/03/2014 - 4: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 News

Drupal core announcements: No Drupal core release on Wednesday, April 2

Mon, 31/03/2014 - 2:50pm

The monthly Drupal core bug fix release window is scheduled for this Wednesday. The last Drupal 7 bug fix release was three months ago, but there haven't been enough changes to the development version since then to warrant a new release. As a result, there won't be a Drupal 7 bug fix release this month. A bug fix release next month (in May) is likely.

Upcoming release windows include:

  • Wednesday, April 16 (security release window)
  • Wednesday, May 7 (bug fix release window)

For more information on Drupal core release windows, see the documentation on release timing and security releases, and the discussion that led to this policy being implemented.

Categories: Drupal News

flink: Gorgeous Google map canvasses for your Drupal site: just Copy & Paste

Mon, 31/03/2014 - 7:48am

I love maps. I love gardens too.

Not keen on gardening, though.

So while the Google Maps API allows you to create beautiful map styles, that doesn’t mean I enjoy spending hours or days doing that. Plus I don’t have the artistic prowess.

But the contributors of Snazzy Maps do.

Read more and drool...

File under:  Planet Drupal
Categories: Drupal News

OhTheHugeManatee: Drupal Dev Days Szeged, or: Why You Should Attend Every Camp You Can

Sun, 30/03/2014 - 1:27am

Today is the last day of Drupal Dev Days in Szeged, Hungary, and I’ve never been more full of the “Drupal spirit!”

One of Drupal’s greatest strengths is the closness of its’ community, how friendly and accepting they can be. Drupalcons are highlight events for many, not because of the learning as much as because of the social track: the chance to see old friends and make new ones. Even more important is the chance to experience in person this incredibly friendly community. I always loved the cons because you could approach really anybody, say “hi”, and ask them about their work with the platform. Seriously, anybody. From a new user to Dries himself.

That’s become harder and harder as Drupal has grown more popular. In a convention of more than 3,000 people, you lose that feeling of being able to approach anybody. Instead, people silo into groups. In a best case it’s a group that shares an interest in a sub-system (Rules junkies, Panels proselytizers, Features fans…), but in most cases it’s because of shared connections outside the community. You end up hanging out with the same people you knew before the con. Of course you can still have fun, but that sense of community is lost.

One of the best parts of Drupal Dev Days Szeged was the way they encouraged people to mix, cross pollinate, and discuss. In a conference of 350 people I felt like I spoke to almost all of them. I could approach even the famous visitors and talk to them like a normal human being. I borrowed VGA adaptors from Gabor Hojtsy and Wim Leers, and neither of them batted an eye at it.

This kind of experience is so great, so positive and validating, that I recommend Drupal Camps for everyone. The ticket price is cheap, the location is always nearby, and the culture is fantastic. The sessions are every bit as good as most DrupalCon sessions (many of us use the Camps as a way to practice before the Con), and you will make great new friends.

Tl;DR: Drupal Dev Days in Szeged was fantastic. If you’ve never been to a Drupal Camp event, get your butt onto drupical.com and find your nearest one today!

Categories: Drupal News

Drupal Association News: Drupal Training: The Self-Taught Solution

Sat, 29/03/2014 - 5:27am

In this blog series, we’re taking a little time to spotlight just a few of the many, many Drupal training options available today. With an emphasis on people in the community advocating Drupal and putting together programs to expand the community, we’re spotlighting a few of the dozens-- if not hundreds-- of fantastic training options out there.

Categories: Drupal News

Forum One: A closer look at Entity Forms

Sat, 29/03/2014 - 4:27am

Almost every project we work on requires a method for capturing user information. In most cases we have a Contact form and in more general purposes the client requires additional forms for various reasons. In the past our go to for creating forms was the Webforms module. As requirements have changed, so has the need for a web form solution that is exportable using Features.

In this series I will be walking you through an introduction to Entity Forms, including installing, configuring and creating an Entity Form from scratch. Later we will explore Exporting Entity Forms using Features and then follow up with integrating Entity Forms with Panels.

Why not Webforms?

The drawback of using the Webform module ((https://drupal.org/project/webform) is that there is no consistent port of this module to Drupal 8 and from an exportable solution you cannot use Features and Webform to easily migrate changes into code an on to a development or staging environment as Webforms are node based. While you could choose to use Webform Share (https://drupal.org/project/webform_share) to import and export Webform changes, this is not ideal for our development lfe cycle.

Advantages of using Entity Forms

This is where Entity Forms is starting to look like a more viable solution. Entity Forms if you are not familiar with them, enables the end user or developer to create front-end forms in a similar manner as Webforms. However, Entity Forms provide what I think is a more rich feature set.

  • Ability to attach any Drupal Field to the Forms

  • Ability to use most field based and entity aware modules.

  • You can download submitted data to XML and / or CSV data files using View Data Export.

  • Rules based form submission notifications. Allows for complex notifications logic.

  • Rules based form access control. Allows for complex access logic.

  • Use Views to create to an administrative listing of each Entityform type Submissions for fine grain control.

The Entity form module takes advantage of the Entity API, allowing for use of the Field UI and some consistency with how we are already developing. Oh, and they are exportable as well using Features, which make placing them in code advantageous for continuous integration.

 

Installing Entity Forms

Like most modules, Entity Forms can be found at Drupal.org and downloaded by browsing to (https://drupal.org/project/entityform). Feel free to choose the download version that is right for you. For sake of demonstration I will be using the 7.x-2.0-beta2 version along with Drush to download the module into my “sites/all/modules/contrib” folder.

Note: If you do not have a “contrib” folder under your “modules” directory, you can create one or simply place the downloaded module directly into the “modules” folder.

 

One we have the module downloaded we need to navigate to “admin/modules” and enable the “Entityforms” module. Keep in mind that Entityforms has dependencies of “Entity API, Views, Chaos tools, Field UI, Field and Field SQL storage”, so you will also need to download and install the dependencies. If you want to have Forms send email to users you will also need to download and install the Rules module and finally since Entityforms uses the Fields UI, you may want to download and configure the “Email Field” module.

Configuring Entity Forms

Entityforms work much like that of a Content type in that you can configure them by creating an entityform type and add fields to it. If we navigate to “admin/structure/entityform_types” we can begin to create a new Entityform as shown in the following image.

 

 

Creating an Entity Form

For demonstration purposes we will create a new “Contact” form. To begin creating an Entityform click on “Add entityform type” and fill out the fields as shown in the following image.

 

 

 

 

  1. Name - Human readable name of our form.

  2. Redirect path - Relative path that a user is redirected to upon submission..

  3. Intro form instructions - User instructions you want to display.

 

We now are presented with multiple settings on how our new form will function. We will need to complete some or all of these sections so let’s review those now.

Access settings

Access settings control who can submit a form, whether a form is open for submissions and whether a form can be resubmitted by the same user. The controls contain the following fields and you can view the defaults I have selected in the following image.

 

 

 

 

  1. Form status - Can users submit the form. Value allows for form submission to be open or closed.

  2. Roles - Roles that can submit our new form.

  3. Resubmit action - Action to take if logged in user has already submitted our form.

Submission page settings

Submission settings control the page title and response that a user will see upon successfully submitting a form. The controls contain the following fields and you can view the defaults I have selected in the following image.

 

 

 

 

  1. Preview Page - Boolean value to show a preview page to user when they are about to submit a form.

  2. Submission page title - Page title displayed after form is submitted.

  3. Submission reply - The text that will be displayed to user upon form submission.

  4. Show submission information - Boolean value to show user submission form data.

 

Submission views

Submission views allow you to specify the view used to display submission reports to both the admin and end user. The controls contain the following fields and you can view the defaults I have selected in the following image.

 

 

 

 

  1. View for submission reports - Select the view that should be used for Submission reports. These views are customizable.

  2. View for current user’s submissions - Select the view that should be used to show users their previous submissions.

 

Draft settings

Draft settings control whether a form can have multiple drafts prior to actually submitting it. The controls contain the following fields and you can view the defaults I have selected in the following image.

 

 

 

 

  1. Draftable - Boolean value to specify whether a user can save a draft of the form.

  2. Override drat button text - Text to use for draft save button.

  3. Draft save text - Text to be displayed to user when the form is saved as a draft.

 

Menu settings

Menu settings control whether a form has a link on a specific menu for user to navigate to. The controls contain the following fields and you can view the defaults I have selected in the following image.

 

 

 

 

  1. Provide a menu link - Boolean value to provide a menu link for form.

  2. Menu link title - Title of menu link that will be displayed.

  3. Description - Alt or Title attribute that will display when hovering over menu link.

  4. Parent item - Menu that men link will belong to.

  5. Weight - Specified order of menu link within menu.

 

URL path settings

URL path settings control the url alias for both submitting the form and the confirmation page once a form has been submitted. The controls contain the following fields and you can view the defaults I have selected in the following image.

 

 

 

 

  1. Submit URL alias - URL where user can find the form.

  2. Confirm URL alias - URL user is taken to upon submitting the form. This will display a page with the settings from the “Submission page settings”.

 

Form overrides

Form overrides allows you to change some of the default values of the form including the submit button text, confirmation text and titles. The controls contain the following fields and you can view the defaults I have selected in the following image.

 

 

 

 

  1. Submit Button Text – Text to use for submit button

  2. Submission confirmation Text – Text to use for Submission Confirmation

  3. Your Submissions Text – Text to use for “Your Submissions” page

  4. Form Disallow Resubmit Text – Text to use for “You already submitted this form”

  5. Submission Delete Text –Text to use for “Delete Confirmation”

  6. Submission View Title – Text to use for page title of submission view

 

Now that we have configured our Contact form we need to add fields to it for the user to be able to input information that will be submitted. Since Entityforms utilizes the Fields UI, we should be pretty comfortable in adding fields.

Managing fields

To manage fields we need to simply navigate to the “Manage Fields” tab and add our fields as shown in the following image.

 

 

 

For our particular Contact form we added the following fields.

  1. Name - Text field with the default settings.

  2. Email - Email field with the default settings.

  3. Subject - Text field with the default settings.

  4. Message - Long text field with the default settings.

 

Finally let’s preview what our form look like by browsing to the Contact link we provided earlier in our settings as shown in the following image.

 

 

 

 

Summary


We covered a lot of information in a short period of time. Including how to download and install the Entityforms module and the dependencies it has to configure properly. We looked at configuring a new Entityform with proper settings and finished off by adding the fields through the Fields UI and previewing our new form. Next time we will look at configuring the Rules module for allowing Entityforms to notify uses by emailing them that a form has been submitted.

 

 

 

 

Almost every project we work on requires a method for capturing user information. In most cases we have a Contact form and in more general purposes the client requires additional forms for various reasons. In the past our go to for creating forms was the Webforms module. As requirements have changed, so has the need for a web form solution that is exportable using Features. In this series we will be walking taking a closer look at Entityforms.

 

 

Categories: Drupal News

Amazee Labs: Our Drupal Developer Days Szeged Slides

Sat, 29/03/2014 - 2:45am
Overwriting code in Drupal

On Thursday Vasi (vasi1186) highlighted methods how to overwrite the default behaviour of Drupal's core and some of the well known contributed modules.

Manage and Deploy your sites with Drush

In his session Bastian (dasrecht) explained how to setup Drush to work with remote sites and how we use it in our daily business. 

Get ready for full translated sites with Entity Translation

Drupal 8 will require only only one module for translation: Entity Translation. Michael (Schnitzel) presented our biggest learning with Drupal 7's version of the module and how by using it the transition to Drupal 8 will be significantly easier.

Pro tip: For the full experience of his presentation's animated cat content gif goodness, which Slideshare doesn't support, you can download his Keynote slides here.

Stay in touch – join our newsletter!  

 

Categories: Drupal News

Darren Mothersele: Drupal Theme Generator Demo

Fri, 28/03/2014 - 11:00am

I've been playing with the idea of automatically generating Drupal themes from static HTML/CSS/JS using annotations in the HTML markup. I put together a basic proof-of-concept of a tool to generate a Drupal theme, ctools layout and style plugins, and view modes and templates.

Last night at the Drupal Show and Tell event in London I gave a live demo of the theme generator in action. The event was recorded, so will be online eventually, but for now I've recorded this demo as a couple of attendees suggested this would give a better idea of the detail that couldn't be seen on the screen during the live demo.

My interest in this area came about through wanting to bring design into the development workflow of an agile project, and move away from the 'throw it over the fence' mentality in design deliverables. You can read more about how this came about in my previous blog post Death of the Themer.

Assembly, not Deconstruction

Traditionally implementation of a design was done via a process of deconstruction from a PSD into flat HTML and CSS, and then another process of deconstruction in CMS implementation of the design. You can't design a responsive site in Photoshop so luckily this is changing. PSDs were horrible to work with as amends take far too long, and while Photoshop may be good to quickly mock up style ideas, pages designed in Photoshop tend rely too much on intuition, implications about how things would work, and tend to come with an implied "you get the idea".

Atomic Design

As I've mentioned in earlier posts, I'm excited about the emerging trend towards atomic design (see Brad Frost) as it brings a more 'development' style process into design. Treating the process as that of designing a system of re-usable components, rather than just designing pages.

This moves implementation of a design from a process of deconstruction, to a process of assembly, so brings the world of dev and design closer together. Either bringing design into the development workflow, or bringing development processes into design (depending on which way around you look at it).

With an atomic approach to design, and with something like SMACSS for modular CSS, the process of converting to a Drupal theme can be automated. Because the markup/styles are 'componentised' we can annotate the source code to document the conversion process and then use automated tools to manage the process.

Demo

Here's a demo of the proof-of-concept:

https://player.vimeo.com/video/90315757 Next...

You can download/fork the code from the GitHub Hyde repo. You'll need to patch the QueryPath module as it needs the latest version of the QueryPath library and the QP module doesn't include the right files to make this work by default.

A lot of work needs to be done. This is very rough proof-of-concept code, but I think this shows the concept can work, and worthy of further development.

Some feedback from last night included:

  • Generate an actual theme. At the moment the theme is just an object stored in the DB/cache, but I had planned for this to be a ctools exportable. An earlier version I started working on generated actual theme files, perhaps it would be better to switch back to this approach?
  • How to handle logic in template files? Shouldn't this be handled in pre-process?
  • Stub code generation for pre-process functions
  • Adding extra custom fields for display only? The example given was a date field that was displayed twice on page, once for date stored in field and once for time stored in same field.

Drop me a line if you've got any other ideas, or want to get involved, or want to help fund building this properly! :)

Categories: Drupal News

Drupal governance announcements: Proposed Conflict Resolution Policy

Fri, 28/03/2014 - 8:40am

For some time we've had a bit of unfinished business around the Drupal Code of Conduct around how we manage and respond to conflict.

The Community Working Group has drafted a policy and is now looking for community feedback over the next 2 weeks. Please check out the draft in the drupal-cwg issue queue.

https://drupal.org/node/2227717

Categories: Drupal News

Drupal Association News: An Updated Look for the Drupal Association

Fri, 28/03/2014 - 7:54am

You may have noticed over the last several weeks we have begun rolling out updated badges for memberships and our partner programs. (You can see the full line-up of new badges here.)

We’re sprucing up our membership badges as part of an iterative effort to update some of the visual branding for the Association - more on that in a moment.

Categories: Drupal News

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer