Skip to Content

Drupal

ComputerMinds.co.uk: Contribute to Drupal(.org)!

Planet Drupal - 26 August 2014 - 5:00am

So at DrupalCon Austin I had a great time at the contribution sprints. I worked on some issues affecting Drupal.org, it was great fun!

The issues we worked on over the week range from simple things through to some pretty difficult issues.

Although Drupal core can always use more contributors, I would suggest that Drupal.org is also desperately short of contributors too.

Categories: Drupal

KnackForge: Drupal 7: Invoking custom callback in maintenance mode

Planet Drupal - 26 August 2014 - 4:10am
In a Drupal site, if we have any module upgrade or configuration related work to be done in our live site, it is recommended to put the site in maintenance mode, so we can prevent end users from experiencing glitches.   When the site is operating in maintenance mode, any page request would return only maintenance message. Some pages are allowed to access though. The login functionality for instance will work in the maintenance mode. Recently, I faced such a requirements in which a custom module's callback to be invoked as to let Single Sign On (SSO) work for admin in maintenance mode. I would like to explain the way I fixed the same in this blog.   There is a hook in Drupal 7 for that, hook_menu_site_status_alter(). With this hook we can control the site status before menu dispatching, So we can change the site status for the particular path.  
Categories: Drupal

User Popup Info

New Drupal Modules - 26 August 2014 - 3:37am

With this module, you can see a mini profile view of a user when mouse is hovered over his/her profile link anywhere on the website. The effect is similar to what you get when you hover mouse over your friend's name on social networking sites like facebook, linkedin, etc.
You also get a feature where you can ignore certain links on which this module should not operate.

Categories: Drupal

Open Source and social capital

Dries Buytaert - 26 August 2014 - 1:27am
Topic: Drupal

The notion that people contributing to Open Source don't get paid is false. Contributors to Open Source are compensated for their labor; not always with financial capital (i.e. a paycheck) but certainly with social capital. Social capital is a rather vague and intangible concept so let me give some examples. If you know someone at a company where you are applying for a job and this connection helps you get that job, you have used social capital. Or if you got a lead or a business opportunity through your network, you have used social capital. Or when you fall on hard times and you rely on friends for emotional support, you're also using social capital.

The term "social" refers to the fact that the value is in the network of relationships; they can't be owned like personal assets. Too many people believe that success in life is based on the individual, and that if you do not have success in life, there is no one to blame but yourself. The truth is that individuals who build and use social capital get better jobs, better pay, faster promotions and are more effective compared to peers who are not tapping the power of social capital. As shown in the examples, social capital also translates into happiness and well-being.

Most Open Source contributors benefit from social capital but may not have stopped to think about it, or may not value it appropriately. Most of us in the Open Source world have made friendships for life, have landed jobs because of our contributions, others have started businesses together, and for others it has provided an important sense of purpose. Once you become attuned to spotting social capital being leveraged, you see it everywhere, every day. I could literally write a book filled with hundreds of stories about how contributing to Open Source changed people's lives -- I love hearing these stories.

Social capital is a big deal; it is worth understanding, worth talking about, and worth investing in. It is key to achieving personal success, business success and even happiness.

Categories: Drupal

Dries Buytaert: Open Source and social capital

Planet Drupal - 26 August 2014 - 1:27am
Topic: Drupal

The notion that people contributing to Open Source don't get paid is false. Contributors to Open Source are compensated for their labor; not always with financial capital (i.e. a paycheck) but certainly with social capital. Social capital is a rather vague and intangible concept so let me give some examples. If you know someone at a company where you are applying for a job and this connection helps you get that job, you have used social capital. Or if you got a lead or a business opportunity through your network, you have used social capital. Or when you fall on hard times and you rely on friends for emotional support, you're also using social capital.

The term "social" refers to the fact that the resources are not personal assets; no single person owns them. Instead, the resources are in the network of relationships. Too many people believe that success in life is based on the individual, and that if you do not have success in life, there is no one to blame but yourself. The truth is that individuals who build and use social capital get better jobs, better pay, faster promotions and are more effective compared to peers who are not tapping the power of social capital. As shown in the examples, social capital also translates into happiness and well-being.

Most Open Source contributors benefit from social capital but may not have stopped to think about it, or may not value it appropriately. Most of us in the Open Source world have made friendships for life, have landed jobs because of our contributions, others have started businesses together, and for others it has provided an important sense of purpose. Once you become attuned to spotting social capital being leveraged, you see it everywhere, every day. I could literally write a book filled with hundreds of stories about how contributing to Open Source changed people's lives -- I love hearing these stories.

Social capital is a big deal; it is worth understanding, worth talking about, and worth investing in. It is key to achieving personal success, business success and even happiness.

Categories: Drupal

Simple Language field

New Drupal Modules - 26 August 2014 - 12:22am

A simple language field for Drupal 8 with 2 widgets - select options and autocomplete

Categories: Drupal

Composer Vendor Autoload

New Drupal Modules - 25 August 2014 - 8:12pm

Simple module to load the Composer Autoloader when Drupal initializes. This module allows the site builder to manually manage the dependencies for the project themselves, rather than relying on some sort of automation. You may even use this module as a dependency in your Drupal site to load the autoload.php file.

Categories: Drupal

PreviousNext: Vagrant, PHING, core development and automation

Planet Drupal - 25 August 2014 - 4:51pm

At PreviousNext we rely heavily on vagrant for development environments and phing for performing automated tasks to speed up site building and project development. These tools are hugely beneficial in the long run. In this blog we'll have a look at how we as drupal core developers can automate the tedious tasks like site install/ re-install, testing, coding standards validation and enable modules.

Categories: Drupal

Drupal Association News: Drupal Association Board Meeting: 20 August 2014

Planet Drupal - 25 August 2014 - 4:46pm

We held our most recent monthly board meeting last Wednesday, 20 August and we had a lot of news to report and a big agenda to cover. You can review the materials or check out the recording

As the year continues to progress, our momentum as a team continues to build. We're accomplishing more and more with the community, which is fantastic to see. That said, it's also been a challenging year. This is the first year we have attempted to systematically measure the impact of our work. On the one hand, it's been wonderful to start to accumulate a baseline of data we can measure against for the future. On the other hand, the data is also a little all over the place. In some cases, we had very little to go on when setting the goals, which means that we aimed way too high or low. In other places, we have some areas of real concern to address. 

Here the topics we tackled on Wednesday:

Drupal.org Improvments

Overall, we've begun to see some significant improvements to the stability and performance of Drupal.org. Although many of our metrics related to performance are still in the red for the year, the last few months have seen significant improvements in page load times, etc. In short, things ARE getting better. Additionally, as the tech team has begun to gel under new CTO Josh Mitchell's leadership, they have begun to rapidly turn out great work on the feature side of Drupal.org. We've tackled a remarkable number of issues in just the last few months:

  • Implemented user pictures on Drupal.org profiles
  • Conducted 30 User Research interviews and began developing personas for a skill acquisition model of user design (more to come from the DCWG)
  • Implemented RESTws API for Drupal.org
  • Implemented Semantic Versioning for Drupal 8
  • Added Supporting Organizations field on projects (entity reference to an organization with an explanation field - we need to promote this change as it was part of the overall efforts to give credit to organizations)
  • Took over maintenance of the PIFT and PFFR testbots so that the community could continue with improvements to a modern, best-practice alternative
  • Updated the Bakery module to allow us to better integrate with subsites like Drupal Jobs
  • Responded to spam on several subsites where the basic Mollom configurations were overwhelmed by human spammers
  • Responded to and deployed several security release updates including the recent XMLRPC response where we teamed up with WordPress
  • Launched a new landing page on Drupal.org for designers and front-end developers
  • Automated process for publishing supporting partners on Drupal.org

Although Drupal.org is chock full of data, this is an area where we had very little longitudinal or granular data to guide our goal setting. Combined with our slow hiring cycle, we've had a tough time really making a dent in some of our red numbers, but we ARE making progress and most importantly will know so much more for next year than we did for this year. 

DrupalCons

We shared a very in-depth review of DrupalCon Austin at this board meeting, as well as trends for Amsterdam. The long and short is that we had, in almost every way, a very successful DrupalCon in Texas. We were able to compare evaluation, finance, and attendance numbers to Portland and show our year over year trends, which was very helpful. While there is a lot to be happy about, we also have reason for concern. While DrupalCons have sustained growth year over year since their beginning, Texas was basically flat compared to Portland in terms of attendees. Looking ahead at the Amsterdam numbers, we're also finding that we may be at or slightly below our Prague numbers. 

There are many reason we could be seeing a plateauing of these numbers. It could be a natural by product of where we are in the product development cycle. No Drupal 8 and a really mature Drupal 7 product means there is less to talk about and learn. It may be that our demographics are shifting and the Con is not needing their needs. It may be a combination of many things. 

What we DO know is that we need to get to the bottom of the issue so that we can adjust our strategy accordingly. After Amsterdam, you will see a survey from the Association to help understand your DrupalCon motivations. So whether you've always gone to DrupalCon or have never entertained the notion, we will want to hear from you.

Licensing Issues on Drupal.org

I've heard from lots of volunteers on Drupal.org recently that our policies for enforcing GPL v2 licensing on Drupal.org have been problematic. In short, there are too many issues, those issues are reported inconsistently, and volunteers are not trained on our licensing issues and apply remediation to those issues inconsistently. It's a pretty typical story - great volunteers getting stuck in an escalating situation. 

To help mitigate these issues, I pulled together a call with folks who had been working on these issues for advice about how we can help fix the process. The advice of the group is to form a Licensing team (like the Security Team), that receives training from the Association's lawyers and works together to resolve licensing issues quickly and consistently. We would create a separate queue for licensing issues and get this off the plates of the webmasters queue volunteers (where most issues end up now). 

The board agreed that this woudl be the logical next step and a meeting has been scheduled for September 9th to begin work on a charter for the group.  We'll share more details as we have them.

Quarterly Financials

Finally, in executive session we reviewed and approved the financials for the second quarter of 2014. Here they are:

Next Meeting

The next board meeting was scheduled for 17 September 2014. However, given the proximity to the 3 October board meeting at DrupalCon Amsterdam, the board decided to cancel that meeting. Remember though, you can always review the minutes and meeting materials in the public GDrive

Flickr photo: xjm

Categories: Drupal

Robert Douglass: Robert Douglass takes the ALS Ice Bucket Challenge in Köln

Planet Drupal - 25 August 2014 - 11:23am

Baris Wanschers called me out, and here it is, my ALS Ice Bucket Challenge.

Thank you to the Drupal Community for 10 years of prosperity: I hope you take this challenge too, and find it in your heart to give to ALSA.org or a charitable organizations of your choice.

This video is dedicated to Aaron Winborn. Aaron's family could also use your donations, as he is suffering from ALS.

Finally, I expect to see Dries Buytaert, Kieran Lal, and Jeffrey "jam" McGuire complete this challenge within 24 hours!

Tags: Drupal Planet
Categories: Drupal

Drupal.org Featured Case Studies: Tech Coast Angels

Planet Drupal - 25 August 2014 - 9:54am
Completed Drupal site or project URL: http://www.techcoastangels.com/

Tech Coast Angels is the largest angel investment organization in the United States. With over 300 members throughout Southern California, Tech Coast Angels' members have invested over $120 million in over 200 startup companies since their inception in 1997.

Since 2013, Exaltation of Larks has been working with Tech Coast Angels with their online systems, including an extensive Drupal web application that their members use as a deal flow tracker and document management system. Services we’ve provided include support, maintenance, security improvements, performance optimization, and mobile integration.

The web application that Tech Coast Angels uses allows its members to view startup companies' applications for funding, discuss each company's application, and collaborate with one another in researching each company, which then helps them make individual decisions on funding.

Key modules/theme/distribution used: ServicesPHP Filter LockAPC - Alternative PHP CacheSecure Password HashesFeaturesACLOrganizations involved: Exaltation of LarksTeam members: focal55
Categories: Drupal

Cultura Registration

New Drupal Modules - 25 August 2014 - 7:02am

This module provides administrators with a form to enter two category labels, intended to hold each language used in a Cultura Exchange, and creates two unique registration URLs with which people can sign up at the site.

Cultura Registration is part of a suite of modules used by the Cultura Exchange installation profile and this is the strongly recommended way of installing the Cultura Exchange modules if you are starting from scratch.

Categories: Drupal

Code Karate: Multiple Views Part 3

Planet Drupal - 25 August 2014 - 6:23am
Episode Number: 164

In the last installment of multiple views you will learn how to change the look of the view using the two classes you set in the previous video. By using CSS, you will be able to display content in two ways depending on the choice of the viewer. This is a nice advantage to provide options for the visitor to your site.

Tags: DrupalViewsDrupal 7Theme DevelopmentDrupal PlanetUI/DesignCSS
Categories: Drupal

Acquia: How I learned Drupal 8

Planet Drupal - 25 August 2014 - 6:13am

In this post, I will share my experience on trying to learn Drupal 8 during its alpha stage, talk about some of the challenges of keeping up with the ongoing changes while trying to learn it, and end with some tips and resources which proved useful for me.

Categories: Drupal

Lullabot: Module Monday: Office Hours

Planet Drupal - 25 August 2014 - 6:00am

Lets say you are building a site for an institution with multiple locations, each of which have varying hours depending on time of year or other variables. What is the best way to manage this data? This is a pretty common type of content modeling problem. The easiest thing to do is to just give each location a text field for their hours, but that limits display options and is prone to data entry errors. You could also build out a whole fancy content type with multi-instance date fields, but that could get bloated and difficult to maintain pretty quickly.

Categories: Drupal

Friendly Machine: Web Performance: A Guide to Building Fast Drupal Websites

Planet Drupal - 24 August 2014 - 3:50pm

What follows is part one in a series of posts on web performance that I've wanted to write for quite some time. In this series of posts I'll not only be talking about optimizing web performance generally, but also providing specific guidance for speeding up Drupal sites.

Although I'm not a web performance specialist or expert, I have taken a keen interest in the topic in my work as a frontend developer building responsive websites. I love building fast sites and have gained some experience over the years getting Drupal to shed some its inherent sluggishness. 

As a way of systematically tackling what can be a complex subject, we'll use the results of a test from WebPageTest.org, a Google-sponsored tool that provides very in-depth information about the performance of a site in nice, easily digestible chunks.

How Fast Is Fast Enough?

Before we get into the details of web performance we should first stop to ask how fast a site should be in order to qualify as "fast". Here are some research results courtesy of Radware that might help bring things into focus:

  • 64% of smartphone users expect pages to load in less than 4 seconds.
  • The performance poverty line (i.e. the plateau at which your website’s load time ceases to matter because you’ve hit close to rock bottom in terms of business metrics) for most sites is around 8 seconds.

More guidance comes courtesy of Ilya Grigorek of Google. In his recent presentation at the Velocity conference, he cited research that indicates a target page render time should be 1000ms - or one second  - to avoid "context switching" among users.

Basically, if it takes a page longer than one second to render, you risk losing the attention of the user. If it takes longer than eight seconds for a page to render, it's similar in terms of business metrics (conversions, sales, etc) as if it took 30 seconds or a minute.

If one second sounds impossibly ambitious, there is further research showing that a load time of three seconds or less is probably OK

The bottom line: your pages should load in under three seconds on desktop, and under 4 seconds on a mobile.

Pretty harsh reality check, huh? Let's see what can be done to get our sites whipped into shape.

Test Results for this Analysis

In order for us to have a practical example for our discussion, I ran the Friendly Machine site through WebPageTest. Here are the results (click to enlarge image):

I recently completed a refresh of the design of this site with a lot of attention focused on keeping things fast. My target page load time was one second, so I was happy when the results consistently came in below that.

Let's start our analysis by looking at the first number in the above table - under the heading "Load Time". You'll see the value is 0.662 seconds. That's pretty darn good, but if you scan across the table you may see something on the far right that's a bit confusing - a Fully Loaded Time of 0.761 seconds.

So what's the difference between Load Time and Fully Loaded Time?

Load Time is calculated from the time when the user started navigating to the page until the Document Complete event is fired. The Document Complete event is fired by the browser once the page has completed loading.

The Fully Loaded time, on the other hand, also includes any metrics up until there is no network activity for two seconds. Most of the time this means watching for things being loaded by JavaScript in the background.

First Byte Time = Backend Performance

Whenever talk turns to web performance, it seems a lot of folks immediately start thinking of what's happening on the server. Although it's a very important piece of the puzzle, as we walk through this analysis, you'll see that most web performance issues actually reside on the frontend.

Before we get ahead of ourselves, though, let's return to the results from our test and look at the next metric in our table, First Byte Time (highlighted in blue below) which tells us about performance on the server.

This First Byte Time represents the time from when a user began navigating to the page until the first bit of the server response arrived at the browser. The target time for this on WebPageTest is a meager 87 ms!

This metric is also represented as the first in the series of letter grades you see at the top of the test results. You'll notice Friendly Machine got an "A" and I really wish I could take credit for it, but the truth is my host Pantheon - and the awesome backend performance they provide - are responsible for this metric scoring well.

Backend Drupal Performance

Let's pause here and talk specifically about backend Drupal performance. How would we address this metric if it hadn't scored well? This topic can get pretty deep, so we'll only review the most popular options, but they'll still be able to do wonders for improving this key metric if your site is not performing well.

Let's start by discussing server resources (with a brief, tangential mini-rant about shared hosting).

If you want a fast Drupal website, you really shouldn't be on a shared host, period. Although many of them will claim to be Drupal specialists, very few of them actually are. One giveaway is the number for PHP memory limit.

Although this number doesn't directly impact performance, it can break your site if it's too low and is also useful for smoking out hosts that don't know Drupal. You can find this number at admin/reports/status and it will look something like the image below.

You can see on my site this number is at 256 megabytes and this is most likely where you want it, although if you have a simple site without Views or Panels, then 128M might work. If it's set at 64M, then it's too low and this is often what you'll find with shared hosting arrangements. 

Another issue with shared hosting - and one that does impact performance - is that your website is on a server with perhaps hundreds of other sites. If one of those sites gets hit with a large spike in traffic or some other issue, it can affect all the sites on that server as it gobbles up the available resources.

Perhaps the biggest issue with shared hosting, however, is that advanced caching using tools like Memcached and Varnish are rarely, if ever, available. And when it comes to Drupal backend performance, caching is critical. The best you'll probably be able to do with regard to caching on shared hosting is using the Boost module, which we'll talk about in the next section.

To ensure that server resources aren't an issue for your website, consider either a managed VPS or a Drupal host like Pantheon, both of which start at around $25 per month. Pantheon is what I recommend for small to medium sized sites because your site will scale better with them and they offer tremendous value, although they are a great fit for enterprise clients as well. If you have a bigger budget, Acquia or BlackMesh might fit the bill.

Sure, these options cost more than the $7 per month the cheap hosts offer, but they will provide a professional level of service that will more than pay for itself over time.

Caching for Drupal Websites

We said caching was critical, so here are five of the most important caching solutions for a Drupal website:

  1. Drupal's built-in caching
  2. Boost module
  3. Memcached
  4. Varnish
  5. Views caching

There are other options, of course, but these five cover most of the ground. Let's briefly go through them one at a time.

Drupal's Built-in Caching

Most of a Drupal site is stored in the database - nodes, information about blocks, etc. - and enabling the default caching will store the results of these database queries so that they aren't executed every time a page is requested. Enabling these settings alone can have a big impact on performance, particularly if your pages use a lot of views. This one is kind of a no-brainer.

Boost Module

The Boost module is pretty great. It works very well in tandem with Drupal caching, but it requires some additional configuration. What you end up with after you have the module installed and configured is a caching system that stores the output of your Drupal site as static HTML pages. This takes PHP processing out of the equation, leading to another nice bump in performance.

Memcached

Memcached can speed up dynamic applications (like Drupal) by storing objects in memory. With Boost and Drupal caching, the data being cached is stored on the server's hard drive. With memcached, it's being stored in memory, something that greatly speeds up the response time for a request. Memcached works great in conjunction with both Boost and Drupal caching.

Varnish

Varnish is an HTTP accelerator that, similar to memcached, stores data in memory. It's capable of serving pages much faster than Apache (the most common web server for Drupal sites). It can also be used in conjunction with memcached, although it's often the case that they are not used together and other advanced caching methods are instead implemented alongside Varnish.

Views Caching

Another type of database caching is Views caching. Views is a very popular, but rather resource intensive, Drupal module. Implementing Views caching can give your site a nice additional performance boost by possibly removing a few database queries from the build process.

To set views caching, go to your view. On the right hand side, under Advanced > Other, you'll see a link for Caching. Just go in and set a value - an hour is usually a good default - for each view on your site.

Wrapping Up Part One

Wow, long post and all we've really covered so far is backend performance and caching! This discussion hasn't been comprehensive by any means, but it does provide a great start.

Next time we'll start digging into frontend performance, the area where most of our performance issues reside. What should be obvious so far is that web performance is a subject that is both deep and wide, but also critically important to building successful websites.

If you have any comments about this post, you may politely leave them below.

Drupal Web Performance
Categories: Drupal

LookAlive: Saving a serialized data Array as a property on a custom Entity (D7)

Planet Drupal - 24 August 2014 - 12:42pm

Doing some initial prototyping work on the Comstack module I hit this question without a clear answer. For clarity here's a chunk of the schema structure for a Message Type (exportable entity).

/**
* Implements hook_schema().
*/
function comstack_schema() {
  $schema = array();

  $schema['comstack_message_type'] = array(
    'description' => 'Stores information about all defined {comstack_message} types.',
    'fields' => array(
      'id' => array(
        'type' => 'serial',
        'not null' => TRUE,
        'description' => 'Primary Key: Unique {comstack_message} type ID.',
      ),
    ...
    'delivery_methods' => array(
        'type' => 'text',
        'not null' => FALSE,
        'size' => 'big',
        'serialize' => TRUE,
        'description' => 'A serialized array of allowed send methods for this type.',
      ),

Following the instructions on how to create an exportable Entity as over here on d.o https://www.drupal.org/node/1021526 and here https://www.drupal.org/node/1021576

The second link has the following code which is the submit process where the form values are wrapped up and a new entity put together for you before saving.

/**
* Form API submit callback for the type form.
*/
function profile2_type_form_submit(&$form, &$form_state) {
  $profile_type = entity_ui_form_submit_build_entity($form, $form_state);
  ...

So how do we construct a form which will allow for arbitrary array structures? Like this (in your form function)!

  $form['delivery_methods'] = array(
    '#title' => t('Delivery methods to allow'),
    '#type' => 'checkboxes',
    '#required' => TRUE,
    '#options' => $delivery_methods,
    '#default_value' => isset($comstack_message_type->delivery_methods) ? $comstack_message_type->delivery_methods : array(),
    '#tree' => TRUE,
  );

It's the #tree bit there that does it. Here's an explanation from the Form API documentation page which is marked as archived but still useful https://www.drupal.org/node/48643.

When we set fieldset value to TRUE we create the form:

<?php
$form['colors'] = array(
'#type' => 'fieldset',
'#title' => t('Choose a color'),
'#collapsible' => FALSE,
'#tree' => TRUE,
);
$form['colors']['green'] = array(
'#type' => 'checkbox',
'#title' => t('Green'),
'#default_value' => $node->green,
'#required' => FALSE,
);

and this is how they are inserted or updated in a db_query:

<?php
function example_insert($node){
  db_query("INSERT INTO {example} (nid, question, green, blue) VALUES (%d,'%s', %d, %d)", $node->nid, $node->title, $node->colors['green'], $node->colors['blue']);
}

Any questions? Leave them in the comments :]

Categories: Drupal

Cultura Discussion

New Drupal Modules - 23 August 2014 - 7:36pm

Cultura Discussions can be standalone topics presented for discussion or can hold the collected answers of questionnaires. This module provides the content type and views listing it. The Cultura Questionnaire module helps produce the webform Questionnaires and the Cultura Answer module can aggregate the webform responses and place them in Cultura Discussion content for clean-up by educators and commenting by students.

Categories: Drupal

Cultura Questionnaire

New Drupal Modules - 23 August 2014 - 7:15pm

The Cultura Questionnaire module makes pairs of prompts (one for each of two languages) and creates webforms, one in each language, for people to complete.

The Cultura Answer module can aggregate these webform responses and place them in Cultura Discussion content for clean-up by educators and commenting by students.

Categories: Drupal
Syndicate content


Google+
about seo