Planet Drupal

Subscribe to flux Planet Drupal
Drupal.org - aggregated feeds in category Planet Drupal
Mis à jour : il y a 56 min 47 sec

IXIS: Phpstorm & Drupal presentation from DrupalCamp NW 2013

lun, 27/01/2014 - 18:52

What's the point in using an IDE, especially a paid one, for PHP development when there are so many simpler, free tools?

In November 2013 I was lucky enough to be offered the chance to present a session at DrupalCamp NW on why it's time for Drupal developers to be using a proper IDE. The session used JetBrains PhpStorm as an example, but presented the case including other popular IDEs like Eclipse and NetBeans as well.

read more

Catégories: Elsewhere

Stanford Web Services Blog: Using Templates in a Custom Drupal Module

lun, 27/01/2014 - 18:06

In Drupal development land, the theme is what controls the final HTML, CSS, and Javascript that get delivered to the browser.

Sometimes, however, in developing a custom module, you want to provide a suggestion for an HTML framework, and not rely on the theme's default implementation of a given block of HTML.

You may ask yourself:

Can I use .tpl.php files in a Drupal module?

(And you may ask yourself, "How do I work this?", and you may ask yourself, "Where is that large automobile?")

Catégories: Elsewhere

Appnovation Technologies: 7 Great Responsive Websites

lun, 27/01/2014 - 17:12
With the internet being more accessible across many different devices these days, it’s no surprise that responsive websites have seen a rise in popularity. The following are 7 websites that take advantage of this new responsive approach. var switchTo5x = false;stLight.options({"publisher":"dr-75626d0b-d9b4-2fdb-6d29-1a20f61d683"});
Catégories: Elsewhere

Amazee Labs: Drupal Global Sprint Weekend Chapter in Switzerland: A big success!

lun, 27/01/2014 - 11:04

This weekend over 20 Drupalistas met at the Amazee Labs office to work together on Drupal 8, which was part of the Drupal Global Sprint Weekend. For some of the attendees it was the first time that they ever worked on Drupal Core! Thanks to the Drupal Ladder project they learned fast how core development works and actually could submit and review some patches after few hours.

Great minds of course also need great food and drinks:

To be able to do this we've found some great sponsors:

Thanks to all the attendees for spending their weekend to make Drupal 8 even better!

Catégories: Elsewhere

Web Omelette: How to theme forms and add custom classes wherever we want in Drupal 7

lun, 27/01/2014 - 09:00

In this article we are going to talk about theming forms. What exactly about it? Since theming forms can be a huge topic, I will stick to inserting your own custom classes wherever you can in a given form.

Have you ever needed a form element to have some special class you could target in your css? Or even yet, have you ever used a css framework like Bootstrap that tells you: ok, you need the form element to have class X in order to pick up these nice styles? Well, it can be a bit tricky to find exactly where you need to go, hook into what, override what theme function etc.

So in this tutorial I'm going to show you how to get your classes into 5 different form "places":

  • the <form> tag itself
  • the submit button
  • the element input itself
  • the form element wrapper <div>
  • the element label

Before we go further, this tutorial assumes you are already familiar with Drupal hooks and know how to implement one at the basic level. We are going to talk about form_alter hooks a lot which means that you can use more than one for the job: for instance hook_form_alter() or hook_form_FORM-ID_alter(), whichever best suits your need. You can read more about hooks in this section.

1. The form tag: <form>

If you want to add your class to a form tag you can do so inside of a form_alter hook. Once you are targeting the form(s) you want, you'll need to add some information to the $form array that gets passed through the hook:

$form['#attributes']['class'][] = 'your-class';

What happens here? The $form variable is a renderable array that also takes #attributes. There can be many types of attributes, one being class. This is as well an array so we make sure we add another item to the class array.

How do you know all this? When I debug the $form variable with the Devel module, I see no #attributes array in there at all...

WeIl, if you look at theme_form() itself - which is the Drupal core theme in charge of rendering forms - you'll notice that the #attributes array exists and gets transformed into HTML attributes by the drupal_attributes() core function. So, whatever you put in there will be transformed into attributes.

2. The form submit button

Adding a class to the submit button - the input element rather - is similar to adding one to the <form> tag but a bit tricker.

One thing you can do is override the entire theme_button() function in your theme and add your class there. Not really recommended if all you are doing is adding a class because you are copying all that code just to add a couple of more words. For more complex operations, you can do that.

Instead, you can use the same form_alter hook as before, and insert it there. We'll look at a couple of different forms to notice the difference between how you might approach this.

First of all, you can have a custom form that you declared yourself in the module. In this case, all you have to do is specify the #attributes when declaring the submit button. Something like this:

  $form['submit'] = array(
    '#type' => 'submit',
    '#value' => t('Submit'),
    '#attributes' => array(
      'class' => array(
        'your-custom-class' 
      ),
    ),
  );

If the form however is declared by another module and you don't - nor you should - want to hack it, you can use the form_alter hook of your choice. Considering that this is the form submit button declaration (so no classes defined in the #attributes array originally):

  $form['my_submit'] = array(
    '#type' => 'submit',
    '#value' => t('Next'),
  );

In the form alter you can add the following line:

$form['my_submit']['#attributes']['class'][] = 'my-custom-class';

Where my_submit is the machine name of the submit button. This will have the same effect.

Now let's take the Search block form as an example and say you want to add the class to the Search button. In your $form array, you'll notice an actions array. Looking this up in the Form API reference, you'll see that this is in fact a wrapper around one or multiple form buttons. So going inside that, we can find the submit button. So to add a class to that button, we do something like this:

$form['actions']['submit']['#attributes']['class'][] = 'your-custom-class';

So it's basically about finding out where the submit button is in the $form array. And since the actions form element is defined as a renderable array as well, you can add a class to that too:

$form['actions']['#attributes']['class'][] = 'your-custom-class';

So now the class is on the wrapper <div> of one or multiple buttons in the form.

3. Form elements

Similar to the form buttons, to add classes to form elements (the actual input, select, etc fields), you need to find them in the $form array of your form_alter hook and then add to the #attributes array. So to take the same Search block form, we can add our custom class like so:

$form['search_block_form']['#attributes']['class'][] = 'your-custom-class';

Easy peasy. And same as above, if you are the one declaring the form, you can just add the #attributes array with the class right there.

4. Form element wrapper <div>

When I say form element wrapper <div>, I mean the <div> surrounding the form element itself and the label. So how do we add our custom class to this? If you try with the form_alter hook as before, you won't be able because the form elements are rendered using their own custom theme implementation of theme_form_element(). And I've found that using the preprocess hook for that theme function does not pass the class to the wrapping <div> (as I thought it should).

So then what we can do is override the theme function itself - in our custom theme of course - and add the class there. Just copy the theme implementation from the API page into your theme template.php file and change its name from theme_form_element() to your_theme_name_form_element(). Then perform inside it any additional checks to make sure you only target the class name addition to the elements you want. The important thing then is to add the class into this array:

$attributes['class'] = array('form-item');

You can see below it all sorts of checks to add further classes that have some sort of meaning for the form element. You can insert yours in there somewhere.

5. Form element label

Adding your own class to the label is similar to what we did in the previous point: you have to override the right theme function. In this case it is theme_form_element_label().

Here though, you have to be careful. The $attributes['class'] array into which we've been putting classes is no longer an array but a simple string. So you need to avoid wiping out any other classes that Drupal might want to add to the label in various circumstances. So right before the function returns the output, add something like this:

$attributes['class'] .= ' my-custom-class';

This way you are appending to any class string that may come before. For some reason, the $attributes['class'] is not an array here. I don't know. Maybe you figured out why and there is a better way of doing this.

Conclusion

In this article we've seen what we need to do to add our own custom css classes to Drupal 7 forms. It's not a walk in the park but it's not so difficult either. One thing you can be sure of though is that it takes a lot of trial and error until you get everything right.

In Hooks | Theming | Drupal var switchTo5x = true;stLight.options({"publisher":"dr-8de6c3c4-3462-9715-caaf-ce2c161a50c"});
Catégories: Elsewhere

R.J.'s Blog: If you're on WAMP and using a CLI, here's how you automatically change PHP version in CLI when you change PHP version in WAMP

lun, 27/01/2014 - 05:12

Over the weekend, I updated my local Drupal development environment to use WAMP instead of XAMPP, simply because WAMP lets you switch between versions of PHP. Unfortunately WAMP doesn't set the PATH to PHP so in your CLI you need to update PATH manually either in your environment variables (Windowz) or in .bashrc (Cygwin/*nix). I searched for a way to automate this and couldn't find anything so I wrote this small snippet to do it automatically.

Tags: snippetsDrupal Planet
Catégories: Elsewhere

ardihundt.com: How we built a Drupal distribution for the Estonian Government, part 1 – what and why?

dim, 26/01/2014 - 16:22

In April 2013, Wunderkraut Estonia was tasked to build a website platform for the Government of Estonia. The platform would be used to run the Goverment Office website, all of the 11 main public sites for the Estonian Ministries, and the central “Government site” called valitsus.ee (government.ee in Estonian).

We took our weapon of choice, Drupal, and decided to develop the platform as a Drupal distribution. It did end up having most of the characteristics of a Drupal distribution – installation profile, theme, a bunch of modules; but it also has some differences – it’s not (yet) publicly available, and it ships as a ready-to-go website, with most of the settings already configured.

I have been running this project from the developer side since April and we have now arrived at a stage where we are due to launch first of the sites soon, so this is a good moment to take a look back. This is Part 1 of the series of posts that describe the lifespan of this project. Part 1 concentrates on the reasoning – what is this project about, and why is it a good idea to build a unified platform for 13 important public sector websites?

The preparations

Before we had even heard of this project, there was a period of time during 2012 and beginning of 2013 when the Government Office did a spetacular job of bringing together all the interested parties, who, as a group, worked out the main principles and functionality of the forthcoming platform. Some decisions were made:

  • the platform will be developed centrally, ie. decisions are made as a group and tasks delegated to a single dedicated development team. This means that at least until the deployment phase, noone can press his specific needs into development without finding common ground within the group first.
  • the platform will be named “Government Portal” and will have to make the 13 sites look as parts of a single big information source, with similar visual language, some shared and aggregated content, and similar structure in menus and page layouts. However, it’s not a single website, but a separate site for each, installed in different servers, running on independent CMS cores.
  • the look and feel of the platform will be obligatory to all group members, but the specific technical solution (ie. Drupal) will be recommended, not forced.
  • everyone will try to migrate to the new platform together, the most optimistic deadline being the beginning of 2014.

These were all important decisions that set the tone for the platform-to-be. Whats probably just as valuable, is that the group got to know each other and made those decisions together. Estonia is a small country, but even here each of the Ministries is a huge administrative machine, with its own traditions, missions, structure, powerful leaders and so on. To make the centralized approach work, you can’t just throw a finished end product out there and force everyone to use it. It has to be made together, and has to feel like it was made together.

The design layout for the frontpage

Another part of the preparations was working out the detailed functionality and designing all the layouts for it. This came to be about 20 pixel-perfect views, from frontpage to news views to content page templates, all the webdesign this project would need (actually ended up being about 80% of the design it needed), with the functionality drawn into it.

Now, coming from the world of agile and modular Drupal, I have to be critical about this part. A Drupal project should start from Drupal – prototyping, choosing the right modules, eliminating or redesigning that 5% of the functionality which takes 30% of the effort, etc. As it turned out, we did end up facing some functionality that did not really make sense on Drupal and didn’t allow for the best user experience. Luckily, client was flexible and understanding enough that this didn’t turn out to be a mayor problem.

Understandably, a public sector organization cannot choose a development partner at random to have them onboard from the start. A better scenario here would have been if as soon as the main concept was in place, a single procurement process would have been called to find a design partner and development partner together. And then the detailed functionality and user interface would have been defined together with both of them.

Too much of the website functionality is still drawn up in Photoshop these days, without a developer present.

Why?

Why would you do a project like that, and in such a way as the described preparations suggest? Different stakeholders have their own answers to this question, but the following reasons are the way I see it.

CMS engine segmentation before Government Portal on Drupal

Of course there is the efficiency – saving resources and money. Websites have a lifespan of 3-5 years, sometimes longer. All the 13 websites involved would need to be updated or remade at some point or other. Their look would decay, the technologies involved get hopelessly outdated, needs for new functionality arise etc.

5 of the sites were running on a CMS engine called Saurus, everyone else had a different backend. Even if those 5 wanted to share resources, they didn’t, because the sites were quite different.
Out of 13, maybe 4 could be updated, everyone else needed a remake, because the backend was discontinued or just too old.

So lets say a complete remake costs 100 apples, an update and a facelift  50. To get everyone done, one would need to spend 9×100 + 4×50 = 1100 apples. No sharing of resources.

Building the unified platform did cost about 300 apples, about 100 apples will be spent on various ways of deploying the sites. Thats 400 apples total.

This is, of course, a simplification, but the caliber is correct. And thats a lot of apples saved.

Another one is user experience. People of Estonia dont have to learn how to navigate 13 different public sites, which usually, based on good historical data, have the navigation scheme of a maze.  The news, search and contacts of the sites are now unified, helping to deliver the idea that the Government is actually a single large organization.

This also works on the product owner side – server administrators and content editors now have unified manuals, they can share knowledge and materials about how to run these sites. Training can be centralized.

Nobody gets left behind. Ministries with less resources or time are also helped or forced to the new platform. This contributes to a more modern, unified look across the whole government sector. Security is better. Updates are coordinated together, so that when a more technologically savvy Ministry goes for a new technology or functionality, others get part of it too.

I suppose there are some cons aswell – mainly that ministries lose some of their decision-making independence and making ministry-specific functionality is a bit tricky (more on that later). But in no way can I see that those cons would outweigh the pros.

So this is what the client wanted to build, and some of the reasons why make the effort. Next up, part 2 – highlights of the technical implementation.


Tagged: case study, Drupal 7, planet drupal, workflow
Catégories: Elsewhere

CTI Digital: Drupal 8 Print Module Port: The Plugin API (1/5)

dim, 26/01/2014 - 13:37

This post is part of a longer, multipart series as I begin to rearchitect the Print module for Drupal 8. The print module has been in the toolkit of many Drupal developers since its Drupal 4.6 release in 2005. Getting this module ready for a Drupal 8 release seemed like a great time to take stock, and look how this module could be built with all the great new systems in Drupal 8.

In this series of blog posts, I will try to steer clear of explaining the concepts that are covered brilliantly in many other Drupal blog posts, and instead focus on some of the currently less well documented areas of Drupal 8. There are areas that I will skim over, however I will ensure these are areas that have documentation in the Drupal or wider PHP community.

One of the first unexpected issues I faced is that “print” is a reserved keyword in PHP, which therefore means it can not be used within a namespace. Due to this, in this Drupal 8 port I have renamed the module hardcopy. I feel this name actually better reflects what the Print module does, with its PDF and ePub formats.

The current state of the code can be found in the hardcopy sandbox. I suggest you take a look at the code and follow along, as I will only being posting small snippets of the key areas of code in this post. Although the changes in Drupal 8 are starting to stabilise, everything in this post is subject to change when the final version is released.

One of my favourite advancements in Drupal 8, and something that I think contributed modules will use heavily is the Plugin API. Plugins should be used where you have some functionality that could be implemented in multiple different ways. The closest thing this could be related to in Drupal 7 are Ctools plugins, or *_info() hooks that provide metadata alongside related hooks that provide the functionality. For example, the block module invokes hook_block_info(), hook_block_settings_form() and hook_block_view(). In Drupal 8, the *_info() hook becomes an annotation on the plugin class, and the additional hooks become methods on that class. I believe this is a great improvement, as it keeps the related functions grouped with the metadata in a single class.

The new architecture for the hardcopy module relies heavily on the plugin system to allow additional formats (e.g. print, PDF, ePub) to be made available by any modules that implement the plugin.

The plugin API is actually a very simple system and rudimentary plugin types can be built very quickly and easily. They are also very flexible, which means that complex systems can be built from the API as well (for example, entities are defined as plugins). I think it is a credit to the developers that have worked on this API that it is able to cover all the levels of complexity that it does.

So, how do we define a plugin? The first thing that is required is a plugin manager service, which is a class that implements the PluginManagerInterface. In the hardcopy module we define the class HardcopyFormatPluginManager:

/** * @file * Contains \Drupal\hardcopy\HardcopyFormatPluginManager. */ namespace Drupal\hardcopy; use Drupal\Core\Config\ConfigFactory; use Drupal\Core\Plugin\DefaultPluginManager; /** * Manages hardcopy format plugins. */ class HardcopyFormatPluginManager extends DefaultPluginManager { }

A plugin manager is responsible for the following:

  • Discovery - Discovering the plugin definitions (the metadata associated with the plugin). Core provides a few different methods for discovering plugins including hook, YAML discovery and the most commonly used method: annotated class discovery. Annotated class discovery is used by defining a namespace subdirectory (the namespace without “Drupal\[module]”) and the fully qualified namespace of the annotation class (more on this below).
  • Creation - A class responsible for instantiating another class is referred to as a factory. The plugin API uses factories to instantiate instances of the plugin classes through a createInstance() method.
  • Mapping - Returns the preconfigured plugin instance appropriate for a particular runtime condition. This allows a plugin manager to return fully configured and instantiated plugins based upon an arbitrarily definable array of options (as opposed to passing a plugin ID as with the createInstance() method).

Generally the manager proxies any requests to methods on the manager to a specific class for each responsibility.

The great thing about the plugin API is that for 90% of use cases when using the DefaultPluginManager, only the __construct() method needs to be implemented, calling DefaultPluginManager::__construct() like so:

class HardcopyFormatPluginManager extends DefaultPluginManager { public function __construct(\Traversable $namespaces, ConfigFactory $config) { parent::__construct('Plugin/HardcopyFormat', $namespaces, 'Drupal\hardcopy\Annotation\HardcopyFormat'); } }

The hardcopy plugin manager additionally is responsible for retrieving configuration from the config system and passing this to the plugin during instantiation.

class HardcopyFormatPluginManager extends DefaultPluginManager { protected $config; public function __construct(\Traversable $namespaces, ConfigFactory $config) { $this->config = $config; parent::__construct('Plugin/HardcopyFormat', $namespaces, 'Drupal\hardcopy\Annotation\HardcopyFormat'); } public function createInstance($plugin_id, array $configuration = array()) { $configuration += (array) $this->config->get('hardcopy.format')->get($plugin_id); return parent::createInstance($plugin_id, $configuration); }

This plugin manager uses AnnotatedClassDiscovery for class discovery at the given namespace sub directory, using the given annotation. This annotation is defined in a class, which for plugin annotations should extend Plugin. This class defines the properties that make up this annotation type:

namespace Drupal\hardcopy\Annotation; use Drupal\Component\Annotation\Plugin; class HardcopyFormat extends Plugin { public $id; public $module; public $title; public $description = ''; }

We have now built the plugin manager, next we need to actually create some plugin classes themselves. Plugin classes are simply PHP classes which implement an interface for that plugin type. This interface ensures that the code calling the plugins knows how to interact with plugins of this type, and can interact in a uniform way with each. Here is an abbreviated version of HardcopyFormatInterface:

namespace Drupal\hardcopy\Plugin; use Drupal\Component\Plugin\ConfigurablePluginInterface; use Drupal\Core\Plugin\PluginFormInterface; interface HardcopyFormatInterface extends ConfigurablePluginInterface, PluginFormInterface { public function getLabel(); public function getDescription(); public function setContent(array $content); public function getResponse(); }

You will notice that the HardcopyFormatInterface also extends two other very useful interfaces: ConfigurablePluginInterface and PluginFormInterface. ConfigurablePluginInterface is the standard interface for plugins that use some kind of configuration to change their behaviour. It is often used alongside PluginFormInterface to allow the configuration to be changed from the user interface.

It is also very common to create a base class for plugins as most plugins of a given type will share some similarities. This is done with an abstract class as can be seen with the HardcopyFormatBase class:

namespace Drupal\hardcopy\Plugin; use Drupal\Core\Config\ConfigFactory; use Drupal\Core\Plugin\PluginBase; use Drupal\Core\Plugin\ContainerFactoryPluginInterface; use Drupal\hardcopy\HardcopyCssIncludeInterface; use Drupal\Core\Page\HtmlPage; use Drupal\hardcopy\LinkExtractor\LinkExtractorInterface; use Symfony\Component\DependencyInjection\ContainerInterface; use Symfony\Component\HttpFoundation\Response; abstract class HardcopyFormatBase extends PluginBase implements HardcopyFormatInterface, ContainerFactoryPluginInterface { protected $configFactory; protected $hardcopyCssInclude; protected $linkExtractor; public function __construct(array $configuration, $plugin_id, array $plugin_definition, ConfigFactory $config_factory, HardcopyCssIncludeInterface $hardcopy_css_include, LinkExtractorInterface $link_extractor) {} public static function create(ContainerInterface $container, array $configuration, $plugin_id, array $plugin_definition) {} public function getLabel() {} public function getDescription() {} public function defaultConfiguration() {} public function getConfiguration() {} public function setConfiguration(array $configuration) {} public function validateConfigurationForm(array &$form, array &$form_state) {} public function setContent(array $content) {} public function getResponse() {} protected function buildContent() {} protected function getOutput() {} }

This base class takes care of persisting any plugin configuration into the configuration system and providing some basic boilerplate for the hardcopy formats.

After putting the plugin manager, plugin interface and plugin base class together we can create as many plugins as may be required. They are all using a common interface so can be swapped in and out within any code making use of the plugins. Other modules can now quickly and consistently provide a hardcopy format by specifying a single class.

Hopefully this post demonstrates the simplicity and power that the plugin API offers contrib developers in Drupal 8. The plugin API should make modules better organised and more easily extensible in a uniform way. The next post in the series will build on this post and look one of the more advanced features of the plugin API: plugin derivatives.

 

About the Author

Matt Smith is a Drupal developer working both on frontend and backend development. Matt has been working with Drupal 8 since March 2013 contributing both to core and contrib. You can find Matt on Drupal.org as splatio or on Twitter as @splatio_.

Image courtesy of Adam Mulligan

Catégories: Elsewhere

Bruno De Bondt: D8 to D3: Using Drupal for data visualization

dim, 26/01/2014 - 00:31

One of the exciting features that’s on its way in Drupal 8 is the ability to use Drupal as a RESTful web service. This means that Drupal 8 core allows you to expose data to external applications in a number of standardized formats, and have those applications send data back to Drupal, for example to create, update, or delete content.

Catégories: Elsewhere

Bryan Braun: Template Picker Now Supports Entities

sam, 25/01/2014 - 20:29

Several months back, I released a module to drupal.org, called Template Picker. The idea was that it was too difficult to set up a workflow where content creators could pick how they want their content to be displayed. It either required heavy site building using tools like Panelizer (outside version control), or one-off custom development.

The way Template Picker works, you drop node templates into your theme for each way you'd like to display your content, and, as long as the file name matches the naming convention, it will be available as an option on the corresponding node-edit page. If that's too much Drupal lingo for you, you can see a video demo here.

But what I really wanted was to think outside the node and see if we could allow template picking for all sorts of entities. This way, a user could choose a style for their user profile, or a content admin could assign taxonomy term listings to predefined displays. It took some digging into the entity API, but I finally got it coded up and released over the Christmas holiday. I also depricated the old project on Drupal.org to fix a renaming issue (kind of a pain, but that's the price of learning).

If you think something like this could be useful for your next project, you can check it out on Drupal.org.

Catégories: Elsewhere

Acquia: Drupal 8 Wins: Avoiding the Dead Hook Blues, Part 3

sam, 25/01/2014 - 09:58

Drupal 8 Wins: Avoiding the Dead Hook Blues, Part 3 - Today we wrap up this mini series with Larry Garfield, Kris Vanderwater, and me answering the question "Do I need to learn Symfony to develop for Drupal 8?", getting the lowdown on plugins, and doing a wrap-up on the important points from our whole, 3-part conversation.

Catégories: Elsewhere

Drupal Association News: The Future of Drupal.org Development

sam, 25/01/2014 - 00:58

Hi everyone, if you don't know me I am Rudy Grigar (basic` on Freenode IRC). I have been a volunteer Drupal.org infrastructure maintainer since 2009. This month I started full time at the Drupal Association managing the Drupal.org infrastructure, which I am extremely excited about -- volunteer work has become my day job!

One of my first projects is to improve the development process for people interested in contributing to Drupal.org.

Catégories: Elsewhere

Théodore 'nod_' Biadala: Critical gaps in Drupal core JS

sam, 25/01/2014 - 00:10

Here are the main problems with Drupal javascript:

  1. no testing,
  2. no visible documentation.
Testing

This one is a maintainer nightmare. We refactor away and break eveything in the process. Thankfully we can't break the overlay anymore, but we have Views UI to break now! As well as various surprising components all over the place. Long story short, we need front-end testing.

There was a core conversation at the last DrupalCon prague about javascript testing where jessebeach, seutje and me talked about what was wrong and how we could get that going. The take away is that we need to find a framework to work with to set up our tests. If anyone has experience with a framework that might work with Drupal and the contrib space to write tests with, please let me know.

It really is the main pain point right now, let us know your thoughts in the javascript testing issue.

Documentation

Next big issue is documentation. It is currently non-existant for javascript. There are comments in the code, but it's just not fun to read and we can't see the whole picture. There have been many discussions and arguments about what and how to do. A few weeks ago I spend a whole sunday writing Drupal javascript with jsdoc and comming up with a JSDoc theme suitable for Drupal.

All that work ended up online at the Drupal JS API site. And it is looking pretty damn good. For example, you can see everything contained in the Drupal JS object. Ever wondered what was the list of all the Drupal.behaviors in core? Or what exactly are objects created from the Drupal.ProgressBar constructor? Of course there are lots of adjustments to make but it's a start.

Right now it's pretty much patch worthy. There is still a couple of issues that would be nice to get in for easier documentation: Split up contextual.toolbar.js and Split up ckeditor.admin.js. Once those are in I'll make the patch so we can use JSDoc to generate documentation while we wait for a Drupal API integration with JSDoc and finally get some javascript documentation on api.drupal.org.

There is still a long way to go for Drupal to become a javascript heaven. We can use all the help we can get to make that sooner rather than later.

Catégories: Elsewhere

Ben's SEO Blog: Installing Google Tag Manager and Universal Analytics on your Drupal Website

sam, 25/01/2014 - 00:07

Erik Wagner, Program Manager at Volacci, walks you through the steps of installing Google Tag Manager and Universal Analytics on your Drupal website.

Transcript:
Hey folks, this is Erik Wagner from Volacci, and today I’m going to be walking you through installing Google Tag Manager and Universal Analytics onto your Drupal website.

So to get started, I have actually loaded up Google Tag Manager. For those of you who don’t use Google tag manager yet, just go to https://www.google.com/tagmanager/. Once you’re here you are going to need to create a new account. I’m going to walk you through the steps here and just talk briefly about the concepts.

First, we need to create an account name. So, generally that’s going to be potentially your company or your brand name depending on the structure. I’m just going to name this Erik Wagner’s Website, okay. Then, you want to have a Container Name, and I’m going to call this Drupal Garden’s Website, because I actually have this installed or I'm going to install this on my Drupal Garden’s website here. I will capture my URL here and just copy and paste action, back in here paste that in, and change to HTTP. I’m going to set the time zone to Central. Quick review and everything looks good. Let’s create container. Excellent. So, now I have the code for our container. The container essentially will hold all of the tags. The container needs to be installed directly after the opening body tag on every single page of the website. So to do this, we’re gonna copy and paste this code, we're going to switch over to our Drupal Gardens website here. I am going to click on ‘Structure’ and theoretically it will load. Alright, we're going to click on ‘blocks’, we are going to create a new block, I'm going to ‘Add block’ and I am going to give this a description to call this Google Tag Manager Container. Now the code they gave us is HTML so I’m going to switch from WYSWYG into HTML here and paste that right in. I'm also going to make sure that this is selected on Full HTML, instead of Safe HTML. Although it may work with Safe HTML, I’m going to switch it up. And did that work? It did, okay.

Now I need to choose the location, now remember we want to have it right after that opening body tag. So I'm going to put it up as far as possible, the Preheader first, pretty early on. I'm going to have this on every single page. Now press 'Save'. Alright, your block is created. Now let's go double check to make sure everything worked out fine. Now I'm going to close that and go back to the home page here. Excellent, now code to be found, let's take a look at the page source here. Ah, here's our code, excellent, looks good. Cool, so our code looks good.

Back to Google Tag Manager, we need to get our Google Analytics code installed. We want to create a tag here. Alright, now that this has loaded the next step for us is actually to capture and create a new view within Google Analytics. So I'm going to switch tabs here. First step is we are actually going to create a new property, click on 'create new property.' We want to create a Universal Analytics property and call this Erik's Drupal Gardens Website. I am just going to drop my URL in here. We're going to come with an Industry category here and call this 'Computers and Electronics' and I'll go with Central time, which is where I am located. Press 'Get Tracking ID'. I am now brought to this page here, which has my tracking ID, which is what we're going to need next. I'm going to copy that tracking ID and then go over to Google Tag Manager again. I'm going to call this Universal Analytics, because we're going to install universal analytics, not this Google Analytics nonsense, though.

Paste this tracking ID in there. You'll notice we have the ability to choose a different Track Type, so it could be Page View event, Transaction, yadda yadda yadda. I'm choosing Page View. I'm not going to get into more settings or advanced settings, for the sake of time here press save. We have now created our first tag in our container.

However, before I get too far ahead of myself, I just realized I forgot something here. Let's go back into our tag here. You'll notice that it says here on the right hand side 'this tag will not be fired because it has no firing rules.' Alright, let's click this firing rules. Actually, there has already a default rule here. This tag will fire on every single page and that's what we want to do here. So, I will just click that 'All pages' and I'll press Save. And then I will save that here. Alright now let's go and let's create a new version here. Okay, so we created version number three. I am actually going to name this something a little bit more interesting and more descriptive as well “Universal Analytics Installed and Firing Rules Setup” and press 'save'. Let me press 'Publish.' And now our container tag and new tag has been pushed to the website.

Now that that is done, let's switch over to Google Analytics here, and we should be able to see, although I probably need to load. Alright now the website has loaded, I'm just going to click to a separate page here so we can see some browsing activity. Let's go back, let's take a look. Ah, look at that, one active visitor on the website. They're on the about us page. Looks like our Google Analytics installation is up and running.

Well, that's it folks! If you have any questions or is there anything else I can do to help, please let me know. My email address is erik.wagner@volacci.com. Thanks!

A walk-through of the steps necessary to install these useful tools.google tag manager, universal analytics, Planet Drupal
Catégories: Elsewhere

Lin Clark: Video: DELETE requests and Cookie Authentication in Drupal 8's REST

ven, 24/01/2014 - 23:00

You can remove content from your site using the HTTP method DELETE. Since you don't want just anyone deleting content from your site, you'll want to keep permission limited to trusted users. In this video, I'll show you how to run DELETE requests and...

Catégories: Elsewhere

Drupal Association News: Drupal Association Board Meeting: January 15, 2014

ven, 24/01/2014 - 22:46

Last week we held our first board meeting of the new year. We were really pleased to share a new staff report format featuring the KPIs and other metrics that we will be tracking in 2014 to document the impact of our work. Because board meetings are held in the middle of the month, our method going forward will be to report numbers against the plan for the month prior.

Catégories: Elsewhere

Drupal core announcements: This (two) weeks in Drupal Core

ven, 24/01/2014 - 21:56
What's new with Drupal 8?

Last week, in lieue of a This week in Drupal Core, xjm and wechick compiled a phenomenal This YEAR in Drupal Core, so here's a catch up of the last two weeks.

Happy 13th birthday, Drupal!

Drupal 1.0.0 was released on January 15th, 2001. Many software projects from that era are long forgotten by now. That we have stayed relevant and gotten stronger through 13 years of fast and chaotic evolution of the internet is, in my opinion, very impressive. Here's some highlights from the birthday:

Drupal 8 Alpha 8

For module developers who've already begun porting their modules to Drupal 8, there's a shiny new alpha8 for you to play with as of yesterday. These alphas are provided to give you something more stable to work off of than having to chase HEAD every day. If you do choose to chase HEAD though, be prepared for more volatility. For example, Move definition of menu links to hook_menu_link_defaults(), decouple key name from path, and make 'parent' explicit was a very important patch committed immediately following the alpha8 release, but requires extensive follow up changes that we are trying to resolve between now and the next alpha.

Where's Drupal 8 at in terms of release?

Last week, we fixed 7 critical issues and 11 major issues, and opened 6 criticals and 20 majors. That puts us overall at 136 release-blocking critical issues and 497 major issues.

3 beta-blocking issues were fixed last week. There are still 60 of 107 beta blockers that must be resolved and 38 change records that must be written before we can release a Drupal 8 beta.

Where can I help? Top criticals to hit this week

Each week, we check with core maintainers and contributors for the "extra critical" criticals that are blocking other work. These issues are often tough problems with a long history. If you're familiar with the problem space of one of these issues and have the time to dig in, help drive it forward by reviewing, improving, and testing its patch, and by making sure the issue's summary is up to date and any API changes are documented.

More ways to help

The Drupal 8 "meta meta", compiled by vijaycs85, is a great place to start if you want to dig your teeth into a technical problem but aren't sure where to start. Or if coding isn't your thing, there are plenty of issues tagged as Needs change notification. Writing these is a great way to keep abreast of recent changes - see more on change records to get started.

As always, if you're new to contributing to core, check out Core contribution mentoring hours. Twice per week, you can log into IRC and helpful Drupal core mentors will get you set up with answers to any of your questions, plus provide some useful issues to work on.

Notable Commits

The best of git log --after=2014-01-09 --pretty=oneline (and before alpha8) (65 commits in total):

  • #2144919 by yched, fago, effulgentsia, amateescu, tstoeckler, chx, larowlan, swentel: Allow widgets and formatters for base fields to be configured in Field UI.
  • #2020393 by dawehner, bdone, pcambra, oadaeh: Convert "Recent content" block to a View.
  • #1649780 by effulgentsia, jibran, Wim Leers, nod_, hefox, joelpittet, kaare, BarisW, sun, rbayliss, Cottser, fubhy: Remove first/last/odd/even classes in favor of CSS3 pseudo selectors.
  • #1862202 by plach, Berdir, katbailey, ParisLiakos, alexpott, chx, sun, larowlan, Gábor Hojtsy, cosmicdreams, vijaycs85, YesCT, penyaskito, andypost, Albert Volkman, joelpitett: Objectify the language system.
  • #2173719 by dawehner, tim.plunkett: Remove the fork of doctrine/common.
  • #2168333 by tim.plunkett, EclipseGc, yched, fago: Ensure custom EntityType controllers can be provided by modules.
  • #1892320 by damiankloip, linclark: Add deserialize for JSON/AJAX - now you can interact with all of Drupal's REST API via plain JSON as well as via HAL.
  • #2160735 by Cottser, aspilicious: Add hook_theme_suggestions_alter() - that completes item #1 from the API changes list of [meta] Theme system architecture changes.

You can also always check the Change records for Drupal core for the full list of Drupal 8 API changes from Drupal 7.

Drupal 8 Around the Interwebs

Blog posts about Drupal 8 and how much it's going to rock your face.

Drupal 8 in "Real Life"

Also, although DrupalCon Prague is well behind us, if you're feeling nostalgiac or if you weren't there but want to know what the vibe was like, you can watch the Drupalcon Face to Face video posted by John Desalvo.

Whew! That's a wrap!

Do you follow Drupal Planet with devotion, or keep a close eye on the Drupal event calendar, or git pull origin 8.x every morning without fail before your coffee? We're looking for more contributors to help compile these posts. You could either take a few hours once every six weeks or so to put together a whole post, or help with one section more regularly. Contact xjm if you'd like to help communicate all the interesting happenings in Drupal 8!

Catégories: Elsewhere

Drupal Commerce: Greenville Grok Drupal Meet Up

ven, 24/01/2014 - 20:36

Howdy pals. My name is Chris and I work at Commerce Guys as the R&D Engineering Manager. Did you know that three of the Commerce Guys live in Greenville, SC? Recently we were talking about the Drupal community and how we could rally a group to meet up in April during Greenville Grok.

I know what you're thinking: Not another conference! While this isn't a Drupal camp, sometimes it's good to get outside the community and be the expert at what you know and talk to experts in what they know. Grok is a small web/tech conference in Greenville, SC that I help run on the side. At Grok we talk, listen, eat and drink with world class people asking a ton of hard questions, digging into great issues, and making headway on some decent real-world solutions. This conference really is what you put into it. Bring your ideas, problems, and input and you will have a blast, learn some things, and make amazing pals. If you are hoping the answers to life will be handed to you I think you have the wrong conference.

Read More

Catégories: Elsewhere

Mediacurrent: Meet David Younker

ven, 24/01/2014 - 17:34

1.   So David, what's your role at Mediacurrent, both internally and client-related?

As a Drupal Developer, I develop features for new and existing sites, manage deployments, participate in code reviews with team members, and perform client trainings.

I also work with other developers to contribute to new and existing Drupal modules, and give knowledge shares on new technology or sharing things learned at a recent conference.

2.  We're so glad to have you! Give us an idea of what professional path brought you here.

Catégories: Elsewhere

Pages