Planet Drupal

Last night, I was sent an email from a friend whose email was hacked. I am seeing a lot of that in the past year or 2, so I thought I would share my response to help train folks into better password habits. And seriously, I think that it would be a good practice to install the Password policy module on all your Drupal sites, to help enforce better habits for everyone. That module can be configured to force passwords similar to what I described here, and much more, such as requiring that passwords be periodically changed.

Dear (Friend),

I got those emails, it does look like it's possible that your email was hacked. You did the right thing, by changing your password. However, we need to do a few other things to try to minimize the damage.

1st, it is entirely possible, in fact probable, that they did not actually hack your computer. Identity theft is rampant, and in this interconnected world, does not even require any access to your computer.

That said, it is still possible that your computer has a virus. That would be the 1st thing to check. If you have an antivirus program, you need to ensure that it has been updated. That may require a fee, if you are using a paid antivirus program subscription.

If you do not have an antivirus program, I would highly suggest Avast, which I have been using for years. You can safely use the free version of it, as it is not crippled in any way from the paid version. You can find it at http://avast.com.

After, and only after you have scanned your computer for viruses, then you can get on with the business of securing your accounts against identity theft.

You will need to change your email password yet again, I am sorry to say. Additionally, you will want to change the security questions, which I believe that Yahoo will ask.

Treat the security questions as passwords in themselves, as these are most commonly used to hack in to an email account. That means that you should not use anything resembling what they actually ask for, such as your mother's maiden name or your 1st dog. That can be discovered with Google these days.

Next, a word about passwords. As you may have heard by now, you need to have a password that cannot be guessed. Unfortunately, that is not enough. You also need to have a mix of cases, at least one number, and a special character, such as a punctuation mark. Additionally, you need to have a different password for every account that you have.

I cannot stress that last paragraph enough. It is too easy for a hacker to get into, say an account with a forum, and use that to get into your Wells Fargo account. For instance, to use myself as an example, about 6 years ago, I accidentally broadcasted my password into a chat room, and about 2 weeks later, I got an email from a woman wondering where her Gucci bag was that she had purchased from my eBay account. It turns out that someone in Russia had hacked into my eBay account and listed about 100 fake Gucci bags.

I know that this sounds daunting, but it is necessary. Fortunately, you can use what is called an algorithm to remember your dozens of new passwords that you'll need to create. You can use that to create a new password for any site, and you will always remember it. Additionally, it will be secure for all intents and purposes.

Basically, you will choose a passphrase, modify and, and apply it to any site. For example, and please do not use this example, let say you choose "apple" as your passphrase. We will modify that to have a punctuation mark and a number, so that it will be "@pp1E". Then you would append that to the 1st 4 characters of whatever site that you are creating an account for. For instance, for eBay, your password would be "ebay@pp1E", and your Hotmail account would be "hotm@pp1E". This will make your passwords immune to so-called dictionary attacks, where they try to figure out your password by entering random words from the dictionary.

Much easier to remember, right? And for your financial accounts, I would suggest creating yet another algorithm, as an extra layer of protection.

You can apply this same idea to those security questions that you see everywhere. Basically, you do not want to actually use a real answer, because it is far too easy for a determined hacker to read about that experience in your 1st car that you posted in Facebook. Instead, treat them with the same respect as your passwords. For instance, you might create an algorithm with your grandmother's cat's name that you apply to a site's question for referring to your own pet.

Once you have done this, you should be fairly safe.

Good luck.

As a postscript, and not to deflect responsibility, it is entirely possible that your email was not the one hacked. It may have been a more intelligent hack, where someone hacked into someone else's Facebook account, for example. From there, they may have grabbed the contacts and spoofed an email from it, sending spam and making it look like it came from yours. This is a more insidious form of identity theft that is becoming more common. Still, the best defense is to secure your passwords.

read more

A short one because not a lot of time has passed but two commits worths a quck post: Aggregator support for entity queries has been committed and also we have an aptly named 'drivers' directory database and other drivers can live. I will work on getting drush and update.module support for the db drivers there.

This post outlines the steps required to create your own custom tokens in Drupal.

When writing the recent releases of the Copyright Block module, I used tokens to allow the user to edit and customise their copyright message and place the copyright_message:dates token in the desired position. When the block is rendered, the token is replaced by the necessary dates.

We will be using the fictional foo module to demonstrate this.

Requirements

• Token module

Recommended

• Devel module - useful to run dpm() and kpr() functions
• Copyright Block module - 7.x-2.x and 6.x-1.x use tokens, handy as a reference

Implementing hook_token_info().

The first thing that we need to do is define the new token type and/or the token itself, along with it's descriptive text. To view the existing tokens and types, use dpm(token_get_info());, assuming that you have the Devel module installed.

/** * Implements hook_token_info(). */ function foo_token_info() { $info = array(); // Add any new tokens. $info['tokens']['foo']['bar'] = t('This is my new bar token within the foo type.'); // Return them. return $info; }

In this case, the token called bar resides within the foo group.

If I needed to add a new token within an existing token type, such as 'node', the syntax would be $info['tokens']['node']['bar'].

Implementing hook_tokens().

Now that the Token module is aware of our new token, we now need to determine what the token is replaced with. This is done using hook_tokens(). Here is the basic code needed for an implementation:

/** * Implements hook_tokens(). */ function foo_tokens($type, $tokens, array $data = array(), array $options = array()) { $replacements = array(); // Code goes here... // Return the replacements. return $replacements; }

The first thing to check for is the type of token using an if() function, as this could be an existing type like 'node', 'user' or 'site', or a custom token type like 'foo'. Once we're sure that we're looking at the right type(s), we can use foreach ($tokens as $name => $original) to loop through each of the available tokens using a switch(). For each token, you can perform some logic to work out the replacement text and then add it into the replacements array using $replacements[$original] = $new;.

/** * Implements hook_tokens(). */ function foo_tokens($type, $tokens, array $data = array(), array $options = array()) { $replacements = array(); // The first thing that we're going to check for is the type of token - node, // user etc... if ($type == 'foo') { // Loop through each of the available tokens. foreach ($tokens as $name => $original) { // Find the desired token by name switch ($name) { case 'bar': $new = ''; // Work out the value of $new... // Add the new value into the replacements array. $replacements[$original] = $new; break; } } } // Return the replacements. return $replacements; } Example

An example from Copyright Block module:

/** * Implements hook_tokens(). */ function copyright_block_tokens($type, $tokens, array $data = array(), array $options = array()) { $replacements = array(); if ($type == 'copyright_statement') { foreach ($tokens as $name => $original) { switch ($name) { case 'dates': $start_year = variable_get('copyright_block_start_year', date('Y')); $current_year = date('Y'); $replacements[$original] = $start_year < $current_year ? $start_year . '-' . $current_year : $start_year; break; } } } return $replacements; } Using token_replace().

With everything defined, all that we now need to do is pass some text through the token_replace() function to replace it with the values defined within hook_token().

$a = t('Something'); $b = token_replace($a); // This would use any token type - node, user etc. $c = token_replace($a, array('foo')); // This would only use foo tokens.

From the Rules project page:
The rules module allows site administrators to define conditionally executed actions based on occurring events (known as reactive or ECA rules). It's a replacement with more features for the trigger module in core[.]

read more

For the first time ever, DrupalCon is featuring a User Experience Track. We will have 13 sessions discussing User Experience Methods, tools and philosophies.

Today, Friday February 15th, is the last day to submit sessions for DrupalCon. Get your sessions in!

UX Track Featured Speakers

We already have 3 Featured speakers planned for the track:

• Design Ops: A UX Workflow for 2013 - Chris Blow, Meedan, User Experience Lead
• What Users Want (Or Why Webpages are Dead) - Nam Ho Park, ForumOne Communications, Regional Director for West Coast / Director of Mobile Services
• Responsive Discovery: The Underpants of a Great Web Project - Steve Fisher, Director of User Experience, Yellow Pencil

Here is our focus for the User Experience track.

The User Experience process is key to the success of the development of websites and web applications. From user research, interviews and analytics, we learn what the user actually wants and needs; not what we assume they want. At this year's DrupalCon we present a new User Experience track to show our community's dedication to user needs.

Main Themes

• Explaining what user experience is and why it’s important
• UX for mobile and tablet, Responsive UX
• Speeding up the design process using UX tools and techniques
• UX for multilingual sites - especially RTL
• Content Strategy

Audience

• UX professionals - Drupal
• UX professionals outside of Drupal
• Backend devs that are interested in UX
• Frontend devs interested in UX

Episode Number:  109 Post Topics:  Drupal Blocks Contrib Drupal 7 Layout Tools Drupal Planet Site Administration

The Drupal 7 Block Up Down module allows easy management of your blocks from the front end of your site (rather than having to go to the Administer Blocks page).

In this episode you will learn:

• What the Block Up Down module is used for
• How to use the Block Up Down module to re-position or disable blocks on your Drupal site

Thanks to Drupalize.me for sponsoring today's episode.

DDoD Video: 

I was super excited last year when I heard a DrupalCon was to be thrown in Sydney, Australia in 2013. At the time, my wife and I recently found out she had been accepted into a teachers' exchange program and we were going to be living in Adelaide, SA for the year. Win win! This happy coincedence cut the travel time from 22 hrs. down to 2 hrs.—making the idea of attending the first DrupalCon in the southern hemisphere a realistic one. So last week I found myself on Coogee Beach with roughly 400 hundred Drupal comrades.

Location, Location, Location. Coogee Beach was the most spectacular location for any Drupal event I've been to. (Sorry Auraria Higher Education Campus.) The landscape was breathtaking. Unfortunately, I didn't have the time to explore. After all, I wasn't there to get a sun tan. I had things to learn and people to meet.

As with any Drupal event, I was surrounded by a fantastic community of developers eager to share their knowledge and experiences with others. While sessions are the main attraction, it's the conversations and relationships that you only get from attending the live event that appeal to me most. Being on the other side of the globe, there were fewer familiar faces than usual. Not a bad thing as it presented a great opportunity to make new friends.

This is not to say the sessions aren't worth the price of admission. I made it to quite a few this time. All were great but there were two in particular that struck a chord with me. Luke Brooker's Improving your Responsive Workflow with Style Guides and Jeff Eaton's Building for the Post-mobile World.

Style Guides are something we've been working into our evolving site creation process for a while now. Last year, Ken spoke about utilizing style guides in Photoshop as an alternative to a series of full page comps. Luke's session focused on HTML and CSS based style guides utilizing Kalei Style Guide. Kalei is a JS based dynamic style guide generator that automatically builds Bootstrap like documentation based on Markdown-formatted CSS comments from a stylesheet. This has a positive side effect of forcing front-end developers to comment their code—extremely useful when working with teams. I had some great conversations with Luke about this approach and his vision for it. I'm super pumped about working this into our process!

Jeff's talk followed the same themes described in Karen McGrane's Content Strategy for Mobile. I like to think of it as 'Responsive Information Architecture' in which content is structured in such a way that any site or app can pull the bits that are appropriate for its use case from a single conical source. He points out that Drupal's architecture is already poised to take advantage of such an IA strategy. It's just a matter of how we, as developers, take advantage of the tools in our site creation process.

Having served as a track chair for DrupalCon Denver and currently as global-chair for front-end in Portland, these are the types of sessions I find perfect fits for DrupalCon. Taking ideas from the broader web development community and applying them to Drupal. After all, most attendees are already (or about to be) invested in the Drupal platform and this is the type of content they won't get at most other conferences.

Speaking of which. Session submissions for Portland close at 11:59pm PST Fed. 15th. That's Tonight!! Please get your proposals in right away. Drupal events are only as good as the community makes them. A shining example of this is Mr. Snow. Snow set the bar extremely high for track chairs. While most track chairs (I'm guilty of this) consider their work mostly over when the conference starts and leave the speakers to fend for themselves, Snow mc'd every single front-end session, giving each speaker a personal introduction and facilitating Q&A afterward. It's this type of effort and ownership that the local community can contribute to DrupalCon. Well done Mr. Snow!

The Saturday sprint was an amazing experience. This was the first event I had made plans to stick around for the code sprint and it won't be the last. It's a great opportunity to get involved with core and help steer the direction of Drupal. Again, the location was amazing. It was a bit toasty in the official sprint room, but outside the internet connection was just as good as the ocean view.

All in all it was a great conference. My only complaint was that it went by too quickly. I'd like to say thanks to Aten for sponsoring DrupalCon and sending me. On to Portland!

Mark Sonnabaum, performance engineer at Acquia, comes to open source on a straighter path than some ... despite his university degree being in music composition! He was a systems administrator at the University of North Texas and chose Drupal – in the Drupal 4 era – as the replacement for a mish-mash of legacy, static systems at the university. Today, he is a contributor who has made significant improvements to how Drupal performs for all of us.

mark_sonnabaum_final.mp3

A professor of mine was fond of saying, “We’re not building bridges, people.” His point was that the process required to build a bridge—extensive planning, budgeting and documentation, followed by execution—has been misused by the software development industry.

My professor saw engineering as a science and software development as an art, and he believed the processes to build each should be different. The result of all that planning and budgeting can be an expensive websites with irrelevant or useless features. Web culture changes often and fast, but bridge culture is predictable.

Unless you’re a fearsome troll hiding under bridges, waiting for a goat lunch. In that case, you have some reading to do. Here, borrow my copy of Three Billy Goats Gruff. You’re welcome.

The Agile development approach has been gaining traction in the last few years because it aims to address the biggest factors tripping up projects. Agile is a different way to manage project teams and the processes that govern them. Agile promotes working software over documentation, customer engagement over contract negotiation, and a fluid development processes over a strict plan and timeline.

In a traditional model, change requests are a burden on project teams and a leading cause of project failures. A minor mistake can have a catastrophic impact on timelines and budget.

In other words, don’t believe those small goats: a small lunch is better than dead.

Agile avoids this by favouring short, focused, iterative development cycles. Because Agile is designed to adapt, project teams can evolve with the needs of a project and changing requirements are welcome.

Say you decide to switch things up by eating the first goat that comes along, or—even better—all the goats (you know, instead of ending up on a milk carton): Agile is flexible enough to to accommodate this.

At ImageX we start the Agile process with clients by creating a Minimum Viable Product (MVP). This isn’t the “least we can get away with,” but a set of features to satisfy core project goals: the minimum required for it to be successful.

One small goat should about do it, hey?

This gets the product into the client’s hands faster. It also allows clients and stakeholders to assess the actual product (not a diagram or description) and its usefulness sooner in the process.

When features and functionality of the MVP have been set, the remaining features and functionality are placed in a queue, prioritized by importance. These features are designed, documented and developed in the order they appear in the queue.

Once the MVP is finished, work starts on the development queue. Should a new idea come along, it can be placed in the queue without disrupting the development plan. Since development cycles in Agile are short and focused (and relatively inexpensive), the impact of change is minimized.

Now you can troll your lunch and eat it too!

The management of Agile projects requires a skilled team, a project manager with strong communication abilities, and a client willing and able to be involved in the process. Let’s get started!

Ma-a-a-a.

After more than two years of development, our team at epiqo is excited to announce Recruiter 1.0 - the final release of our e-recruitment solution based on Drupal 7. Go and download the fresh and shiny Recruiter 1.0 from drupal.org or read further, as I'd like to share some insights on how we have been creating the distribution as our base product over the last years.

Step 1: Creating a fresh platform for extensible e-recruitment websites based on Drupal 7

At epiqo, we started developing Recruiter early on by September 2010. As one of the very first Drupal 7 based distributions, short time after Drupal 7 was released in January 2011, our first beta of Recruiter was announced on March 4th, 2011. Creating the Recruiter distribution early on by that time involved figuring out the right feature-driven development workflow and working on fundamental Drupal contrib modules. Entity API, Profile2, Field-collection, the Search API, Rules, the Rules Autotagger module and a Term-level field is just a brief exerpt of the great variety of modules that have been sponsored during the creating of the Recruiter distribution.

Step 2: Stabilizing the Recruiter platform

Since our first beta release, we have been continously improving and expanding the Recruiter distribution which forms the basis of all our job boards. A lot of stabilizing happenend under the hood like figuring out the optimum of default field settings for job postings and our detailed resume feature. Over time, we also added a number of additional features to Recruiter like job applications, a content admin role, a registration feature and the ability to switch between Search API Database and Solr backends. It took a while until the drupal.org distribution infrastructure was able to build full releases, so since beta7 we are able to host them entirely on drupal.org.

Step 3: Adding Cloudy, a Omega 4.x responsive base theme

Back in early 2011, shipping Recruiter with a red Bartik theme was kind of cool because were showcasing the new and fresh Drupal 7. Frontend web design has evolved dramatically since then, so we decided to create a modern, new base theme for our Recruiter based sites. Together with Sebastian Siemssen we worked on his complete rewrite of the Omega 4 base theme. In summer 2012, we relaunched our demonstration platform DrupalJobs just in time for DrupalCon Munich. Since then, our Recruiter-based job portals are based on our mobile-first and reponsive base theme Cloudy that leverages Sass, Compass and the Susy grid.

With the final release of Recruiter, we are glad to include the fully open-sourced Cloudy base theme within the distribution. Omega 4 is moving towards a stable release. For more information, consult the issue queue and or find a in-depth discussion in the comments of Amazee Labs Blog post on the new face of Omega 4.

Step 4: Finalizing the Recruiter distribution with demo content

So far, Recruiter was a great platform technology-wise, but after installing the distribution you didn't see anything. We have now added a Recruiter Demo feature to provide a good starting point when evaluating the Recruiter distribution. The installer will automatically import a set of demo data, including job postings and a complete applicant resumes. Similar to other modern Drupal distributions, Recruiter now provides a nice out-of-the-box experience that show cases the essential functionality provided by our distribution. 

simplytest.me is a great way for evaluating Drupal projects online. Take a quick Recruiter 1.0 test ride using the direct link: http://simplytest.me/project/recruiter/7.x-1.0

Conclusions and outlook

Recruiter is a Drupal distribution that focuses on a specific nieche - job portals. By leveraging and actively contributing to the Drupal ecosystem we have found a great way of building on the shoulders of giants. The great amount of extension modules for Drupal is the perfect fit for creating flexible and extensible e-Recruitment solutions. epiqo also provides premium-features built on top of Recruiter and we offer Recruiter consultancy from job board architecture over implementation details to related module development. Come and contact us to discuss how Recruiter can help bring success to your job board project. 

 

Tags: drupalplanetomega

• Share on Facebook
• Tweet Widget

Before this gets too much traction: We didn't add Twig to core because Symfony uses it. I know it became popular to add anything that Symfony does based on the features it provides. Now, I started the Twig movement and I don't work like that. In fact, I feel frustrated and somewhat insulted that anyone presumes I would operate like that. My No1 priority is security. It always was. It always will be. To quote the original issue:

Some have proposed using Twig. We get security. We are not doing our own custom things. The skills learned would be usable not just Twig using systems, there's Liquid for Ruby as well. (As a bonus this also makes Crell happy and we didn't even list him in the first place.) Some are against using a non-PHP templating language in the first place because, well, we have PHP running already why put something on top? And the reason is, mostly, security. (We could argue that because we do not need to generate every variable under the sun in preprocess in some cases there's actually might be some speed benefit but this is a footnote and something so usage specific that it's not really up to debate) Another concern was IDE integration, but look decent IDE integration is already there.

And No2 is making sure the relevant stakeholders get what they want. I reached out to themers often (there was a lot more than interactions but I only found these two quickly). I know one thing for sure: we developers have no idea about what themers need.

In general, I am fairly sure that I am very, very unsure whether anything we do in core fits the need of the users at large and I feel frightened beyond anything that we throw out without consideration all the code that we might have polished through the years and replace it with what's basically an unknown. That's my biggest gripe with this go-all-out-Symfony thing: I do not know and I hate not knowing. It might continue the fantastic growth of Drupal. It might kill it. I do not know and I am scared. I spent a significant portion of my life (literally, more than 20% of my whole lifetime) on helping Drupal to get where it is now and not knowing what the future holds is a very, very, very scary prospect. Some of the frustration from that might surface in anti Symfony statements from time to time but please understand this behind it. Thanks :)

Image Link Formatter is a really handy module that allows you to have a link behind the images you upload via the Drupal core image field. It does so by combining it with another contrib module: Link.

Most e-commerce websites offer a checkout process indicator, the indicator often appears at the top of a checkout page and lets a user know which checkout process they are currently on. For example, an indicator should display each major checkout process such as checkout, review and complete. In this day and age, everyone wants to know how much effort is required to complete something and an indicator helps users gauge the effort required. Adding an indicator to a website that uses Drupal Commerce is very easy thanks to the Commerce Checkout Progress module.

In this tutorial, I'll show you how to setup the Commerce Checkout Progress module on your Drupal Commerce website.

 

I am so glad that my Dear friend Ashwini broke the ice for us. And I would

like to thank him for the same, I followed the steps and Bingo!!! 

I have Drupal on my machine. I  walked little further and quick look over changes.

 

Most striking changes I found :   

 

1) The biggest bang, if you haven't heard of is "Symfony meets Drupal 8"

Yes, that is correct! Drupal 8 has adopted many low level components like 

HttpFoundation, HttpKernel, Routing, EventDispatcher, DependencyInjection, and ClassLoader from 

Symfony to achieve more structured code & semantics with the help of OOPs,

which community was waiting a while.

 

According to me  Drupal will achive the same objects transmission through out

the flow with better encapsulation.

 

"By adopting HttpKernel, Drupal and Symfony projects will become more interoperable. 

It means that you will be able to easily integrate your custom Symfony applications with Drupal... and vice-versa."

- Courtesy Fabien Potencier, www.symfony.com (http://symfony.com/blog/symfony2-meets-drupal-8) 

 

2) New drupal 8 has Twig as template engine. Personally I was waiting for such change in drupal after

working for last 5 years. It was always a wish to have template engine as a part of core to speed up the 

performance. I hope it will be fast, secure & flexible as it is mentioned on http://twig.sensiolabs.org/.

Thanks to Fabien Potencier. But I guess this is also because Symfony2 has it.

 

3) The next thing made a tick was the folder structure & separations. Now drupal has structure like

core, modules, profiles, sites, themes and index level files with ROBOT.txt. The core has drupal's

traditional file & folder structure but there you can find additional folder called as "vendor".

This is the folder where symfony components resides. You can find 

Symfony classes : 

Symfony framework classes

Twig :

Twig is a modern template engine for PHP 

Composer :

Composer is a tool for dependency management in PHP. It allows you to declare the dependent 

libraries your project needs and it will install them in your project for you.

Doctrine :

The Doctrine Project (or Doctrine) is a set of PHP libraries primarily focused on providing 

persistence services and related functionality.

EasyRDF :

A PHP library designed to make it easy to consume and produce RDF.

Guzzle :

Guzzle takes the pain out of sending HTTP requests and the redundancy out of creating web service clients.

 

By bunch of all these, drupl 8 was never powerful than this.

 

4) While administration I did not find many changes than admin menu structure. But there are some modules

included in core than drupal7. 

Majorly, 

Views is part of core now. 

ckEditor is in there, which was surprise to me as I always prefered TinyMCE for Drupal sites. 

Language module is included in core for i18n.

 

With curasity I tried to have contents in two differant languages and it is user friendly.

Though personally I feel adding plugins in CKEditor is pain and needs improvements.

 

5) Last but not the least for now, documentation of hooks available for Drupal 8 is ready before 

it is stabalizing core. It is at http://api.drupal.org/api/drupal/core!includes!module.inc/group/hooks/8. 

And I am happy that it will really help community to conribute back to core modules/themes, core & contributed 

modules/themes.

 

I will try to explore more and will try to share more in upcoming posts.

I'm happy to announce that Lee Hunter has been appointed as the new Documentation Team Lead for Drupal. Lee has been a long term member of Drupal's Documentation Team, and has been a technical editor for thirteen years of his professional career. To read about Lee's vision for Drupal's documentation, please check out his announcement blog post. The short version is that he will focus primarily on coordinating the effort to document Drupal 8 and exploring ways of making Drupal a more effective tool for technical communication.

From 2010 to 2011 the Drupal Documentation Team was led by Jennifer Hodgdon (jhodgdon) and Ariane Khachatourians (arianek), and up until July of year just Jennifer. Without their leadership and effort, tens of thousands of people would have faced great challenges in using Drupal. I'd like to thank Jennifer and Ariane for the tremendous effort that they put into the documentation team.

Documentation is one of the most important aspects of Drupal, and not one that we should take for granted. Please join me tanking Jennifer and Ariane for their work, and in welcoming Lee as Drupal's new Documentation Team Lead.

With Mobile in the forefront of digital government initiatives, laying the foundation for a mobile solution for the Department of Energy (DOE) was a priority. With this in mind, we wanted to meet this challenge for DOE in a way that was efficient and affordable.

PHP's command line interface doesn't respect the max_execution_time limit within your php.ini settings. This can be both a blessing and a curse (but more often the latter). There are some drush scripts that I run concurrently for batch operations that I want to make sure don't run away from me, because they perform database operations and network calls, and can sometimes slow down and block other operations.

Can you tell when the batch got backlogged? CPU usage spiked to 20, and threads went from 100 to 400.

I found that some large batch operations (where there are hundreds of thousands of items to work on) would hold the server hostage and cause a major slowdown, and when I went to the command line and ran:

At Four Kitchens, we have done quite a bit of work within the education industry. As we began looking into expanding our footprint within the education web technology space, we discovered that there was a corresponding need in the marketplace waiting to be filled; especially within higher ed. Universities and higher ed institutions continue to look for ways to cut costs, deliver content more effectively and easily, ease administration, and facilitate online learning/training. While several (open source and proprietary) solutions exist, there seems to be little clarity into what the options are, and perhaps more importantly, what the possibilities may be.

So we set out on a quest to understand the “lay of the land” a little better. Broadly speaking, there are three categories of solutions:

Learning Management Systems (LMS)

Succinctly, an LMS is a software application for the administration, documentation, tracking, reporting, and delivery of education courses or training programs. There are an incredible number of LMSs available to choose from; some proprietary, some open source, some completely custom built, some entirely off the shelf. Traditionally, LMSs have focused more on content delivery than content management, which is part of the reason we found that almost no academic institution is entirely happy with the LMS they chose to implement. Said another way, a complete solution for an academic institution involves the best aspects of CMS and LMS, and traditional LMSs have been very poor at CMS functionality.

Part of the problem, I venture to guess, is that there is surprisingly little available documentation around what the business and functional requirements of a good LMS are! The argument could be made that every academic institution has different needs and it is thus difficult to compile a unified set of requirements. But despite those differences, is there core functionality that we can distill as universally applicable? It would seem that at a minimum, the requirements of an LMS are:

1. Classroom management (attendance, etc)
2. Delivering content to students
3. Collecting completed assignments
4. Reporting student performance
5. Streamlining administration
6. Improve customer service
7. Developing and queueing standard content, and providing opportunities to tailor content
8. Provide self-service learning for students and employees
9. Deploying learning resources and programs quickly
10. Extending, maintaining, and enhancing communities

Some of the LMSs that we feel best meet these objectives are:

Canvas: Arguably the most robust and full featured LMS offering currently available, Canvas is on a meteoric rise and has been gaining use in both the higher ed and K-12 segments. It is an open source and open API product, and is one of the few (only?) LMSs that has a free mobile app to go along with it.

Sakai: Sakai is a full featured LMS built by Stanford, which has been adopted by MIT, Berkeley, and others. It is not open sourced, but operated on a community backed license.

Moodle: Moodle is a fully featured and powerful LMS, but the once dynamic open source community behind it has seen some attrition. The LMS isn’t on the leading edge anymore, but with continued support from developers, it continues to remain very relevant.

ELMS: Headed by Bryan Ollendyke of Penn State University, ELMS is the most prominent Drupal based LMS. A lot of progress has been made, but there is still some work to be done, and Bryan is a well of knowledge on the subject and is happy to talk to anyone that wants to help further its development.

Blackboard: The original dominant LMS, Blackboard has since fallen out of favor with the emergence of the other more modern, elegant, and open source solutions. It is regarded as a very rigid LMS, and awful as a CMS. Blackboard has attempted to stay relevant by acquiring Moodle and Angel.

While perhaps biased, Instructure (the makers of Canvas) have a feature comparison chart on their website.

Site building solutions and tools

Site building tools are especially important to higher ed institutions, as they frequently need to provide academic units and departments an easy way to brand themselves under the institution’s overall brand. ImageX Media, Chapter 3, Funny Monkey, and several others have done excellent work to provide open source solutions that provide the ability to manage content, rapidly deploy sites, control branding, etc. Our four favorite Drupal based solutions are:

• OpenEDU, ImageX Media
• Open Academy, Chapter Three
• Julio, Funny Monkey
• Open Scholar, Harvard

Social based “LMS” platforms

This class of solutions is centered around giving teachers and students a way to interact easily online. It shifts away from the “heft” of traditional LMSs to try to facilitates easy communication, discussions, sophisticated learning opportunities (traditional and e-learning), content distribution/sharing, etc. Taking the view that allowing educators and students to connect more easily provides the greatest value, all the other functionality and bells and whistles are built around that core premise. While none of these services use Drupal, the big players are:

Edmodo: With 7.4 million users at over 80,000 schools, Edmodo is considered one of the best solutions for Elementary and Middle Schools. It boasts very good security safeguards and granular permissions controls, a high degree of personalization, and customers speak highly of the responsive support team. Edmodo was the first of its kind, but is now seeing increased competition from the next two in this list.

Lore (Coursekit): Lore is at the newcomer to this arena, but is moving to the forefront rather quickly thanks to strong financial backers. It is “Course-centric”, in that each course has it’s own private “social network”. Users love its clean and elegant UI.

Schoology: Schoology combines some of the best elements of Lore and Edmodo. One of the big selling points is that unlike Edmodo’s “wall” which can get cluttered. Schoology has threaded discussion boards to make content easier to find. It also has better security and permissions granularity controls than Lore. Despite the lite/social nature of the service, Schoology bills itself as being able to perform full-blown LMS functions.

What to choose??

With all these options out there (and these are truly just a sliver of the pantheon of offerings), it is easy for education institutions to feel completely overwhelmed by the choices available. Perhaps this is natural given our open source leanings at Four Kitchens, but we believe that the best option for education institutions is the one that makes data exchange, interoperability, and connected systems most easy to achieve. The process efficiencies, cost savings, ease of administration, reporting that higher ed and K-12 institutions crave can only be realized when the systems work in concert. A comment made by one educator that I talked to should be of particular note to technical service providers; he said, “All these educational services and websites try to be software and lock you in. What I would REALLY like is for a way to make all these systems talk to each other. If you can do that, you’ve got a real winner!”

Date: Wednesday, February 27, 2013 - 17:00 to 18:00

Several organizers of the Downtown Los Angeles Drupal group are meeting for the year's first Downtown Drupal Governance Meetup on Wednesday, February 27, 2013 between 5-6pm.

In the spirit and tradition of our user group and events, this meetup is open to all Downtown Drupal members and is an excellent opportunity for anyone who's interested in getting involved or is just interested in observing our open governance model.

Join us in person at Droplabs or remotely via Google+ Hangout!

Agenda

Our agenda for this meeting is to review (and possibly publish) the proposed Downtown LA Drupal Governance policy:

   http://groups.drupal.org/downtown-los-angeles/governance  

If you plan to attend, please be prepared and familiarize yourself with both our group's mission at http://groups.drupal.org/downtown-los-angeles and our current governance proposal at http://groups.drupal.org/downtown-los-angeles/governance prior to this meetup.

Join Us on Google+ and Twitter!

To join the meeting, use the following URL:

   Google+ hangout: https://plus.google.com/hangouts/_/7378d9b61d65107cb08a67d67ef7e75fd8a2f67d
   Short URL: http://ex.tl/ZMW  

During the meetup, the event organizers will be monitoring Twitter for feedback and questions that mention @DowntownDrupal.

Location and Directions

This event is hosted by Droplabs (@Droplabs), a collaborative coworking space, classroom and hackerspace in Downtown Los Angeles.

   Droplabs
   651 Clover St.
   Los Angeles, CA 90031

We're quickly gaining a reputation for being the only coworking space around with a with a low-cost business model: come work here and use our tables, chairs, WiFi and conference room with a low, daily or monthly membership fee and only pay more for the extras, such as 24/7 access, equipment rental and a locker for your belongings.

Droplabs is in the Mission Junction neighborhood of Los Angeles at Big Art Labs, just 1 mile down Main St. from Philippes (the first-ever venue for Drupal meetups in Southern California!) and Union Station. We're one block west of The Brewery, the largest live-and-work artists' colony in the world.

Free parking in our large parking lot is first-come, first-served. After parking in the lot, follow the yellow signs that point to Droplabs. (If our lot is full, you can park for free on Clover St.)

Droplabs is a brief walk from the Main St. / Lamar St. stop on the the Metro Local 76 bus line. This is also the Lincoln Heights / Chinatown DASH stop.

To carpool or catch the Droplabs shuttle from Union Station, post below in the comments.

What to Bring

Just bring your laptop, your business cards or whatever else you need. You're also welcome to bring some light food, sodas or beers to share with others at the meetup.

Please note that our guest wireless network is limited to 1Mb per client, so bring your MiFi router or a phone you can tether with if for some reason you need a lot of bandwidth. Access to our high-speed network is included with a Droplabs membership.

About Downtown Los Angeles Drupal

The Downtown Los Angeles Drupal group regularly meets in and around Downtown Los Angeles, California. We organize a large number of weekly and monthly events on various Drupal topics, including the general Downtown Los Angeles Drupal meetup that has been meeting regularly each month since early 2010.

The Downtown area is the most active area for Drupal in the Greater Los Angeles Area and has seen hundreds of Drupal events, including job fairs, meetups and workshops, study group meetings, conferences about design and theming, paid trainings, FREE tutoring sessions from Drupal professionals and barn raisings to benefit non-profits and members of our community here in and around Downtown Los Angeles.

Attending Drupal events in and around Downtown Los Angeles is one of the best ways to meet and talk with other Drupaleros and we encourage you to attend as many meetings and special events as you'd like. Whether it's to find solutions to problems you've been having, sharing something you've learned or just meeting interesting like-minded people, the Downtown Los Angeles Drupal events are an essential resource for Drupal professionals and hobbyists alike.

If you aren't already a member of Downtown Los Angeles Drupal, it's easy to join our community. Our community calendar is on our "Events" tab on our home page at http://groups.drupal.org/dtla  

The Downtown Los Angeles Drupal group proudly participates in the California Drupal Travelers Program and can host businesses and community members who are visiting the area. Inquire within by contacting any of the Downtown Los Angeles Drupal organizers.

Tags:

• Meetup
• Planet Drupal

The best type of blog post is the type that leads to action.

It seems that my recent post Drupal Modules: Usability Starts With A Name seems to have done exactly that.

As a result of that post and the comments that followed (on this website and in the issue queue), I have renamed the Storm module to Project Management.

Project Management is now the name and the description of the module. A new user now knows the context of the module without any additional explanation.

I have wondered since whether it was the right decision. But I am reassured that there was unanimous support for this change in comments, and the number of people participating in the issue queue has increased significantly since the change.

You can try Project Management (still a work in progress for Drupal 7) on this demo site. A version is also available for Storm (the stable modules for Drupal 6).

This practical example is, I hope, a motivation for more module maintainers to reflect that "Usability Starts With A Name".

Category: WebsitesTags: Drupal PlanetStormProject ManagementusabilityDrupal