Drupal Planet

Syndicate content
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 43 weeks 5 days ago

Microserve: When to use $query->fetchAll() (hint: it's optional)

Wed, 2014-03-12 06:40

Something that has come up on one of our projects recently is when to use fetchAll() or equivalents like fetchAllAssoc().

When writing a db_query() or db_select() query, you don't always need to use $query->fetchAll() or $query->fetchAllAssoc() to retrieve the result set; it's optional.

Database queries in Drupal 7 are iterator objects, so you can treat them like an array and loop over the results with foreach(). If you're going to do any processing on the results, it'll be quicker and use much less memory this way.

So for example, this will still work, note the lack of fetchAll():

// Build and run the query.
$results = db_select('node', 'n')
           ->fields('n', array('nid', 'title'))
           ->condition('status', 0, '!=')

$nodes = array()
// We can use a foreach loop on the $results object.
foreach ($results as $n) {
  // Each $n is an object.
  $nodes[$n->nid] = $n->title;

If you need the result as an array, you can use $results->fetchAssoc() to retrieve one item at a time:

// Build and run the query.
$results = db_select('node', 'n')
           ->fields('n', array('nid', 'title'))
           ->condition('status', 0, '!=')

$nodes = array()
// We can use a foreach loop on the $results object.
while ($n = $results->fetchAssoc()) {
  // Each $n is an object.
  $nodes[$n['nid']] = $n['title'];

One common use-case for using fetchAll() is so you can use count($results) to find out how many items were returned by the query. To get around this, you can use a count query instead. So:

// Create the query, but don't execute it yet.
$query = db_select('node', 'n')
         ->fields('n', array('nid', 'title'))
         ->condition('status', 0, '!=');

// This runs a COUNT(*) query to count the number of results.
$count = $query->countQuery()->execute()->fetchField();
// Now run the original query and return the result set.
$results = $query->execute();

More details can be found in the DatabaseStatementInterface API documentation, or in the PHP PDO manual.

Categories: Drupal

Pronovix: My first iOS training at Drupalcamp London

Wed, 2014-03-12 01:58

I have been a developer at Pronovix for over 2 two years now. During this time I was either developing a .NET based web service or iOS applications, but what they all had in common was that they were communicating with a Drupal site. I was always on the dark side of Drupal until last week, when I attended my first international Drupal conference ever: Drupalcamp London

Categories: Drupal

Deeson Online: DrupalCamp London session: Concurrency in Drupal

Wed, 2014-03-12 00:22

On March 1, I attended DrupalCamp London as a speaker. It was my first time running a session, but my training topic, Concurrency in Drupal, turned out to be a popular choice!

What is Concurrency in Drupal?

Concurrency in Drupal is the description and demonstration of making migrate faster. You can learn more about it in a previous blog of mine.

The session

During my half-hour session, I covered the basics of:

  • Why concurrency makes programs faster and;
  • How to wrapper drush and migrate to make it execute in parallel.
The presentation

The wisdom of the crowd

The great thing about DrupalCamps are the discussions that take place - and there was an interesting debate after my session where the conference delegates described other approaches to solving the problem.

For example, a number of participants liked the ‘brave’ live demo which showed a migration first taking two minutes with one process, and dropping to around 20 seconds with eight processes.

Would I do it again?

Actually, yes. I would.

All in all, it was a good first 'Drupal session' experience - so if you have discovered something of interest to share with the community, I'd recommend you give it a go!


Read moreDrupalCamp London session: Concurrency in DrupalBy John Ennew | 12th March 2014
Categories: Drupal

Modules Unraveled: 099 The Core Mentoring Experience With Marc Drummond - Modules Unraveled Podcast

Tue, 2014-03-11 22:00
Published: Wed, 03/12/14Download this episodeDrupal Core Mentoring
  • For someone who’s not familiar with it, what is it? Or how would you describe core mentoring?
  • How long have you been taking part in core mentoring?
  • Do you remember what your first experience was like? Was it scary?
  • What are some of the way’s you’ve helped in core mentoring?
Questions from Twitter
  • Cathy Theys
    • After contributing once, what made him keep goin?
    • Has he ever done something that didn’t get feedback, reviews or moved forward in some way?
    • How did he deal with that practically to get it moving, or mentally to not get him down.
    • What would he say to people who were frustrated by trying to help?
    • What are his goals?
    • What improvements to d.o would make it easier for him in his daily (or weekly) contributing tasks?
    • How much time per week does he estimate is on contributing?
    • Is it interest driven, or a byproduct of projects at work or contracts?
    • What ways does Marc contribute beyond writing patches?
    • Is Marc happy with the amount of contributing he does? If not, what barriers does he face?
    • Lots of people share that feeling: of wanting to do more, and see things fixed. Why? Is it that much fun? Addictive?
Your Experience
  • Do you have anything you’d like to say to someone who’s heard of core mentoring but not gotten involved?
NodeSquirrel Ad

Have you heard of/used NodeSquirrel?
Use "StartToGrow" it's a 12-month free upgrade from the Start plan to the Grow plan. So, using it means that the Grow plan will cost $5/month for the first year instead of $10. (10 GB storage on up to 5 sites)

Episode Links: Marc on drupal.orgMarc on Twittermdrummond IRCMarc’s blogPost about skills required for D8Drupal Ladder WebsiteTwin Cities Drupal Camp (August 2014)National Association of Government Web Professionals (September 2014)Call for SpeakersCall for SponsorsTags: 
Categories: Drupal

Darren Mothersele: Death of the Drupal Themer

Tue, 2014-03-11 17:00

At Drupal Camp London 2013 James Panton presented a methodology for implementing designs in Drupal without resorting to custom theme development. At this years Drupal Camp I pulled together two BoF (Birds of a Feather) sessions to continue the conversation and discuss prototyping designs, atomic design, and challenges of incorporating design activities into development workflow.

In recent posts I've talked about prototyping and a bit about using Jekyll for prototyping. In many ways this discussion is a continuation of those ideas, but also much more general in it's scope, and more wide-reaching in it's potential.

Death of the Themer?

I've become interested in this area after recently facing challenges bringing design activities into the development workflow of an agile project. But first, for some context, let me explain where this all began...

Last year, Jim presented a methodology for implementing designs in Drupal without having to do any custom theme development.

First, Drupal is stripped of all it's markup. Jim presented to a packed room at Drupal Camp London, and received a big whooping round of applause when he showed naked Drupal markup. Perhaps indicating the general level of frustration the developers/themers have from battling with Drupal markup. Also, there's a general preconception that Drupal suffers very badly from "Divitis", "Classitis" and "Span-mania". This demo showed that this need not be the case.

Next, markup is added back in bit by bit to match the markup in the flat HTML/CSS design. This means that the eventual markup produced by Drupal should exactly (or almost!) match what the designer originally intended. The rendered HTML is therefore cured of it's divitis (contains much less bloat), works with the CSS styles from the design with little or no tweaking, and can make use semantic HTML5 tags.

The tools used to reset Drupal default markup include: Semanic Views, Display Suite, Panels, and a fork of Semantic Panels that I can't seem to find a reference for. Fences can also be useful, although functionality to override field wrappers is also part of Display Suite.

One of the main benefits of this approach is that it allows designers and Front-end developers to work freely, using whatever tools they want, and without consideration for any of Drupal's (perceived) limitations. There have been lots of really cool developments in front-end, including CSS and HTML preprocessors, and the multitude of CSS and JS frameworks. This approach allows designers, front end developers, UXs, and IAs to take advantage of all of these tools when prototyping sites.

During the BoF sessions at this year's Drupal Camp London a few limitations and disadvantages were discussed. This methodology moves the implementation of design from development (writing code) to configuration. This can become quite repetitive as each individual bit of output has to be configured with appropriate resets and the correct wrappers to build up the markup.

Custom Plugins?

In the BoF sessions I presented a methodology that I had been playing with, inspired by Death of a Themer, whereby designs are implemented in a similar way, without the need for a custom theme. Drupal markup is taken to a "full reset" state, and then just the required markup is introduced through various plugins.

This differs from the original methodology as it does not use configuration to add wrappers back in to fields, view modes, views, panels, etc. Instead, the markup is taken from the prototype (flat HTML and CSS) and copied into "plugins". Various plugins are used:

  • Display Suite plugins to add markup to content/entities in various view modes.
  • Views styles to output list markup
  • Panel's style plugins to add "box" markup, and,
  • Panel's layout plugins to add layout markup.

The result is the same markup as the flat prototype, and the same result as with the original Death of a Themer approach, but with much less configuration required.

The real big win for this approach, is that the components of the design are reusable across various content types and sections of the site without having to repeatedly configure each occurrence.

Building out these plugins for every bit of a design might seem like over-kill and more work than is really necessary, but it is a much more scalable way of theming as you end up with design components that can be reused across the site.

This version of "Death of a Themer" means the Themer is replaced with a developer, rather than a site-builder, as the emphasis moves away from configuration towards writing custom plugins in code. However, I think a lot of the grunt work can be automated, as I'll explain in a bit.

Atomic Design

I saw parallels between this approach (of reusable theme components) and the emerging trend of atomic design. In fact, I think atomic design is more than just a current trend but a real leap forward in design methodology.

We're not designing pages, we're designing systems of components.
-- Stephen Hay

While producing an atomic design the designer is effectively breaking down the design into components. This is exactly what a good themer does when they take a design and decide how to implement it as a Drupal theme.

From Design to Theme

When a designer hands over a design (let's assume static HTML and CSS) the developer (or themer, or site-builder) has to make several decisions about how this will be implemented.

  • Assumptions are made and things get "lost in translation"
  • Compromises are made due to limitations in implementation (i.e. limitations of the CMS, content model, etc)
  • Markup is augmented to add in extra properties like RDFa, etc

There shouldn't really be a "handover" of design. The style guide / atomic design or static mockup that is the result of prototyping should evolve as the product evolves.

If something comes up that needs design we go back to the static HTML/CSS to implement it. If using atomic design, this means adding any required "atoms", "molecules", etc.

If changes have been made as a design is implemented these need to be flowed back upstream to the style guide so that further development of the design can happen, and then (some of) the conversion process is repeated to bring across new design elements into the theme/templates.

This process can be hard to manage and bring duplication of effort into the process.

If we can automate some of the steps involved in going from static HTML and CSS to Drupal theme then we can move towards a more agile, and robust design-dev workflow.

Proof of concept

Automatically generating a Drupal theme from either a style guide, atomic design, pattern library, static mockup, prototype (or whatever you want to call it!) might sound like a crazy idea, but I've got a working proof of concept.

I decided to start from just pure HTML/CSS. After experimenting with static site generators (HTML preprocessors), and CSS preprocessors like SASS, I decided that it was best to take pure HTML/CSS as the starting point. This works because every design eventually ends up as HTML/CSS. It's the language of the web, so it's unavoidable. It means designers can use any combination of tools they like, as long as they produce HTML/CSS as the end result.

As an example, I'm using Jekyll to compile the static mockup, and Compass to compile the CSS, but this could be any combination of tools, or just hand-crafted HTML and CSS.

The next stage is to add annotations into the source of the HTML to identify and describe each of the design "components".

I don't have any terminology yet. Drupal has it's own jargon, as does SMACSS, Atomic Design, OOCSS, KSS, etc. I'm not sure what to call things. I'm tending towards a combination of Atomic Design and Drupal terminology, but this will change.


There has been some discussion in the design community about Pattern Library Annotations documentation, etc.

I want to use annotations in designs so that they can be automatically parsed and converted.

In this proof of concept, annotations in the HTML source code map directly to the appropriate Drupal templates and plugins.

I'm using the x- prefix for my custom attributes. This mechanism is intended for use in vendor prefixing for vendor specific attributes. It distinguishes them nicely from data- custom attributes, results in valid HTML5, and therefore I think it's an acceptable abuse of the feature.

For example, annotate a certain part of the source code as being responsible for layout and it will be automatically compiled into a Panels Layout Plugin:

<div x-drupal-type="layout" x-drupal-name="front_page" x-drupal-label="Front page" x-drupal-no-wrap> <div class="container"> <div class="row"> <div class="span8" x-drupal-region x-drupal-name="content"> ... </div> <div class="span4" x-drupal-region x-drupal-name="sidebar"> ... </div> </div> </div> </div>

Another example, this is content shown in a particular preview style called "Box". It maps to a Drupal view mode:

<div class="box" x-drupal-type="display" x-drupal-name="box_teaser" x-drupal-label="Box teaser"> <img src="" width="100" height="100" alt="" x-drupal-region x-drupal-name="image" x-drupal-no-wrap> <h6 x-drupal-region x-drupal-name="title">Easy to use</h6> <p x-drupal-region x-drupal-name="summary" x-drupal-no-wrap> To get started, you select the desired sample and base the entire website on it. It’s that simple! </p> </div>

Many other attributes are identified and the system currently supports panels layouts, panels styles, views styles, display suite (view mode templates), menus (kinda), and image styles.

During the compilation process the various components are identified and the appropriate plugins are created. Any required static files, such as CSS and JS are copied across. Any content in the various regions is removed from the markup, and the generated plugins therefore only contain the markup to wrap the various parts of Drupal output.

You can see the (very!) rough proof-of-concept here: https://github.com/darrenmothersele/hyde

You really shouldn't try using this yet, but if you insist, install the modules on a Drupal site with Display Suite, Panels, etc, then enable both modules, and configure to point at the folder with your HTML/CSS design. Then click the "Sync" button to parse your design files and create and register the appropriate plugins based on the design.

Warning: You are probably better off waiting for the next version or some actual documentation!

Rather see it in action?

If you would rather see it in action, then come along to the next Drupal Show and Tell where I'll be demonstrating the early version of the theme generator and asking for feedback!

Categories: Drupal

Drupal Association News: Drupal.org team week notes #22

Tue, 2014-03-11 14:21

Drupal.org improvements

As usual, a lot of big and small deployments happened on Drupal.org during the past 2 weeks. RTBC patches are now being automatically re-tested (thanks jthorson!). Module index page is back, as well as full pager on issue listings, except for text search pages (thanks drumm!).

There is a new block available in your Dashboard on Drupal.org - “Your security issues”. The block will display the issues you have access to on security.drupal.org. Thanks mlhess and drumm!

Personal blog tags: week notes
Categories: Drupal

Drupal Association News: Addressing the Growing Demand for Drupal Talent

Tue, 2014-03-11 11:40

Recently, the number of Drupal websites on the web surpassed a million and that number will no doubt continue to grow. While there is plenty of interest from businesses, nonprofits, and government entities in implementing Drupal websites, a big challenge remains: the relative scarcity of talent.

Categories: Drupal

2bits: Another botnet spamming Drupal web sites, causing performance issues

Tue, 2014-03-11 10:36
We previously wrote in detail about how botnets hammering a web site can cause outages. Here is another case that emerged in the past month or so. Again, it is a distributed attempt from many IP addresses all over the world, most probably from PCs infected with malware. Their main goal seems to be to add content to a Drupal web site, and trying to register a new user when that attempt is denied because of site permissions. The pattern is like the following excerpt from the web server's access log.

read more

Categories: Drupal

Drupalize.Me: Seeing What Has Been Done in Drupal Theming

Tue, 2014-03-11 08:00

There is a Buddhist quote which states, "I never see what has been done; I only see what remains to be done." But learning can be overwhelming if we only look forward. In this post, let's take a journey back in time to get a better sense of how far Drupal theming has come and where it's headed next.

Categories: Drupal

Drupal Association News: DrupalCon Goes to Latin America in 2015

Tue, 2014-03-11 07:35

Here is the much awaited blog post to consider our options for the location of our 2015 Latin American DrupalCon. While we have looked at the pros and cons for two locations, we want you to weigh in and tell us what you think!

Categories: Drupal

InternetDevels: Field API D8 - Custom Formatters && Widgets

Tue, 2014-03-11 07:00

Drupal 8 has dramatically changed the process of creation of custom formatters and widgets. If in Drupal 7 this could have been done with hooks usage, then in the new version this process is similar to Ctools plugin writing. Further in this blog we will explain why.

Read more
Categories: Drupal

Deeson Online: It canna handle the load cap'in

Tue, 2014-03-11 04:00
Load testing

When building a site you want to make sure that it can handle the expected (and even unexpected) load that might incur through the traffic that the site will receive.

There are some tools that you can use, such as ‘siege’ or 'ab' (Apache Benchmark) to test the impact of multiple users requesting a page (or several pages).  These can be good for the initial testing of page loads etc., but in order to be able to see more realistic results of multiple users from multiple locations around the world there is a nice online service called Load Impact.

This allows you to configure user scenarios (user journeys through a site) and store your test configurations (configurations that you can run multiple times and clone to store different variations) and even schedule tests to be run on you site at regular intervals.

The configuration allows you to set how many user syou want to simulate accessing your site over a period of time, known as a 'load test'. So, for example, you can scale from one to 200 number of users over a five minute period. 

You can also add multiple user schedules within the load test, meaning that you can build a scenario which increases the number of users from one to 200 over a four minute period, then keep the number of users at 200 for a further two minutes.

You can also configure where your traffic is going to be coming from in the world and set up multiple sources.

Site testing

This approach became invaluable recently when working on a site. The site had varnish cache configured for it, but there were a couple of places where AJAX calls were being made back to the Drupal site to get up-to-the-minute data from a third party web service. 

From the initial testing with Load Impact on the home page, our varnish cached pages responded as you would have expected - no problems at all. We then also used Load Impact to test a specific AJAX end point to see how this would handle the requests.

Having done this, this highlighted that the third party web service response gradually got slower as the number of users increased, indicating a potential weak point in the site.

After the initial testing of specific pages, we did full testing of a users journey. We used Load Impact as it has a nice plugin for Chrome which allows you to record page clicks into its programming language script (Lua) which you can save as a user scenario. They also have full documentation on their scenario scripting.

We then ran this test using the above load plan (one - 200 users in four minutes, followed by continuous 200 users for a further two minutes) and found that once we had got up to about 200 users using the site, the site became very slow and finally ground to a halt. Not a good outcome.

Investigating highlighted problems

Within Apache’s configuration for its log format, you can include the 'the time taken to serve the request, in seconds' (%T) and 'the time taken to serve the request, in microseconds' (%D)  in the access log. The reason for including both is because the first (%T) is in seconds and you would hope that most requests take less than a second to process.  

So including the second time (%D) which is in microseconds, you can get a more accurate response time. Also, having the first time in seconds can help when grepping the logs for requests (which took over a second to process).

You can also enable Apache’s ’status’ screen, but for security reasons, make sure that this is configured to be behind a htpassword or only accessible via localhost and an SSH tunnel. This status page shows various details about Apache including the number of threads that are being used and what requests the threads are being used for.  

Having added the request times to the log format and activated that status page, we re-ran the test.

As the number of users approached 200 concurrent users, we could see the apache threads building up and not being released until we hit the maximum number of threads (255). At this point apache was then queuing requests, delaying all future requests.

Once the test had stopped we analysed the access logs which showed that the AJAX requests had been taking over 40 seconds to process as the number of users increased, which was therefore tying up a thread meaning that we eventually hit out limit.

As there was nothing that could be done about the speed of the third party web service, we opted for caching the response from their web service for a period of five minutes, reducing the number of requests to it, meaning that the service could then handle the requests better.

Having implemented the caching, we re-ran the tests. Throughout the test, the site was responsive and seemed to have no impact from the number of users on it.  

We were much happier and the client was very pleased that their site would be able to handle the load that they might expect!

Read moreIt canna handle the load cap'inBy Mike Davis | 11th March 2014
Categories: Drupal

Zero to Drupal: Quicktips with Charlie: Entity Metadata Wrapper and Null Values

Mon, 2014-03-10 19:06

Last year I had the privilege of meeting Charlie Schliesser, a fellow developer here in St. Louis. Little did I know, a few months later we'd actually be working together quite a bit as I took a new position with my church which utilized the services of the company he worked for. Since that time, we've had several co-working sessions where we swap tips, talk about new technologies, get help with problems and leave inspired to do cool work. Each time we depart, I feel like I have a few more tools in my toolbox and I'm eager to share them. With that in mind, I'd like to start a series of posts that share what we learn. Feel free to leave comments, ask questions, or give feedback!

Entity_metadata_wrapper and Null Values

Are you a fan of entity_metadata_wrapper from the entity module? If you aren't, it's a great alternative to node_load()/entity_load() that gives you chain-able, localized, and sanitized (if requested) access to fields and properties of any entity. If you are hip to EMW, you've likely run into an issue where you try to access the value() of a field that isn't set on the object and EMW throws a nasty exception killing the page.

This often happens when looping through nodes where a non-required field is blank (i.e. $wrapper->field_middle_name->value()) and is quite frustrating. Before today, I'd try to avoid this issue by using field_get_items() or dumping the entity (using $wrapper->value()) and checking the value there. Thankfully, today I found a stackoverflow post that provided a pretty elegant alternative.

The Solution

Who knew that the good folks who created EMW implemented the magic method __isset() on the EntityMetadataWrapper class? Now, we can do something like this to check for set values:

  1. $wrapper = entity_metadata_wrapper('node', 123);
  2. if($wrapper->__isset('field_middle_name')) {
  3. // Do something awesome with the middle name.
  4. } else {
  5. // Don't do anything awesome, they don't have a middle name.
  6. }

Pretty neat huh?

Categories: Drupal

Open Source Training: Is Drupal Entityforms a Good Alternative to Webforms?

Mon, 2014-03-10 17:41

Last month, we ran a Drupal webinar called 45 Modules in 45 Minutes.

In the webinar we ran through 45 of the best and most popular modules in 45 minutes.

One of the modules we mentioned was Webforms which is a module we use in every beginner class.

In the comments on that webinar, someone mentioned Entityforms as a viable alternative to Webform and one that is more tightly integrated to Drupal.

I decided to take Entityforms for a test drive ...

Categories: Drupal

David Norman: Guardr achieves point release status

Mon, 2014-03-10 13:35

The first point release of the Guardr distribution for Drupal was released last week. Though the Guardr node wasn't created until May 2012, the project actually started about 5 years ago. The product follows much of the history of Drupal - as a collaboration between many developers across multiple different shops. The reality is that the Guardr make file is just a way to organize a crap-load of work that was done in module contrib land.

I was faced with hardening Drupal beyond the built-in controls as part of a project for a Fortune 100 company. At the time, my thoughts were to turn Drupal from a social publishing platform into a business application. One of my project requirements was to conform to business practices that would limit users' sessions - to make sure when someone shared a login at work that it could only be used by one person at a time. Shared logins break a security principle of accountability. As long as users are sharing the same account, nobody can tell for sure who updated node content or changed site configuration. That's when I started committing patches to the Session Limit project.

The Drupal Security Report, updated recently in December 2013, enumerates how Drupal is secure by default and how each of the security points match to the OWASP Top 10 vulnerabilities for web applications. The mitigations for OWASP Top 10 items haven't changed substantially over the past 5 years in Drupal core.

Though Drupal's default configuration sends seemingly harmless information, Guardr goes an extra step - it checks for security updates by default. It seems odd that I should even have to tout that as a feature. Drupal tries to be helpful by displaying errors to the screen after the installation is complete.

Guardr's install profile disables displaying error reporting by default, silently logging them instead. You should be reviewing your logs regularly anyway. Every time Drupal has to log a PHP warning, a deprecated function, or Drupal nuance, it drags down your database and extends your page load times. Even if you mess up in a big way, Guardr hides fatal PHP errors, too.

Part of Drupal's history is as a social platform. Even though the forum module has always been a joke to usefulness, the default new user rules permit new user registration without administrator approval - again, something that Guardr locks down.

While LoginTobogan was a great introduction for usability improvement, allowing users to login using their email address is a security weakness. I recently just added my real email address to the footer of my blog. If I then also allowed anyone on the Internet to login using my email address, the evil they would also have half of the credentials needed to break into my account. Guardr removes usernames from the default outgoing email texts, then combines the Realname module to help keep login usernames private. If the attacker doesn't know the username or their password, they've really got a lot of username/password combination permutations to try. Think of it like a poor man's two-factor authentication.

The Internet has several lists of modules that make Drupal sites more secure, but it's things like the pairing of modules like Realname with the removal of usernames in outgoing core emails that's what makes Guardr stand out. It's the build script. Another example - the Remove Generator module removes the META tag that displays "Drupal 7" in the HTML source of every page, but Guardr's build also removes the CHANGELOG.txt file from the root directory, another easy vector for determining both the software and the version of CMS. Why give the vulnerability scanners and penetration testers the easy way out? Let them try some Wordpress vulnerabilities first so your web application firewall and intrusion detection system can flag them well before they get to specific Drupal version exploits.

Starting with Guardr takes away a bunch of the headaches for securing your site from the start. Imagine having a password policy in place that even forces UID 1 to have a reasonably secure password or which even denies UID 1 the ability to activate the PHP input filter. Run your code through version control, test it, review it, wrap it in accountability, tag it, and don't skip the proper workflow.

Guardr's configuration keeps enough logs that you can actually go back a few weeks to review what your users have been doing, who's accountable, and pin-point events at specific times. Role watchdog module helps you track down scenarios where a user gave themselves extra access through a role change, then removed the role later - it's logged.

All this configuration and the modules to go with it are maintained by people who have studied advanced security issues, who work for companies who pursue security-conscious customers, and have proven over several years to contribute back to the Drupal security co-op.

It's my opinion that starting with Guardr and using the modules therein, sway the balance of Drupal towards being more secure without burdening administrators and users with excess annoyances and overhead. It gives you tools for maintaining uptime, auditing for accountability, injecting countermeasures for attacks, and enforcing policies to make active countermeasures less necessary.

Post categories Drupal
Categories: Drupal

Drupal Association News: Drupal Association Board Meeting this Thursday

Mon, 2014-03-10 12:25

We continue to get busier and busier at the Association, and we want to make sure that you know everything we've been up to. Although we normally hold board meetings on Wednesdays, this month we'll be hosting our meeting on Thursday to accommodate some SXSW travel.

Categories: Drupal

Mediacurrent: Meet Jonathan DeLaigle

Mon, 2014-03-10 11:25

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

As a senior developer at Mediacurrent, I do anything that is necessary to make sure that the vision of the client is executed and delivered on time and in budget.  I fill gaps wherever necessary, from architecture to module updates.  Internally, I work with the devops team to charter a new evolution of local development through the use of great tools such as Vagrant, provisioning software, and virtual machines to create an easily managed and unified local development platform. 

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

Categories: Drupal

Stanford Web Services Blog: Create a Page Title From the Views Exposed Filter Term

Mon, 2014-03-10 08:18

Suppose you're using taxomomy terms in exposed filters, and you want the resulting page to display one of the the terms as a title. Taxonomy term pages will give this to you very easily, but sometimes the taxonomy term page is not the right solution.  Here's how you can display the taxonomy term as the title of your views page.

Categories: Drupal

Commerce Guys: Guest Blog: Manufacturing Ecommerce & Product Customization

Mon, 2014-03-10 08:00

The first in a three part series of posts on "eCommerce for Manufacturers" from our Alex Salvador with Drupal Commerce Delivery Partner The Jibe

Manufacturing and wholesale is a neglected sector when it comes to optimizing for ecommerce. Most businesses use outdated online approaches to lead generation and sales in what is now a sophisticated digital retail environment. Simply providing product overviews and product order sheets online is no longer enough to make the sale. For the big, high-volume projects supplied by manufacturers, the efficiency of digital tools is invaluable.


Product Customization and Scalability   Scalability is key for enterprise level organizations with vast inventories and a large client base, in order to execute many large orders successfully. Drupal Commerce is uniquely positioned to streamline the sales experience of a large scale operation on a unified platform, avoiding the pitfalls associated with using a bolt-on store to complete sales.    Manufacturing products, when applied to retail scenarios, often come in an extensive array of variations (sizes, colours, power, speed, etc). Using the Drupal Commerce back-end, each product can be configured for these unique variations using a bulk product creation interface. Product variants are streamlined into a manageable, single product page. This eliminates the need to scroll through an endless catalogue which we often see on older, less optimal sites.

Inventory Management Drupal Commerce simplifies inventory management and speeds up product creation by providing mechanisms to display a single back-end product in a variety of contexts. In other words, it is easy to reuse a single product and to display it on its own independent product page and in product bundles – no duplication of products required.   Products that are often purchased together can be sold in a bundle as a single item. This is especially relevant to the manufacturing industry because many items have associated accessories. Bundles promote intelligent cross-sells. For example, recommending baseboards and moulding to sell with wood flooring.
  Discounting Another must have for large retailers is a flexible discounting system. Drupal Commerce uses rules to drive this functionality: website administrators can create a rule that will apply an arbitrary discount on products that match the criteria defined by the rule. For example: discount products tagged with “high performance” by 10%; or discount all products with a SKU starting with XYZ by $5. These rules allow retailers to provide bulk discounts on a large set of items, or on a very granular basis.   In conclusion, next level product customization has made manufacturing ecommerce an intuitive next step in streamlining sales systems.   Upcoming in our Ecommerce for Manufacturers series: Sales and Marketing.


Categories: Drupal

Acquia: 5 Mistakes to Avoid on your Drupal Website - Number 5: Maintenance

Mon, 2014-03-10 06:12

In the previous articles in this series, we've focused on aspects of architecture, security and performance and the choice of infrastructure.

Categories: Drupal

Powered By