Drupal Planet

Tweet

This is the second blog about the sessions druing the Drupal Developer Days in Barcelona on June 16 and 17. See here for part one. 



There will be one more post dedicated to some sessions on performance, becuase there were a lot of those. Probably because Drupal is serving more and more big, hig traffic site.

Introducing Symfony2
 

This session of Claudio Beatrice was an introduction to Symfony2. As you may all know Drupal 8 will incorporate some basic Symfony2 components, so it is wise to get up to speed with this framework. As I said it was an introduction to the framework about what it is and what filosophy it adheres. So what is Symfony?

• A reusable set of standalone decoupled cohesive php5.3 components.
• A full-stack framework.
• A request/response framework around http specs.
• A promoter of best practices, standardization and interoperability.
• An awesome community.

And why should we use a framework as Symfony? Because it removes some of the old habits in programming with a new structured way of doing things. As Claudio said: Leave stupid alone! So avoid:

• Singletons
• Tight coupling
• Untestability
• Permature optimization
• In descriptive naming
• Duplication

Symfony can help us with this. It can make you solid:

• Single responsibility
• Open/closed
• Obelisk substitution
• Interface segregation
• Dependency inversion

So what parts of symfony are coming to Drupal 8 then? For now these ones are confirmed:

• Class loader
• Service container
• Event dispatcher
• HTTP foundation
• Http kernel

But Symfony is not the only new thing in Drupal 8. A few days ago Twig was committed to Drupal 8. And people are talking about Assetic and Doctrine so keep your eyes open for all the new stuff! You can find the slides here.
 

Drupal and nodejs - beyond chat
 

NodeJS is as everybody knows very cool and totally awesome. It's one of the most popular buzz words around now. So of course we want to use it with Drupal! But why do you want to do that? What would be a practical use case? Frederik Lassen showed some possibilities.

If you want to do things as:

• handling/pulling external data-sources efficiently, (feeds, "idling", network latency)
• big uploads / big (dynamic) downloads
• sending / receiving lots of emails (pubsub)

it might be better to not use PHP. NodeJS might be the better choice. But we love Drupal so we want to leverage all the tools and power we have with that. We need to find a way to use them together. There are some initiatives to integrate both but there is no finished solution yet. There is the nodejs.module on Drupal.org. This one is tightly scoped and focuses mainly on passing messages. Then there is the node-drupal module on github. This one “consumes” Drupal from NodeJS. The downside of this module in my opinion is that it does query directly on the MySQL database. And then there is the new dnode.module. This module is a sandbox project and leverages the dnode-rpc-protocol. It's lightweight and JSON-based.

Frederik showed what you can do with this module an example with downloading large private files in Drupal. PHP sucks at this because it is blocking during the download. You can avoid this by taking the following approach:

1. big files in Drupal (managed private files)
2. Drupal validates/authorizes request
3. Drupal generates token (& "firms" it)
4. pass token + data (file path etc.) to nodejs
5. Drupal redirects to nodejs server w/ token
6. nodejs validates token
7. nodejs (manipulates &) pumps file

In that way you off-load the heavy downloading to NodeJS. The best part is, you can edit the image on the fly. Because NodeJS is streaming you can pass the image to ImageMagik and add a watermark on the fly, for example.

The cool thing about the dnode.module is that the configuration of the NodeJS servers is done in Drupal through arrays, and there is even drush integration.
Of course introducing NodeJS in the setup makes it a little more complex, but NodeJS is extremely simple and you can achieve a lot with only a few lines of code. Furthermore it's extensible. In the above example you could think of pausing downloads, throttling, callbacks on end of streams etc.

Another cool example was that of integrating third party data with subpub. He made a demo module that pushes IRC messages to a Drupal site, making a new node and showing a message to everyone on the site. The other way around worked as well. So making a new node on the side would push a message to the IRC channel. And this worked with Rules. Pretty cool. For code examples and more information see the slides.

It's stil in early development and there are challenges ahead. So if you're interested in NodeJS and Drupal keep an eye on the different projects.

Drupal Search and Solr Wizardry
 

This session was by Nick Veenhof and Matthias Hutterer about the Search API Solr module and the apachesolr module. Why are there two Solr modules on Drupal.org? And which one is better?

The thing is that the apachesolr module was there way before the Search API. This module was supported by Acquia and has a lot of Solr knowledge inside. For now only apachesolr module is supported by Acquia Search. Also a lot of performance optimization that is in the apachesolr module is not yet integrated in the Search API version. So for big, high performance sites (over 1.000.000 nodes) the old module is the only way to go. And there is no Drupal 6 version of Search API because it was build with the new architecture of Drupal 7 in mind.

But I like the new approach of Search API with pluggable back ends. I think it's a better architecture. And I think that is the general opinion in the community. Even Nick Veenhof, the maintainer of the apachesolr module said that in the long run  Search API is the way to go.

The first thing that has to be done is make the schema.xml and solrconfig.xml of the two modules compatible. And there is already a sandbox project where work is done in that area. So no more rivalry between the two but joint forces. Yeah!

For an excellent overview of the two modules and the differences between them see the slides of the presentation.
 

 

UpdateDrupal, Drupal-Planet, Dev Days

Drupal Commons provides a great framework for building community-driven sites. With topic (organic) groups at its core, Commons uses several content types to help grow communities such as

• wikis to promote collaboration among users
• polls for users to vote on
• events for users to organize meet-ups and functions

These content types are organized into Features. However as we shape Commons to match our business requirements, we inevitability need to modify these Features accordingly.

read more

Late last year, the Drupal Association announced a targeted fundraising campaign to build a fund to tackle the challenge of improving Drupal.org. Special T-shirts were offered in conjunction with Drupal Association membership, with net proceeds of those shirts set-aside for the sole purpose of improving the website at the heart of our community.

Thank You!

Thanks to your generous help, we raised over US$12,000! But we also raised awareness about the importance of Drupal.org. When the board of the association met in December they made improving Drupal.org the number one objective for 2012, and set aside additional budget to help make that happen.

A lot has happened since November 2011. Here's a quick summary of pointers to more information for those of you curious to know. To keep up to date, join the Drupal.org Improvements group and follow @drupal_org on Twitter.

read more

Next Wednesday, June 27, is a possible date for the next bugfix release of Drupal 7 core.

However, there are a number of issues tagged as 7.15 release blockers which we want to get resolved before then. Mostly these are tagged that way because they contain fixes for regressions (i.e., behavior that used to work in earlier versions of Drupal but isn't working correctly in the latest code).

All these issues have proposed patches, so what we mainly need help with is two things:

• Manual testing: You don't need to be an expert to do this; you simply need to try out the patch in various scenarios and confirm that it works. This is particularly important for issues that are known to have affected various contributed modules, since it's important to make sure those modules work correctly with the proposed fix.
• Technical reviews: If you have expertise in any of the areas of Drupal that these patches affect, reviews of the code are highly welcome.

Thanks for your help, and hopefully we can get the next Drupal 7 release out the door soon!

• Core

Sometimes its challenging to figure out how to create a good mix of fonts in a design.

Too little variation and the design is less than interesting and too many fonts creates a jumbled, unorganized look.

Increasingly our web pages are being bookmarked on iOS devices.  This is a good thing, however we had traditionally been using long titles on our pages and these were clumsy for end users when trying to store bookmarks.  Like 90,000 other websites we have chosen Page Title to solve this issue.  It works well with Tokens and Views and is probably one of those modules you should just install.

Here’s your 1:30 video http://www.youtube.com/watch?v=DMvXVJ2mbGQ

and a couple of screen shots for the really curious types.  It’s a simple module to install and use. Made by several of Drupal giants robertDouglass, JohnAlbin, and nicholasThompson.

Turn on page titles in the content type area

Enjoy refreshing page titles independent of your content title

Packt has contacted me in order to let me give away books to three participants. The details of what you have to do can be found below.

a cat from flickr

Developing for Drupal can be exciting, but without a proper approach it can also get messy.

Drupal is maturing and its developer community is growing and becoming more diverse as people from different software engineering backgrounds join. In addition, the number of modules produced is increasing, as is their complexity, especially as Drupal is required to integrate with external services and legacy systems. In the face of this it is crucial that, as a community, we ensure that the experience of coding for Drupal and the quality of the resulting modules continues to improve. If we neglect these issues, we risk negatively impacting Drupal by having poor quality modules and fewer developers wanting to join and dedicate time to the project.

While, as a community, we have specifically focused on improving the Drupal site builder and Drupal designer experience, we should ensure that we don’t forget our main constituency: Drupal developers themselves. I am not talking about core developers or leading Drupal module developers. Rather, I’m referring to the thousands of Drupal developers who day-in and day-out build and expand Drupal modules whether custom or not - and how we as a community provide tools to allow them to do this work effectively.

Furthermore, the types of tools I am referring to are not just things like more IDE plug-ins, more APIs, more documentation, more snippets and recipes; although all of these are part of the solution, we already have plenty of them.

What is missing are wider-ranging conceptual tools that describe a rational and systematic approach to choosing and gluing together all the different systems and APIs that Drupal makes available in a way that can work well, can be shared across team members, and will naturally leads to better quality code. Such tools ultimately improve the developer experience as they reduce confusion, improve confidence in the choices made, and reduce the time it takes to develop. These tools are also more scalable, since they deal with overarching concerns and should survive specific Drupal versions.

In particular, I am referring to the need for methodologies and patterns:

Methodologies: guidelines, principles and methods that we employ to go from problem definition to solution.

Patterns: proven reusable solutions to common problems.

In the following paragraphs I will touch on each and give some examples of the types of things that we as a community could be discussing and presenting to help improve module development. I will leave more specific examples and a more in-depth analysis of the issues to subsequent blog posts.

Methodologies

A methodology is a process that accompanies us from problem definition to solution and provides tools that will allow us to do this in a consistent way. Underpinning a methodology are guidelines or principles that help us determine whether an approach is right or wrong.

In the next couple of paragraphs I will give some examples of what could be valid principles to adhere to and what processes we could suggest.

Here are three sensible principles to adhere to:

Separation of concerns: are we performing actions at the right level? Is our module interacting with Drupal at the right point and through the right systems in order to do things such as access control, theming, interaction with the database, etc.?

Decoupling: is our system flexible enough? Can different components be swapped out easily? Drupal is a mixture of OO and procedural code, so what are the best strategies for building decoupled systems in this rather unorthodox environment?

Consistency: whatever approach we follow, it is important that we are consistent in how we name things, structure the location of files, and describe what we are doing. This makes it easier to share across teams.

And here are some of the processes a methodology can introduce:

1. Always describe a problem in abstract terms first and not in "drupalese." This ensures that you have a clear definition that can be shared across a team and with a client. Consider the following two statements:

A hotel owner needs to be able to display a list of available rooms with their associated descriptions given an arrival and departure date.
Vs.
I need to get all bookable unit entities and attach a field entity reference to them pointing to Room Description nodes that I can then render in Rooms view mode.

The latter makes the mistake of describing the problem in terms of a possible solution. It’s also an example of how Drupal developers all too often liberally referring to nodes, blocks, panels and views instead of the things these tools actually provide (pages, components of a page, the structure of a page, and lists of things). The former, however, describes the problem in abstract terms, making absolutely no assumptions about how it could be solved, while using clear and precise language.

2. Always describe your architecture in generic terms first, and then in specific terms. Talk about storage, data structure, and interaction with other services without worrying about how that would be implemented in Drupal. Then translate that generic architecture into one that uses specific Drupal systems. This enables you to consider alternatives and once more avoids any assumptions about what a good solution would be.

Patterns

Patterns are a well-known concept in software engineering and probably one of the most effective tools we have to educate developers about good practices in developing software.

Within the Drupal world I see the potential of identifying three different types of patterns that we can describe in generic terms, and accompanied with specific examples from modules that employ them so that developers can quickly learn how to use them.

OO Patterns: Classical OO patterns are increasingly making their way into Drupal modules (a good example being the Entity API module). We should pull these out and explain how they can be used across different modules and situations.

Drupal Patterns: There are certain patterns that seem to be Drupal-specific. An example would be the separation of a module's user interface and functionality in two different modules—such as the Views and Views UI module. We should identify more sensible solutions like these and explain how they can be easily implemented in any module.

Service Patterns: Finally, some patterns are best described in terms of web service interactions and are most suitable to describe integrations with external services and Drupal.

Next steps

What I am trying to achieve here is not to formalize the Drupal module software development process and place a straitjacket around what a developer can do and how they should do it. Methodologies and patterns often run these risks, but they can be easily avoided by ensuring that the approach is light and flexible and focuses on underlying principles rather than complicated processes.

Moving forward I would like to: focus on the following goals:

1. Document more patterns from the Drupal world and share those for comment. This is something that I started doing last year by looking at entities specifically. During a Drupalcon London presentation I talked about examples of how entities are used across different modules in order to inform how they can be used in your own modules. And just a couple of days ago at Barcelona Drupal Developer Days, I talked about the issues mentioned in this blog post, although in a more tongue-in-cheek way ;-).

2. Start working on a very lightweight methodology that we can use internally at Bluespark.

3. Identify other things such as module file naming, file structure, etc., that we could standardize within the wider community and which are not covered by the Drupal code style.

If you find these problems interesting, please join in and post your suggestions about how to improve the developer experience in terms of methodology and patterns within the Drupal world.

Tags: DrupalDrupal Planet

Project Review Wednesday Explained

Many people don't know anything about the project review process on Drupal.org. Anyone can post code to Drupal.org, but before sharing it with others in downloadable releases, new contributors must have a project reviewed by volunteers, who check for basic understanding of how Drupal works, in code, community, and especially security. Because there are too few volunteers doing these reviews, there's a long backlog. Waiting isn't a great introduction to the Drupal contributor community. So in an effort to improve this, we're starting a series of weekly posts highlighting some of the awesome projects currently in this queue, awaiting your review.

There are currently 109 new Drupal contributors awaiting review of their first project. This is a great place to contribute to the community and learn about interesting upcoming projects, for example...

Module: Basecamp

What's it Do?

The Basecamp module uses the Basecamp API to integrate the widely-used project management system with Drupal. It syncs Drupal and Basecamp accounts, displays tasks already in Basecamp, and allows creating new tasks.

Potential Uses

This project should be useful to anyone using both Drupal and Basecamp, as we do at Aten. It could also be the basis of something like Open Atrium Basecamp Import for transitioning between the two.

Look Useful? Review It!

If this sounds like something you'd like to see readily available on Drupal.org, you should review it and help make that happen.

Review It

Pro Tip: If you've never reviewed a project application before, you can find instructions for reviewers on Drupal.org and the Code Review group is happy to help more people get involved.

Drupalcamp or Regional Summit Organizers:  Susan MacPhee dcmistry

D4D. The 4th annual drupal design camp boston, the drupal community's first camp dedicated to design, takes place on sat and sun july 14-15 at the mit stata center. each year, 315+ drupalists gather in cambridge to discuss ideas and take part in interactive sessions on the future of drupal, focusing on everything from usability to technology from a design perspective.

We are thrilled to announce back-to-back awesome keynotes this year, Angela "webchick" Byron with a talk on D8 and Jared Ponchot, Creative Director of Lullabot.

Join us!

http://boston2012.design4drupal.org/

We really need sponsors too!

email us at [email protected]

• Design 4 Drupal

I was thrilled to read the story at Mobile Drupal about how ConsumerSearch is using Pronto.js to expose their huge Drupal content to their mobile application.

Pronto.js is designed to be a high performance asynchronous application framework that makes it simple to chain together components to build sophisticated application logic. It's the JS equivalent of the PHP Fortissimo framework.

read more

MongoDB's query language is good at extracting whole documents or whole elements of a document, but on its own it can't pull specific items from deeply embedded arrays, or calculate relationships between data points, or calculate aggregates. To do that, MongoDB uses an implementation of the MapReduce methodology to iterate over the dataset and extract the desired data points. Unlike SQL joins in relational databases, which essentially create a massive combined dataset and then extract pieces of it, MapReduce iterates over each document in the set, "reducing" the data piecemeal to the desired results. The name was popularized by Google, which needed to scale beyond SQL to index the web. Imagine trying to build the data structure for Facebook, with near-instantaneous calculation of the significance of every friend's friend's friend's posts, with SQL, and you see why MapReduce makes sense.

I've been using MongoDB for two years, but only in the last few months starting using MapReduce heavily. MongoDB is also introducing a new Aggregation framework in 2.1 that is supposed to simplify many operations that previously needed MapReduce. However, the latest stable release as of this writing is still 2.0.6, so Aggregation isn't officially ready for prime time (and I haven't used it yet).

This post is not meant to substitute the copious documentation and examples you can find across the web. After reading those, it still took me some time to wrap my head around the concepts, so I want to try to explain those as I came to understand them.

The Steps

A MapReduce operation consists of a map, a reduce, and optionally a finalize function. Key to understanding MapReduce is understanding what each of these functions iterates over.

Map

First, map runs for every document retrieved in the initial query passed to the operation. If you have 1000 documents and pass an empty query object, it will run 1000 times.

Inside your map function, you emit a key-value pair, where the key is whatever you want to group by (_id, author, category, etc), and the value contains whatever pieces of the document you want to pass along. The function doesn't return anything, because you can emit multiple key-values per map, but a function can only return 1 result.

The purpose of map is to extract small pieces of data from each document. For example, if you're counting articles per author, you could emit the author as the key and the number 1 as the value, to be summed in the next step.

Reduce

The reduce function then receives each of these key-value(s) pairs, for each key emitted from map, with the values in an array. Its purpose is to reduce multiple values-per-key to a single value-per-key. At the end of each iteration of your reduce function, you return (not emit this time) a single variable.

The number of times reduce runs for a given operation isn't easy to predict. (I asked about it on Stack Overflow and the consensus so far is, there's no simple formula.) Essentially reduce runs as many times as it needs to, until each key appears only once. If you emit each key only once, reduce never runs. If you emit most keys once but one special key twice, reduce will run once, getting (special key, [ value, value ]).

A rule of thumb with reduce is that the returned value's structure has to be the same as the structure emitted from map. If you emit an object as the value from map, every key in that object has to be present in the object returned from reduce, and vice-versa. If you return an integer from map, return an integer from reduce, and so on. The basic reason is that (as noted above), reduce shouldn't be necessary if a key only appears once. The results of an entire map-reduce operation, run back through the same operation, should return the same results (that way huge operations can be sharded and map/reduced many times). And the output of any given reduce function, plugged back into reduce (as a single-item array), needs to return the same value as went in. (In CS lingo, reduce has to be idempotent. The documentation explains this in more technical detail.)

Here's a simple JS test, using Node.js' assertion API, to verify this. To use it, have your mapReduce operation export their methods for a separate test script to import and test:

// this should export the map, reduce, [finalize] functions passed to MongoDB.
var mr = require('./mapreduce-query');
 
// override emit() to capture locally
var emitted = [];
    emit = function(key, val) {
      emitted.push({key:key, value:val});
    };
 
// reduce input should be same as output for a single object
// dummyItems can be fake or loaded from DB
mr.map.call(dummyItems[0]);
 
var reduceRes = mr.reduce(emitted[0].key, [ emitted[0].value ]);
assert.deepEqual(reduceRes, emitted[0].value, 'reduce is idempotent');

A simple MapReduce example is to count the number of posts per author. So in map you could emit('author name', 1) for each document, then in reduce loop over each value and add it to a total. Make sure reduce is adding the actual number in the value, not just 1, because that won't be idempotent. Similarly, you can't just return values.length and assume each value represents 1 document.

Finalize

Now you have a single reduced value per key, which get run through the finalize function once per key.

To understand finalize, consider that this is essentially the same as not having a finalize function at all:

var finalize = function(key, value) {
  return value;
}

finalize is not necessary in every MapReduce operation, but it's very useful, for example, for calculating averages. You can't calculate the average in reduce because it can run multiple times per key, so each iteration doesn't have enough data to calculate with.

The final results returned from the operation will have one value per key, as returned from finalize if it exists, or from reduce if finalize doesn't exist.

MapReduce in PHP and Drupal

The MongoDB library for PHP does not include any special functions for MapReduce. They can be run simply as a generic command, but that takes a lot of code. I found a MongoDB-MapReduce-PHP library on Github which makes it easier. It works, but hasn't been updated in two years, so I forked the library and created my own version with what I think are some improvements.

The original library by infynyxx created an abstract class XMongoCollection that was meant to be sub-classed for every collection. I found it more useful to make XMongoCollection directly instantiable, as an extended replacement for the basic MongoCollection class. I added a mapReduceData method which returns the data from the MapReduce operation. For my Drupal application, I added a mapReduceDrupal method which wraps the results and error handling in Drupal API functions.

I could then load every collection with XMongoCollection and run mapReduce operations on it directly, like any other query. Note that the actual functions passed to MongoDB are still written in Javascript. For example:

// (this should be statically cached in a separate function)
$mongo = new Mongo($server_name);      // connection
$mongodb = $mongo->selectDB($db_name); // MongoDB instance
 
// use the new XMongoCollection class. make it available with an __autoloader.
$collection = new XMongoCollection($mongodb, $collection_name);
 
$map = <<<MAP
  function() {
    // doc is 'this'
    emit(this.category, 1);
  }
MAP;
 
$reduce = <<<REDUCE
  function(key, vals) {
    // have `variable` here passed in `setScope`
    return something;
  }
REDUCE;
 
$mr = new MongoMapReduce($map, $reduce, array( /* limit initial document set with a query here */ ));
 
// optionally pass variables to the functions. (e.g. to apply user-specified filters)
$mr->setScope(array('variable' => $variable));
 
// 2nd param becomes the temporary collection name, so tmp_mapreduce_example. 
// (This is a little messy and could be improved. Stated limitation of v1.8+ not supporting "inline" results is not entirely clear.)
// 3rd param is $collapse_value, see code
$result = $collection->mapReduceData($mr, 'example', FALSE);

MapReduce in Node.js

The MongoDB-Native driver for Node.js, now an official 10Gen-sponsored project, includes a collection.mapReduce() method. The syntax is like this:

 
var db = new mongodb.Db(dbName, new mongodb.Server(mongoHost, mongoPort, {}));
db.open(function(error, dbClient) {
  if (error) throw error;  
  dbClient.collection(collectionName, function(err, collection) {
    collection.mapReduce(map, reduce, { 
        out : { inline : 1 },
        query: { ... },     // limit the initial set (optional)
        finalize: finalize,  // function (optional)
        verbose: true        // include stats
      },
      function(error, results, stats) {   // stats provided by verbose
        // ...
      }
    });
  });
});

It's mostly similar to the command-line syntax, except in the CLI, the results are returned from the mapReduce function, while in Node.js they are passed (asynchronously) to the callback.

MapReduce in Mongoose

Mongoose is a modeling layer on top of the MongoDB-native Node.js driver, and in the latest 2.x release does not have its own support for MapReduce. (It's supposed to be coming in 3.x.) But the underlying collection is still available:

var db = mongoose.connect('mongodb://dbHost/dbName');
// (db.connection.db is the native MongoDB driver)
 
// build a model (`Book` is a schema object)
// model is called 'Book' but collection is 'books'
mongoose.model('Book', Book, 'books');
 
...
 
var Book = db.model('Book');
Book.collection.mapReduce(...);

(I actually think this is a case of Mongoose being better without its own abstraction on top of the existing driver, so I hope the new release doesn't make it more complex.)

In sum

I initially found MapReduce very confusing, so hopefully this helps clarify rather than increase the confusion. Please write in the comments below if I've misstated or mixed up anything above.

Today we're going to look at a use of Drupal that is a bit outside the norm. Instead of the usual business website, corporate blog, or news magazine site, let's look at a building a presentation tool. How or why would you use such a thing? Well, in a world where the Powerpoint or document-based presentations and proposals are rampant, sometimes you need to do something to stand out a bit.

read more

Last week, we announced that we had put together documentation and a demo site for Julio, our distribution for schools, school districts, and academic departments for K-12 and higher education.

As we have been building school web sites over the years, a common feature request we received was: "I want people to be able to put content in one place on the web site, but only that place." Translated, this meant that they wanted to decentralize control of the web site, and allow people freedom within the areas where they are responsible.

So, for example, the Football coach can put anything she wants into the Football team section of the web site, but she cannot put anything into the any other place.

As Drupal has evolved over the years (for us, starting in 4.5) we solved this in many different ways. However, starting midway through D5, and with some consistency in D6, we began using Organic Groups as the tool to address this functional requirement. In D5 and D6, this involved overriding many OG features on a pretty regular basis, as the default settings provided options within the user interface (UI) that ranged from distracting to scary, depending on the end user and their privileges within the site.

For Drupal 7, Organic Groups was rewritten from the ground up. To understate things, this was an enormous undertaking. The lead developer on this is Amitai Burstein from Gizra, and on this rewrite, he nailed it. The rewrite makes smart use of entities in D7, and, last November, Amitai made the key decision to simplify Organic Groups by deprecating the OG Group entity. This change has many benefits, and one of the more immediately tangible benefits is that the views integration is now much cleaner, which simplifies the work of site builders. We had been working with OG in D7 for about a year when Amitai announced his proposed changes, and the direction he was talking about dovetailed pretty cleanly with our experiences up to that point. It's also worth noting that Amitai's approach to maintaining OG is pretty incredible; the work required for the initial rewrite of Organic Groups for Drupal 7 was considerable, and the rewrite for the 2.x branch was no small feat either. It would have been easy to stick with the original approach in the 7.x-1.x branch, but Amitai made the call to simplify Organic Groups to make it easier to use, and that's a great choice for all of us in the community.

In addition to sponsoring some of the original development, we have tried to be pretty active in the OG issue queue, helping with patches and testing as part of our ongoing work. We have been working with the 2.x branch of OG since late January, 2012, and it has been incredibly useful. In D5 and D6, delivering a site built on top of OG required putting a significant amount of work into UI tweaks. The core functionality of OG was (and remains) incredibly flexible, but the rewrite simplifies the process of delivering a site that has powerful and extensible community sections while being easy to use. From a site maintainer/builder perspective, one of the main improvements in the D7 version of OG is the ability to provide rights on a per-group basis.

Ongoing development and improvements are taking place in the 2.x branch; if you have been waiting to test this out, well, what are you waiting for? Grab a copy, and start testing, now! Yes now! What are you waiting for?

For more information and background on Organic Groups, check out Amitai going over some of the details from his DrupalCon Denver session: OG7 - Pride and Prejudice.

Image Credit: "grilled sugar snap peas" taken by woodleywonderworks, published under an Attribution Non-Commercial No Derivatives license.

Clients often require that a site pass a validation tool. I'll detail some tips and tricks for getting a Drupal 7 site to validate with HTML5 and RDFa.

ConsumerSearch (part of About.com and the New York Times) is hiring! We are looking for excellent software engineers who want to work in a technology agnostic environment!

In February 2012 our team at ConsumerSearch launched the ConsumerSearch Reviews iOS app. This handsome app helps you during your product purchase by providing extensive product reviews, comparisons, pricing information and online and local store product availability. Try it out during your next purchase -- you'll be surprised how much time you'll save in researching the best products.

Searching for products is possible by keyword search or barcode scanner. We are very proud of our first app that has already gone through several updates and has received positive user reviews.

cs-iphone-screen-1

read more

We've tried a lot of project management systems over the years. In some way, they have always seemed lacking, confusing or just a pain in the rear end. If they had good tools for project managers, they were confusing to developers. If they were useful for developers, designers complained about the eye-sores. No one system ever seemed to satisfy the team.

We recently started using GitHub for project management after the developers started raving about how much they loved it for managing code. To our surprise, GitHub has proven a solid option for project management. Our designers have even started using it for some of their projects, which I think says something about GitHub's aesthetics. With a little bit of something for each role, GitHub is starting to come out on top as the tool of choice for hosting code, managing projects, and facilitating project communication.

Content management coupled with content strategies are the perfect 1-2 punch for the ultimate results oriented website.

The biggest revolution in the history of marketing is in full swing. If you are in business and you are on the web, you are in the publishing business. You need to publish great content that attracts audiences and gets them excited about your brand – and, oh yeah, gets them telling their friends.

read more

Planning to set-up new development environment, but haven't yet quite decided between MAMP and installing Apache and MySQL locally?
There is also 3rd option, run LAMP stack virtuallized locally.

Benefits of running your XAMP (apache, mysql & php) stack in virtualbox has many benefits.
- Like having same environment as in production.
- All libraries are not (easily) available to all platforms.
- Freeing resources is easy, just shutdown your virtualmachine.