Agrégateur de flux

Recently I had to create a custom field for a project I am working on. The field was not difficult to implement, it only had to store two values in the database, but I didn't found a sample tutorial for that so I want to share my experience with you.

If you take a look at the Examples module, you can find a sample field that stores one value in the database, but this sample will show you how to store more data. In fact this field will store two values retrieved from The Internet Chuck Norris Database. One numeric value that represents the joke identificatior and a text value that holds the joke itself, for example:

Chuck Norris once ordered a Big Mac at Burger King, and got one.

First step to create our custom field is to create the database structure to store the data. This can be done using the hook_field_schema in the .install file of your module.

/** * Implements hook_field_schema(). */ function field_chuck_field_schema($field) { $columns = array( 'id' => array( 'type' => 'int', 'unsigned' => TRUE, 'not null' => FALSE ), 'joke' => array( 'type' => 'varchar', 'length' => 2048, 'not null' => FALSE ), ); return array( 'columns' => $columns, ); }

You can create as many columns as you want to store your data. Just take into account the supported types.

Next step is to create a .module file to hold the field specifications starting with the hook_field_info:

/** * Implements hook_field_info(). * Provides the description of the field. */ function field_chuck_field_info() { return array( 'field_chuck' => array( 'label' => t('Chuck Norris Joke'), 'description' => t('Creates a field for Chuck Norris jokes.'), 'default_widget' => 'field_chuck', 'default_formatter' => 'chuck_norris_joke', ), ); }

In this hook we create our field name "field_chuck" and the default widget and formatter names. Then we describe the field widget with hook_field_widget_info telling Drupal the name of the widget, a label for it and for what field types it's designed:

/** * Implements hook_field_widget_info(). * Expose Field API widget types. */ function field_chuck_field_widget_info() { return array( 'field_chuck' => array( 'label' => t('Chuck Norris Joke'), 'field types' => array('field_chuck'), ), ); }

Also we must tell Drupal the field widget structure with hook_field_widget_form:

/** * Implements hook_field_widget_form(). * Return the form for a single field widget. */ function field_chuck_field_widget_form(&$form, &$form_state, $field, $instance, $langcode, $items, $delta, $element) { $element += array( '#type' => $instance['widget']['type'], '#default_value' => isset($items[$delta]) ? $items[$delta] : '', ); return $element; }

This hook implementation is different than the one in the Examples module but I guess this is more customizable because we can use hook_element_info to implement our own Form API element types with their values:

/** * Implements hook_element_info(). * Declare the field Form API element types and specify their default values. * @see field_chuck_field_process(). */ function field_chuck_element_info() { $elements = array(); $elements['field_chuck'] = array( '#input' => TRUE, '#process' => array('field_chuck_field_process'), ); return $elements; }

Now we can create the field Form API elements in the #process callback function:

function field_chuck_field_process($element, $form_state, $complete_form) { $element['submit'] = array( '#type' => 'markup', '#markup' => t('Go!'), '#prefix' => '<div id="field-chuck-submit"><h2>', '#suffix' => '</h2></div>', '#attached' => array( 'js' => array(drupal_get_path('module', 'field_chuck') . '/field_chuck.js'), ), ); $element['joke'] = array( '#type' => 'textfield', '#title' => t('Chuck Norris Joke'), '#default_value' => isset($element['#value']['joke']) ? $element['#value']['joke'] : '', '#prefix' => '<div id="field-chuck-joke">', '#suffix' => '</div>', '#maxlength' => 2048, '#size' => 100, ); $element['id'] = array( '#type' => 'textfield', '#title' => t('Joke ID'), '#default_value' => isset($element['#value']['id']) ? $element['#value']['id'] : '', '#prefix' => '<div id="field-chuck-id">', '#suffix' => '</div>', '#size' => 4, ); // To prevent an extra required indicator, disable the required flag on the // base element since all the sub-fields are already required if desired. $element['#required'] = FALSE; return $element; }  The final steps are:

• Create the implementation of hook_field_load if we want to process the data before loading it in the field widget.
• Don't forget that the implementation of hook_field_validate and hook_field_is_empty are required for a correct field validation.
• Also we can implement hook_field_presave if we want to alter the data before storing it in the database.
• Create the custom field formatter using hook_field_formater_info and hook_field_formatter_view as I explained in a previous post.

The full example code can be downloaded from my Drupal sandbox and includes the javascript to fetch the Chuck Norris jokes, so I hope you will enjoy it :)

Tags: drupal 7fieldwidgetformatterDrupal Planet

Today my main machine was down for about 8 hours. Oops.

That meant when I got home, after a long and dull train journey, I received a bunch of mails from various hosts each saying:

• Failed to fetch slaughter policies from rsync://www.steve.org.uk/slaughter

Slaughter is my sysadmin utility which pulls policies/recipies from a central location and applies them to the local host.

Slaughter has a bunch of different transports, which are the means by which policies and files are transferred from the remote "central host" to the local machine. Since git is supported I've now switched my policies to be fetched from the master github repository.

This means:

• All my servers need git installed. Which was already the case.
• I can run one less service on my main box.
• We now have a contest: Is my box more reliable than github?

In other news I've fettled with lumail a bit this week, but I'm basically doing nothing until I've pondered my way out of the hole I've dug myself into.

Like mutt lumail has the notion of "limiting" the display of things:

• Show all maildirs.
• Show all maildirs with new mail in them.
• Show all maildirs that match a pattern.
• Show all messages in the currently selected folder(s)
  • More than one folder may be selected :)
• Shall all unread messages in the currently selected folder(s).

Unfortunately the latter has caused an annoying, and anticipated, failure case. If you open a folder and cause it to only show unread messages all looks good. Until you read a message. At which point it is no longer allowed to be displayed, so it disappears. Since you were reading a message the next one is opened instead. WHich then becomes marked as read, and no longer should be displayed, because we've said "show me new/unread-only messages please".

The net result is if you show only unread messages and make the mistake of reading one .. you quickly cycle through reading all of them, and are left with an empty display. As each message in turn is opened, read, and marked as non-new.

There are solutions, one of which I documented on the issue. But this has a bad side-effect that message navigation is suddenly complicated in ways that are annoying.

For the moment I'm mulling the problem over and I will only make trivial cleanup changes until I've got my head back in the game and a good solution that won't cause me more pain.

Jack, my co-themer here at Advomatic, and I will be doing a series of articles about how we use SASS and Compass on our projects. There are plenty of articles out there on what it is and how to get started, so we wanted to dig a little deeper, and share a few tips and ideas.

Credit: mccun934

Today I'll talk about Modernizr, which is a javascript library that will check to see if your browser supports HTML5 and CSS3 features. We use it on every project now to make sure we aren't serving unsupported stuff to browsers that can't handle it. One thing Modernizr does is add classes to your HTML tag, like "cssgradients" or "no-cssgradients," or "textshadow" or "no-textshadow" as the case may be. Combined with SASS, this can be a very simple way to limit your CSS3 work.

Here's an example of how we now apply any of our css3 theming, using the way SASS allows you to check for parent classes, and the nice CSS3 includes of Compass.

h1.title {  // A double border, for browsers that support box shadows; single border for those that don't.
  border-bottom: 1px solid #c3c3bf;
  .boxshadow & {
    @include box-shadow($white 0 1px);
  }
}

Here's a slightly more elaborate example:

#footer {
  background-color #114163: // a baseline background color
  .lt-ie10 & { // dirty proprietary filter for IE9 and below
    filter: progid:DXImageTransform.Microsoft.gradient(GradientType=0,startColorstr='#2074b1', endColorstr='#114163');
  }
  .cssgradients & { // gradient for CSS3-supporting browsers
    @include background-image(linear-gradient(#2074b1, #114163));
  }
}

By the way, that handy ".lt-ie10" class on the html tag is standard now in Drupal's Zen base theme. It's very handy. While we try to avoid it, we also will add in classes for .mac, .pc, .chrome, .firefox and .safari, if we have some extremely browser-specific problems, which is rare. If you are curious, here's the javascript we use to add that information to the html tag.

Drupal.behaviors.targetBrowsersOS = {
  attach: function (context, settings) {
    // Check to see which operating system we're using.
    if (navigator.appVersion.indexOf("Mac")!=-1) {
      $('html').addClass('mac');
    }
    else {
      $('html').addClass('pc');
    }
    // Check to see if the browser is Safari and doublecheck that it is not Chrome.
    if (navigator.userAgent.indexOf('Chrome') > -1) {
      $('html').addClass('chrome');
    }
    if (navigator.userAgent.indexOf('Safari') != -1 && navigator.userAgent.indexOf('Chrome') == -1) {
      $('html').addClass('safari');
    }
    if (navigator.userAgent.indexOf('Firefox') > -1) {
      $('html').addClass('firefox');
    }
    if (navigator.userAgent.indexOf('MSIE') > -1) {
      $('html').addClass('ie');
    }
  }
}

So, as you can imagine, this gives you the ability to customize what css various browsers are served, and leaner, cleaner experience all around. Stay tuned for more SASS/Compass tips and tricks!

Last night I presented at the SFDUG Meetup (you can find my slides on the Phase2 slideshare). There were some great questions and Drupal theming discussion at the end of my presentation. Here are a few of those questions that came up, as well as the answers:

Q: How does Omega compare to a simpler Drupal theme in terms of performance?

A: There are trade-offs as with anything. Phase2 has used Omega for a number of large site projects including Georgia.gov and Fema.gov.  There are scaling concerns with any complexity in a system but it is by no means a road block.

Q:  Is Delta only used for Omega?

A: Delta was made by the same people who wrote Omega, so this will be your best compatibility, but it is compatible with other themes as well.

Q:  Can we use custom grid systems with Omega 3?

A: Yes, you can. You have to write some custom code to handle compatibility.  There is documentation you can refer to if you interested in trying it out.

 

To experience the full session experience, check out this recording of my session:

Omega from Download to Layout from Phase2 on Vimeo.

Thanks to the San Francisco Drupal Users Group for inviting me to talk!

 

I had the surprise of seeing this at the bottom of the confirmation email when I ordered something online:

Bei Fragen zu deiner Bestellung antworte bitte auf diese E-Mail.

In translation: “If you have questions about your order, please reply to this e-mail”. Wow. Someone out there still reads email. The address pointed helpfully to info@… instead of the usual no-reply@…. I am really surprised.

Open Source software, namely Drupal, can be leveraged to accommodate the technology needs of numerous corporations across a vast spectrum of private and public sectors. The constant collaboration of the Drupal community gives users the freedom to rapidly deploy new innovations in a way that a closed proprietary system does not allow. Here at Achieve we are constantly trying to increase Drupal adoption by developing new solutions to help new stakeholders in new arenas.

Personal blog tags: DrupalCMSHealthcare

Well, I put out crappy predictions for Google IO related to Android.  So here are my crappy predictions for Appengine:

• PHP runtime support - 95% (I would not have guessed this 3 weeks ago)
• Memory increase for at least python - 50%
• Instance hour price cut - 40%
• Premium memcache pricing - 10%
• Python 3 support - 5%

 It should be obvious, but I really have no clue what Appengine related things could be announced.  If PHP is not there then the Appengine team deserves some applause for their slight of hand.  The rest is mostly my wishlist :)

Calendar system requires a very tiny core patch to fully work, The patch was already proposed to core by a fellow developer, so i rewrote it to meet core requirements and set it to needs review (Thanks to Gaelan and wuinfo for helping in completing the patch). The good thing is that the patch is not only for Calendar Systems it's a generic patch that introduces a new hook to make it possible for third-party modules to alter format_date function. If we can get it into core it might even be possible to back port it to Drupal 7

You can read more about the history of calendar system module and even what a calendar system is

 

read more

Views offers a neat grouping mechanism that allows you to list content with matching criteria under said criterion. For example, if you had 3 press releases from 2011 and 2 from 2010, you could display them like this:

2011

• Press Release #5 (April 1, 2011)
• Press Release #4 (March 31, 2011)
• Press Release #3 (January 25, 2011)

2010

• Press Release #2 (December 3, 2010)
• Press Release #1 (June 1, 2010)

To do this, you create a view with three fields:

• Title (linked to node)
• Date (in Month Day, Year format)
• Date (in Year format; exclude this from display) -- if you want to save yourself some confusion later, open this field, go to the "More" section, and enter "Year (grouping header)" to make it clear why this field is there even though it's not shown

Next to your view format (unformatted list, HTML list, etc.), click Settings, and then pick your second date field as the grouping header under "Grouping field Nr.1". Check off "Use rendered output to group rows." Save.

I've done this quite a few times, but on my current site, I found that even when I told it to group by year, it was coming out like this:

2011

• Press Release #5 (April 1, 2011)

2011

• Press Release #4 (March 31, 2011)

2011

• Press Release #3 (January 25, 2011)

2010

• Press Release #2 (December 3, 2010)

2010

• Press Release #1 (June 1, 2010)

This makes a little sense, since the dates all technically are different, but it's supposed to be grouping by the rendered output, which is just 2011 and 2010. I dug around and found that even though it looked like just "2011" to the naked eye, the code was actually <span class="date date-display-year" property="dc:date" datatype="xsd:dateTime" content="2011-04-01T05:00:00-05:00">2011</span>. The month, day, and even time values were still being stored even though they weren't visible.

To fix this, I opened the year field, went to the Rewrite Results section, and checked "Strip HTML tags." This gets rid of the code that differentiates the values from each other, leading to the expected grouping behavior. If you wanted to do the same thing for month and year grouping headers (e.g. December 2010), all you'd need to do is change the format of your grouping field to use the month and day instead of the year.

For more on date formats, see Modifying the page display for a monthly archive view (the "Three steps, for reusing" section).

Hi, I've put net-snmp 5.7.2(upstream LTS) to unstable, it's jump from 5.4.3 and fix 20 or 30 bugs from it. Have fun.

There's some exploit code going around that will let you get root on a range of Linux kernel versions by using a bug in the perf_event_open() syscall. The fix for this is in 3.2.45 and various other stable updates. As a workaround, until it's in Debian stable, you can set sysctl kernel.perf_event_paranoid=2. This blocks the exploit I've seen, though it may still be adaptable to get around this restriction.

Like the ’90s, Drupal really is alive in Portland, the city made popular again from the much-watched TV show, Portlandia. Portland is the homebase for the Drupal Association and host for this year’s DrupalCon, Drupal’s largest North American conference.

This will be Forum One’s biggest presence at DrupalCon since we went to our first conference in Washington, DC, in 2009. We’ll have 17 web developers, project managers, and strategists attending the event from our offices in San Francisco, Seattle, and DC. We can’t wait to meet more Drupalers, share our experiences, and explore Portland!

During our Day Stage session, EPA.gov: Building a Sustainable Drupal Platform, we’re excited to share the challenges and successes we faced in migrating EPA’s large web presence to Drupal. In a “game-show” style session, we’ll investigate how we navigated the unique needs of a large government agency, share project challenges, champion our successes, and provide best practices for other large organizations considering moving to Drupal.

Another highly anticipated session is What Users Want (or Why Webpages are Dead) by Nam-ho Park and Stein Setvik. They’ll dive deep into real questions about the future of websites in the face of the rise of mobile and explore the implications for Drupal.

Each year, it is encouraging to see Drupal growing. With 613 active distributions and more than 25,000 contributors, Drupal is now the largest and most recognized open-source community. It will be interesting to see how keynotes from Dries Buytaert, Karen McGrane, and Michael Lopp address the sheer size of the project and how to get Drupal to even more users.

If you’re going to be in Portland next week, stop by our booth. We’ll have free “Nodetoriusly” awesome T-shirts that will be sure to take you back to the golden age of hip-hop. Plus, we’ll raffle off an iPad mini. And if you have a big heart and bright mind, consider joining our team by checking out our career openings. Come talk to us and help us keep the dream alive at Portland DrupalCon!

Like the ’90s, Drupal really is alive in Portland, the city made popular again from the much-watched TV show, Portlandia. Portland is the homebase for the Drupal Association and host for this year’s DrupalCon, Drupal’s largest North American conference.

Welcome to another Commerce Module Tuesday! Today we are looking at Commerce Product URLs, maintained by Maciej Zgadzaj who is a senior developer at Commerce Guys. This project almost doesn’t require a video. If you’re running Commerce 1.6 or later, just go download this, enable it, and love yourself for making the world a better place. Actually, enabling the module, by default, doesn’t do anything, but the magic is there. And that’s where the video takes the next step. It shows us how to hack the URL to link directly to specific products.

(Video after the break.)

This is a little note for anyone trying to get some debugging out of the puppetmaster when deploying with Foreman.

The trick, much as it is, is that Foreman is running puppet via Apache; so if you're trying to start a puppet master daemon outside that it won't be able to bind to port 8140. You thus want to edit the config file Apache is using to launch puppet /etc/puppet/rack/config.ru. It's probably pretty obvious what's happening when you look in there; simply add

ARGV << "--debug"

and you will start to get debugging output. One issue is that this goes to syslog (/var/log/messages) by default and is a lot of output; so much so that it might get throttled. Although you can certainly reconfigure your syslog daemon to split out puppet logs, an easier way is to just skip syslog while you're debugging. Don't be fooled by config options; simply add

ARGV << "--logdest" << "/var/log/puppet/puppet-master.debug"

to the same file to get the logs going to a separate file. Don't forget to restart Apache so the changes stick.

Track Drupal page load times easily with the Google Analytics moduleTuesday, 14th May 2013

If you're a Drupal developer who's worked on a project with any real complexity I'm sure you've experienced some (or maybe a lot) of slow pages due to some kind of performance bottleneck in your code. Drupal is flexible enough that there's usually quite a few options available to help speed up slow pages, from the "one click" caching solutions provided by core, to third party cache tools like Entity Cache, through to targeted profiling and code refactoring on the level of individual functions with a dedicated PHP tool like xhprof.

In this post I'm not going to discuss fixing performance issues; I just want to talk about an easy way to detect that you have a problem in the first place.

So many times when I've heard somebody complain about a slow site (or section within a site) I see them click around a bit, maybe the cache kicks in and then they say "oh, it's not so bad" or maybe part of the site is only slow in a particular browser or maybe mobile devices are hanging on that cool javascript animation you wrote or maybe your audience doesn't live in the same country as your server. Whatever the situation, the performance you should be interested in is not what you or your clients see on a development setup but the page load times the users of your production site are experiencing.

Did you know that Google Analytics tracks page load times out of the box?

Well... not quite. "Out of the box" Google Analytics only tracks the page load times of 1% of your total page impressions. From Google's own API documentation:

"If you have a relatively small number of daily visitors to your site, such as 100,000 or fewer, you might want to adjust the sampling to a larger rate."

If you're anything like me though, you'll probably want to start weeding out slow pages long before your traffic is averaging anywhere near 100,000 hits a day - unless you like thrashing your server and making your users wait. For a new site that 1% might translate to just a handful of data points that are unlikely to be related or help diagnose anything, really.

Since the sample rate is adjustable we can just continue to push it up until we get meaningful data - Google's daily cap is 10k so if you're getting fewer hits than that each day you can safely push the sample rate right to 100%.

Configuring the Google Analytics Site Speed sample rate

Unfortunately the sample rate can't be set through the Google Analytics UI, we need to add the following line to the tracking script embedded in the site we want to track:

// Sets the Google Analytics Site Speed sampling rate to 100%. _gaq.push(['_setSiteSpeedSampleRage', 100]);

If you haven't worked with the Google Analytics API directly before even a relatively simple snippet like this could be confusing out of context (you might be wondering what _gaq is, for example?)

Luckily the Drupal Google Analytics module has a convenient way to handle dropping in custom GA snippets like this one into the right place for you.

On the Google Analytics module's configuration page, inside the "Advanced settings" fieldset, open the "Custom JavaScript code" fieldset and paste the above snippet into the textfield labeled "CODE SNIPPET (BEFORE)". Save the form and you should be done!

Like most changes to Google Analytics, new data will start tracking immediately but won't become available in a useful format in the dashboard for about 24 hours.

To find the site speed statistics in the Google Analytics UI navigate to Content->Site Speed through the left hand side bar. If you haven't configured the sample rate as per the instructions above this section might look completely "broken", depending on your current traffic levels.

Now that you've tweaked your sample rate for your site, you might want to read up on how to interpret your awesome new data.

Syndicate: planet drupal

Last Saturday (2013-05-11), I gave a talk about Outreach Program for Women (OPW) at the Ubuntu Party Festa Raring Ringtail. I was invited to give this talk because I'm one of the coordinators of this program in Debian side.

This was a small talk and was split in three parts. During the first part I talked about the problem in general: lack of women in technology world. In the second part I talked about the paradox that there are even less women in FLOSS, giving Debian as an example: a very wonderful project, where techie (or non-techie) women should be in love with (at least I am!), has only about 1.6% of women DD. The last part was focused in OPW itself, the successful experience of GNOME with an increasing number of women in their organization and how the program works.

I hope that women attendees will think about applying to OPW or collaborating actively in FLOSS

Here you have the slides (in Catalan): talk_debian_opw

Mozilla Persona is a single sign on system that allows you to login into websites with a single registered email address. To register an email address head over to login.persona.org and sign up. Once signed up you can login to any website that offers Persona with your email address.

Short video explaining Mozilla Persona Beta 2.

The Mozilla Persona module for Drupal allows you to offer Persona as a login option for your users. You can configure the module to be the only sign in method or have it as a second option.

I would like to suggest that the word “unprofessional” be struck from the dictionary – and anyone who uses it struck with a dictionary. It is a word which conveys no useful information or proposal for action, and is thus nothing but meaningless noise.

The purpose of communication is to adjust another person’s process of cognition. I’ve heard it said that “all communication is persuasion”, which is quite true – you’re trying to persuade someone to change what they think. We can consider the intention and effectiveness of an attempt to communicate in this light.

What is someone trying to achieve when they label a person or behaviour “unprofessional”? If we’re being charitable, we would probably say that they’re trying to highlight that something is bad, or could be better. However, just stamping our foot and saying “bad!” isn’t enough – it’s also important to provide some information that the recipient can act upon.

The problem with the word “unprofessional” is that it really isn’t specific enough on the subject of “what is wrong”. Have you ever had someone say something like, “your behaviour yesterday was really unprofessional”? They’re assuming you know what they’re talking about – and you might well have a reasonable guess – but what if you guess wrong? Should you never do anything you did yesterday, just in case that particular thing was unprofessional?

When I’ve caught myself thinking, “that was unprofessional”, of my own behaviour, or someone else’s, I think about what caused me to think that. Once I drill down into it, I usually come to the conclusion that what I really meant was, “I don’t like that”. Since I’m not paid to like things, that’s pretty much irrelevant as a reason to tell someone not to do something.

On the occasions when I come up with something more concrete, it is invariably a more useful expression than “unprofessional”. Things like, “it frustrates the customer”, or “it pisses off the person sitting in the next cube” are a much better expression of why something is bad than “unprofessional”.

I’d encourage everyone to keep a careful watch over themselves and those around them for use of the word. When you catch yourself saying it (or thinking it), examine your motives more closely. Whatever the more specific adjective is, use that instead. If it just comes down to “I don’t like that”, at the very least say that to the person you’re talking to. Don’t try and hang anything grandiose on your personal prejudices. You might come off as being petty, but at least you’ll be honest.

Drupal  7.20 brought a security fix that prevents DDoS attack on servers. Prior to Drupal 7.2 a user could generate image presets on the fly, opening up a potential opportunity for DDoS attacks.

Conrad rolled up a new Armadillo release 3.820 (following two minor fix release in the 0.3.810 series of which we packaged the one that was relevant for us). This new version is now out in a release 0.3.820 of RcppArmadillo which is already on CRAN and in Debian.

The summary of the main changes follows:

Changes in RcppArmadillo version 0.3.820 (2013-05-12)

• Upgraded to Armadillo release Version 3.820 (Mt Cootha)

  • faster as_scalar() for compound expressions

  • faster transpose of small vectors

  • faster matrix-vector product for small vectors

  • faster multiplication of small fixed size matrices

Courtesy of CRANberries, there is also a diffstat report for the most recent release As always, more detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.