Newsfeeds

It's fair to say that in the last year, adopting the CSS preprocessor SASS has completely changed frontend development for me. That's a sentiment I've heard others express when they started using it — and I was pretty late to the party.

I got attracted to it initially through variables. We've all been there when a client or a designer wants to change a color and suddenly we have to change dozens or hundreds of values across CSS.

Dale Sande captures that kind of revolution in efficiency that SASS brings, as seen in a screenshot from his upcoming presentation at Drupalcon Portland.

But Dale, who's spoken plenty on SASS and organizes the Seattle SASS meetup, is taking us way past the SASS basics like variables, and that's why I'm excited to see his presentation next week.

Around the same time SASS came onto the scene, some thoughtful people were exploring more maintainable frontend development and CSS architecture through ideas/acronyms like OOCSS, SMACSS and BEM, and folks like Nicole Sullivan, Jonathan Snook (a Drupalcon featured speaker!), Nicolas Gallagher, and Harry Roberts.

I spoke with Dale about SASS, object-oriented CSS and some the things he'll be covering at Drupalcon. Be sure to join me at his session, "Sass: OO'S'CSS w/Extends and Silent Placeholders," on Wednesday at 2:15 PM!

IB: Some people argue SASS creates bloated code — do you see placeholders addressing that concern effectively?

DS: Sass doesn’t create bad code. Bad coders do.

The whole concept of placeholder selectors was designed to fight code bloat and be a more pragmatic solution to OOCSS. In my presentation, I illustrate how using the various techniques generate code.

The real "ah-ha" moment comes when we see how using placeholder selectors makes it easier to manage and literally re-use code — thus reducing dreaded CSS bloat.

IB: What's the advantage to using silent placeholders over mixins for a set of rules?

DS: Simply put, being able to re-use code without duplicating code. The use of mixins was the first part of being DRY with our code. Looking at the Sass it felt AWESOME! But when we looked at the output CSS, this is when we realized that we were all living a lie.

Our CSS rules were being duplicated tens, if not hundreds of times. We weren't being DRY, we simply put the onus of duplication on the machine.

Placeholder selectors embrace the one of the oldest concepts of CSS and that is to extend the CSS selector for reuse. But with traditional CSS this was difficult to do, especially when you were dealing with thousands of lines of code. Sass' @extend directive allows developers to create name-spaced reusable chunks of code that is portable, re-usable and extendable without duplicating anything.

IB: Do you see placeholders as helping to reduce the amount of tight coupling — scattering pieces of styles in multiple places?

DS: While Placeholder Selectors are a tool that can help with scattered code, it is not the only solution. Having a file/folder structure that embraces the different types of code, e.g. CSS selectors, placeholder selectors, mixins and functions, can assist in creating reusable modulare code and maintain a process of control over the many parts.

Images: Screenshot from Dale Sande's presentation.

Join Rootwork on Twitter, Facebook and SlideShare.

Learn about Rootwork's services for nonprofits and social change.

This will make your website pass gas when you scroll.
Just for novelty.

Imports properties from the Vebra Live estate agent software and converts them to nodes

Hey developers ~ new, experienced or otherwise, undecided!

DrupalCon Portland is just around the corner — have you thought about the week and what you want to accomplish? Keynotes, sessions, a new job, and "people to see" are certainly popular options. As one colleague put it, "Spending time with all the cool, smart people that I talk to online." Maybe just making sure you have some of these ten things to bring with you to Con is all you can muster right now.

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

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!

Web Log Analyzer is aiming to provide an alternative to AWStats (and the likes) and will be implemented in PHP as a Drupal 7.x module.

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!

 

What it does

Propels Drupal 6 sites into the Future by suppressing PHP strict warnings created when running a Drupal 6 site on PHP 5.4.

If you've transferred a Drupal 6 site to a server running PHP 5.4 chances are pretty good that you'll see tons of PHP warnings flooding your watchdog logs and displaying on-screen messages about PHP strict warnings in contributed code. Some of these will eventually be fixed by maintainers but some inevitably will not. Sure you can fix your own code but what about all the others? What to do? You have a few options:

1.) Maybe you've switched your Drupal error reporting to be "log only". That's fine but expect your watchdog table to balloon in size very quickly and you're probably noticing a significant performance lag.

2.) Maybe you tried to turn off strict warnings via settings.php, php.ini or .htaccess. None of those will work because Drupal's drupal_error_handler function will override those settings unless you set the value to 0 (no error reporting at all) which is not a good thing either.

3.) You could hack core, kill a kitten and move on. It would work, but what about the kitten?!

4.) Install this module which will gracefully override drupal_error_handler() with a slightly modified version which will suppress the warnings from being shown on the screen or added to the logs. No patches, no hacks, no killed kittens.

What it doesn't do

It doesn't actually FIX the warnings. It just keeps Drupal from screaming about them.

Based on Biblio Scholar, this module adds Dublin Core metatags to biblio nodes.

This is a very simple, lightweight module that hides standard login page (/user) behind specified alias. After creating alias to login page path "/user" is not available anymore if the user is not logged in.

Configuration

After enabling the module, navigate to the admin settings page (admin/config/people/hide_login_page) and type alias to login page.

this is a module for payment with paywords system of banorte mexico.
if you want more security o another thing you can edit the module and send me your changes.

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

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

Tramite questo modulo potrai creare un carousel per il tuo sito.

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

Drupal 8 port of http://drupal.org/project/menu_attributes

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.

This module allows site administrators to override the Field Label on any field in the Manage Fields settings page. This allows each field to have a different title in different view modes.

Instructions

The field formatter label settings are found in the Manage display tab for content types, users, and other entities. A text box is available for each field's label, revealed by using the formatter settings edit button (Gear wheel icon) for that field. If no 'Label override' is specified then the default will be used.

Dependencies

• Field formatter settings: Provides the low-level API needed to alter formatter's settings forms.

Related projects

This module is almost identical to the Field Display Label module, the sole difference being that the label can be overridden in the Manage Display UI (rather than on the field configuration screen).

This module should work just fine with the Field Display Label module in the way you expect. If it is enabled the following logic dictates what a field's label will be:

1. Use the Field Formatter Label override, if it is not specified then:
2. Use the Field Display Label override, if it is not specified then:
3. Use the Field label (as per Drupal core behaviour).

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