Busy January at Cheppers

Posted by Cheppers blog on January 8, 2015 at 3:11pm

First of all - Happy New Year everyone! 2015 will be a fantastic year and we at Cheppers are ready to kick off! Let's see how we are going to start the year.

Part Four: IDE Integration

Posted by Blink Reaction on January 8, 2015 at 2:32pm

At this point we have our VM running and performance tuned. Now that we have a synced directory on our host machine, it’s easy to see how we copy our site onto the VM. You may have already done this, and that’s okay! Let’s integrate the VM with our IDE so we can push our changes much more easily.

Being Prepared When Everything Goes Wrong

Posted by Drupalize.Me on January 8, 2015 at 2:02pm

We recently completed making updates to our incident response plan for Drupalize.Me and I wanted to share some of what we learned along the way, and help you write your own. An incident response plan is all about being prepared. So that in the moment, under pressure, when everything that could possibly go wrong is going wrong, you can remain calm, cool, and level-headed. If you've ever had to write a social media message, or respond to a support request during an un-planned site outage you know how easy it can be to misstep—even if your intentions are good.

Drupal 7 Smart Trim: An simple way to shorten long text areas

Posted by Code Karate on January 8, 2015 at 1:45pm
Episode Number: 189 An simple way to shorten long text areas

The Drupal 7 Smart Trim module allows you complete control over how you want text to be displayed when shortened. Put another way this is the module to use if you want to display a teaser or a beginning part of a longer text area.

Once installed you are able to set a variety of things. These include: shorten length by either words or characters, what to display for the ellipse (...), if you want a "read more" link to appear and what you want the link to say and lastly if you prefer to use the Drupal summary option.

Tags: DrupalFieldsViewsDrupal 7Site BuildingDrupal Planet

Iterations for Drupal development

Posted by Wunderkraut blog on January 8, 2015 at 11:39am

Iterative development process works well for software development in general. Using a process like Scrum can however cause some problems with a high productivity platform like Drupal. With Drupal you already have a working product very early in the process, you tweak the details and in the end have an improved version. With Drupal features are cheap and details are expensive.

This post is the part 2 for my previous blog post on Iterative and incremental development for Drupal.

agile-waves-2.png

 

Iterations defined

Coming up with generic ideal iterations is very challenging. I fully expect to use different iterations for different kind of projects and project teams. Setting up the iterations should be a part of the discovery process before getting started on the development. The intention of this post is to provide a starting point for defining different iterations in each project.

Before we can start a project we need to do discovery. After the discovery we must at least have the following:

  • Confirmed business requirements and how to measure them
  • Risks and how to manage them
  • Expectations, what promises have been made and to whom
  • List of stakeholders and target user groups, ideally personas defined for each key user group
  • A full backlog for the project, level of detail depends on the size of the project. In large projects stories just get bigger
  • Understanding of the technical landscape, integration points, data migration requirements, etc
  • Dependency diagram, what does the project need from external parties and by when
  • Content delivery process defined, who’s responsible on what and how

We have internal tools and templates for everything that should be done in discovery. Some of these are already shared in our blog, others will be shared in the future.

Iteration 0: User story written

Responsible: The PO with support from the scrummaster and the team as needed

User stories originate either directly from the business goals or from splitting epic stories to something more manageable. An user story always has the following:

  • As a WHO I want to WHAT so that WHY (or your own favourite user story format)
  • Acceptance criteria
  • OPTIONAL: How to measure success. This is a good discussion to have in order to understand the expectations of the PO, but it’s up to the team if they want to capture this or not.
  • OPTIONAL: Technical notes. This is owned by the team and changing it only needs the team to agree on it. The reasoning is to keep technical requirements out of acceptance criteria in cases where they are not coming from the PO.

A great user story focuses much more on the WHY than the WHAT. At this point of the process we want to have a lot of flexibility for the team to implement this story in any way they choose.

Acceptance criteria includes limitations coming from the product owner, never from the team. The team may agree to do something, but only the PO can set official acceptance criteria. Acceptance criteria is often technical in their nature, say for example in an eCommerce payment story:

  • Must accept Visa, Amex and MasterCard
  • Must accept Paypal

How to do it

Many stories are already written during the discovery in a backlog creating workshop. During the project we’ll usually need more stories to be written. These can be written in backlog refinement sessions, in the sprint planning or in sprints as tasks. Each of these approaches has it’s benefits. By default I recommend that the PO and scrummaster together write the additional stories in backlog refinement sessions in each sprint. After this the stories are improved in sprint planning with the entire team as needed.

Definition of done

  • All team members understand the story and the reasoning behind the WHY
  • Acceptance criteria are unambiguous to all team members and the PO
Iteration 1: Potential solutions identified

The team or a team member identifies different ways to implement the story and meet the acceptance criteria. This is where we can make a big difference.

Think about if this is a Drupal implementation, would there be an existing SaaS service for this or some other way to meet the WHY. You are a web professional, it's your job to propose different solutions to the customer that may save a lot of work in the end.

How to do it

In this many heads are better than one. The recommended approach is to have the entire team and potentially also the PO spend a short session on this for each sprint. This may be time consuming, but coming up with an alternative solution may save up to 95% of the time required to implement the story.

Each task of defining potential solutions for a story should still have an owner. It’s the owners responsibility to do quick demo for the PO if required and to make sure the task gets done during a sprint.

Definition of done

  • Drupal and non-Drupal solutions considered
  • The simplest possible solution considered and proposed to the PO
  • Multiple options identified
  • Benefits, drawbacks and risks of each approach presented to the PO
  • A quick demo shown to the PO when required for explaining the options
  • The PO reaches a decision on which way to go
Iteration 2: Service design for the story

Now that we know which approach to take, we should move on to define the user process and experience.

How to do it

Typically the UX designer will create wireframes or other quick to implement solution to demonstrate this to the PO and to the team if needed. At this point the solution should not be a pixel perfect mockup, it’s still possible to choose another solution for the same goal so it’s not worth spending a lot of time on this. In order to do this the UX designer must understand the solution chosen, for example an existing Drupal module.

Definition of done

  • User workflows understood by the PO
  • Preliminary user experience designed and approved by the PO
Iteration 3: Functional prototype created

It's time to implement the chosen workflows and UX. This step only includes a minimal version of admin functionality, no testing or QA. The intention is to make sure we are building the right thing before paying more attention to detail.

How to do it

A team member implements the quickest possible prototype that demonstrates the user experience to the PO. This can then be used as a demo for the stakeholders of the project as needed, assuming the stakeholders can just focus on the functionality instead of the visual details.

In some cases there is very little difference between functional prototype and MVP, in these cases these two iterations should be merged. However if there is uncertainty if the PO or key stakeholders to the project understand what we are about to do it’s well worth doing a separate iteration for functional prototype.

Definition of done

  • The primary end user workflows can be completed in the prototype
  • User experience is mostly according to preliminary designs, not pixel perfect
Iteration 4: MVP implemented

The team and the PO get together with the functional prototype and decide what parts still require attention.

How to do it

Based on the feedback from the functional prototype multiple team members get to work. Remaining details are defined and implemented. The goal is to have a minimum viable product, this means something that could be released but is not yet ideal.

Definition of done

  • A potentially publishable piece of functionality, only waiting for QA in order to go live
  • The project definition of done -QA
  • The PO approves the MVP
Iteration 5: QA implemented

Implement the automated testing and any other QA measures defined in the project. ( a template should be provided )

How to do it

This is mostly technical task, getting all of the quality assurance in place to make the story implementation easy to maintain and make continuous deployment of incremental improvements possible.

The iteration also includes making sure the story meets production check-list, unless this has been agreed to be done per release instead of per story.

Initially we should always only do the MVP instead of trying to reach ideal implementation. According to the pareto principle it’s often more valuable to move the focus on the next story instead of tweaking this one. The team should still allow for more time to get back to improving a story and remind the PO to evaluate the priorities between improving a story vs starting on new stories.

Definition of done

  • The project QA definition
  • Production checklist completed (per story or per release)
The life of a story after the MVP

We are not aiming to do ideal implementations for each story right away. This is important because sometimes priorities do shift during a project when we learn more. It’s also often useful to get a MVP version to the hands of real users and see how it performs before aiming for the ideal version. Sometimes our assumptions on what’s ideal are not spot on after all.

However the goal of a project is not to simply deliver a MVP. For some less important stories a MVP may be enough, but the more important wants definitely require more attention from the team.

Improving a story can either follow the same 6 iterations outlined in this document or be much more specific, basically just a task on focusing on one area of the story implementation. Typically it’s more common to just focus on tasks improving a story.

At this point it’s important to be careful not to end up delivering over-quality. This means a very high quality product technically, visually or by any other aspect that will never have any return on the investment made on it. It’s worth mentioning the cost of doing an improvement in money (based on best guess on hours spent) to the PO and get her to confirm she thinks it’s worth the investment.

Areas of improvement to consider

  • Admin experience improved
  • User experience improved
  • Adding new functionality to the story
  • Better total cost of ownership by making maintenance easier

Iterative and incremental Drupal development

Posted by Wunderkraut blog on January 8, 2015 at 10:54am

Iterative development process works well for software development in general. Using a process like Scrum can however cause some problems with a high productivity platform like Drupal. With Drupal you already have a working product very early in the process, you tweak the details and in the end have an improved version. With Drupal features are cheap and details are expensive.

We like to experiment with our process and to improve it. With a company full of agile experts, trainers and coaches there are plenty of discussions around the topic. One of the recent ones has been on moving from just one definition of done to having one for each iteration of a feature. This should give us better visibility for progress and provide earlier decision points for the customer.

Why do we need this?
  1. Make sure we don't do what the customer asks but what the customer needs. It's our job to meet the business need of a customer, we should be able to offer alternative solutions to the customer instead of just going for the most obvious or the "Drupal standard" one.
  2. Keep better control over the project budget. We are good at delivering the highest priority items first, but not always great at knowing what's good enough. This approach will move the work to the next story before the previous story is implemented perfectly. The goal is to add more clarity on when good is better than perfect.
  3. Help the team members work together in a more effective way. When we work on different stages of multiple stories simultaneously it's easy to lose track of progress. Having a clear process should help us not to do important steps too late and keep the communication simpler.
  4. Allow customers more time to react on the primary decisions by pushing detailed decisions to later in the project. When the customer knows what level of detail we are dealing with they should have easier time on deciding how much time they should use on it.

In the end of the day most of our customers just care about getting the job done in the most efficient way possible. It’s not so much about technology, design or methodology to get there, it’s much more about the results.

How should we do it?

By combining iterative and incremental process into what I call development waves. It's nothing radically new, just combining many things we already do into a process and documenting it.

agile-waves-1.png

The basic idea is to approach a project with increments and iterations. Increments will add functionality and iterations will improve functionality. Instead of trying to get a story done-done in a sprint we will have different definitions of done for different iteration tasks. This is intended to help us find better ways of meeting the why of a story, keep the project moving forward faster and allow more innovation during the project.

The cooperation between team members should also improve with each story being split always to similar tasks based on iterations. We can also use the same methodology for epic stories and tasks.

agile-waves-2.png

Sprints move through increments and iterations of them in waves. In some cases multiple iterations will be done in a sprint, in some just one. Instead of working to reach the definition of done for a full story the team works to reach definition of done for each iteration of a story. This removes a lot of the extra overhead needed for quality assurance while we are still not 100% sure what the final implementation will look like. When the PO changes her mind or the team figures out a better way of delivering the story less work is wasted.

To help balance the workload of team members stories are not in sync for their iteration level. One story in a sprint may only have concept level work done on it, another user experience design and third MVP implementation. This will replace the sprint scouting we do today and make the communication around it easier. It should also make progress more visible and estimation of tasks easier when every story is always split to iteration tasks.

The goal for any project should not be to complete 100% of the backlog. Usually if that happens time has already been wasted on low value items and the same time would be better spent on either improving the quality of higher value stories or coming up with new ideas.

When a release of a project is done we have always completed the most valuable stories for that release and also done some scouting for the future. There may be some time wasted with getting started on stories that will not be implemented, but on the other hand we should be able to make incredible savings on other stories by coming up with more effective ways of implementing them.

agile-development.png

Image credit: Henrik Kniberg, What is Scrum

The approach is to build something visible and useful as early as possible. This is true both for iterations and increments. Everything we build should immediately have some value to it and we should be able to explain that value to the customer at any point.

 

In the next post I'll define different iterations and how to do them.

The Great D8 Chook Raffle

Posted by KatteKrab on January 8, 2015 at 10:06am
Thursday, January 8, 2015 - 21:06The Drupal Association board approved a new initiative to help get Drupal 8 done.  It's called the D8 Accelerate fund. We also agreed to personally help do fundraising to support the program.  So I'm running a chook raffle.  For those of you who don't know what that is, Wikipedia gives a decent introduction.   https://www.drupal.org/governance/d8accelerate   The Drupal Association is working with the Drupal 8 branch maintainers to provide Drupal 8 Acceleration Grants. The goal is to fund work that will positively impact the release date. Drupal 8 has had over 2,400 contributors to date, which is more than any release so far. We hope that this initiative will encourage even more people to join the effort to get D8 done.   I'm about to launch a pozible campaign.  Stay tuned!      

Render custom button

Posted by Yuriy Gerasimov on January 8, 2015 at 8:19am

Sometimes for our front-end development we need to have very granular control about how our form buttons being rendered. So instead of standard drupal markup we want to have something like

<button class="bird-guide-zip-submit button pea-green">
  <span class="hide-for-medium hide-for-large hide-for-xlarge">
     <i class="icon-magnifier"></i>
  </span>
  <span class="hide-for-tiny hide-for-small">Ok</span>
</button>

You would think that something like:

$form['submit'] = array(
  '#type' => 'button',
  '#value' => '<span class="hide-for-medium hide-for-large hide-for-xlarge">
      <i class="icon-magnifier"></i>
    </span>
    <span class="hide-for-tiny hide-for-small">' . t('Ok') . '</span>',
  '#attributes' => array(
    'class' => array('bird-guide-zip-submit', 'button', 'pea-green'),
  ),
);

would do the job but that is not the case as #value is being sanitized (that is great from security perspective). In order to change this behavior for one particular button we should use

 '#theme_wrappers' => array('mymodule_button'),

And then define your custom theming function

/**
 * Implements hook_theme().
 */
function mymodule_theme() {
  return array(
    'mymodule_button' => array(
      'render element' => 'element',
    ),
  );
}
 
/**
 * Custom button theming function.
 */
function theme_mymodule_button($variables) {
  $element = $variables['element'];
 
  $element['#attributes']['type'] = 'submit';
  element_set_attributes($element, array('id', 'name'));
  $element['#attributes']['class'][] = 'form-' . $element['#button_type'];
  return '<button' . drupal_attributes($element['#attributes']) . '>' . $element['#value'] . '</button>';
}

Be aware that when you use this technique you take responsibility for making sure you do not display any potentially harmful html in the #value as you do not sanitize it.

Tags: drupal planetdrupal 7

128 The Z-Ray Developer Bar with Daniel Berman - Modules Unraveled Podcast

Posted by Modules Unraveled on January 8, 2015 at 8:15am
Photo of Daniel BermanPublished: Thu, 01/08/15Download this episodeZ-Ray
  • So, let’s start out with the basics. What exactly is Z-Ray?

    • So Z-Ray is a cool new tech that we introduced just a few months back which gives developers deep insight into all the PHP elements constructing their page, including Drupal-specific elements.
    • It’s basically a toolbar that’s displayed right in front of you in your browser. No code changes needed. You don’t have to configure anything. Just open your app in a browser and you’ll see Z-Ray at the bottom of the page!
  • How does is work? Is there a module that you have to install on your site?

    • No. It’s not a module. Without going into too much detail: Z-Ray collects info while your app is being processed on the server side, and once the request is completed, Z-Ray’s JavaScript code is injected into the response with all the collected data.
    • There are other mechanisms at work, such as Ajax support, but as a whole that’s all there is to it. It’s also the limit of my technical understanding of how it works :-)
  • So what info does Z-Ray display? What are it’s main features?
    Well. There’re so many features in Z-Ray, and I don’t think we have the time to go over them all, but to mention just a few.

    • Z-Ray gives you info on SQL queries. You’ll see a query’s bound value, the result of the query, how long the query took, and how many rows in your code are affected by the query.
      You can even see a backtrace of the query to get the larger picture on how your code was executed.
    • Z-Ray also gives you all the errors generated by PHP itself, or those created by its core functions. You can also see errors for silenced expressions. Exceptions are also displayed.
    • What do we have for Drupal devs? Z-Ray will give you a list of loaded Drupal modules with invoked actions and hooks, a list of called Drupal functions, a list of used Drupal forms on the page, and some general user info.
    • We’re especially excited about Z-Ray Live! Until now we’ve spoken about using Z-Ray in a browser, right? But what if you’re developing APIs or a mobile app? No browser there. So Z-Ray Live! is a new feature accessible via a dedicated page in the Zend Server UI, with an embedded Z-Ray.
      So as soon as this page is loaded, Z-Ray records and displays any request made to the web server, never mind where its coming from - whether from a browser, a mobile device or a web-service client.
    • One of the coolest things about Z-Ray is that you can plug in your own customized extension. Even people in Zend itself have begun developing their own extensions so its pretty viral.
      By the way, all the code for the Drupal extension is available on Github, so feel free to fork it and send us a pull request.
    • There’s integration with IDEs, session and cookie data, request info, and so much more to talk about.
  • Is Z-Ray just for development? Or should it be used in production too?

    • Z-Ray was designed to be used both in dev and prod. While in development it works on every request, in production you can manually use Z-Ray using specially created access tokens. And it also periodically saves snapshots for important URLs - like the slowest requests on your web server, most time consuming requests, and so on. And again - with no changes to your code and no real implication on end-user experience or server performance.
  • OK, if I want to give it a shot, what does the installation process look like?

    • Z-Ray’s bundled with Zend Server, so to use Z-Ray you would need to download and install Zend Server - a total no brainer. Just like installing any other PHP stack.
  • So, how do you see Z-Ray helping Drupal developers?

    • At Zend we like to talk about left-shifting. This basically means that Z-Ray helps developers hit issues very early in the development cycle and way before going to staging and production.
    • We all know that getting clarity on all the Drupal elements working under the hood is extremely hard and takes loads of time. So at the end the day we believe that Z-Ray gives Drupal devs the visibility they need to properly profile their apps, identify bugs very early, and troubleshoot them.
Episode Links: Zend Server Z-RayDrupal Demo of Z-BarZend WebsiteZend Server Online HelpZ-Ray on YouTubeZ-Ray Drupal Extention on GithubDaniel on TwitterEmail DanielTags: ServerDevelopmentPerformanceplanet-drupal

Drupal Field Value Index and Performance

Posted by Wuinfo on January 8, 2015 at 2:13am

When we talk about the performance of Drupal, the first thing come to my mind is caching. But today I found another way to make Drupal run a little bit faster. It is not a profound thing, but something may be ignored by many. In work, I need process 56916 records constantly with automated Cron process. It took 13 minutes 30 seconds to process all those records. Adding a new database field index, I reduced the processing time to one minute 33 seconds only. It is more than eight times faster.

Here is the detail. I have about fifty thousand of record that updated daily. Each record I had a hash created and stored in a field. Whenever inserting or updating a record, and I would check and see if this hash code existed in the database. The project requires searching on the field revision table. Here is the code in my custom module.

$exist = db_query("SELECT EXISTS(Select entity_id from {field_revision_field_version_hash} where field_version_hash_value = :hash)", array(':hash' => $hash))->fetchField();
// Return when we had imported the schedule item before.
if ($exist) {
return;
}

So, checking the hash code in the database became one of the heavy operations. It consumed a lot of system resource. By adding a single query to the field revision table make the process eight times faster. Here is the code I put in the module install file.

// Add version-hash indexes.
if (!db_index_exists('field_revision_field_version_hash', 'version_hash')) {
db_add_index('field_revision_field_version_hash', 'version_hash', array('field_version_hash_value'));
}

When we build a Drupal website, we are not dealing with database directly. Even though Drupal creates the tables for us, we can still alter the table and make it better.

tag: performance

Drupal 8: Reviewing and updating diff module

Posted by Conocimiento Plus on January 8, 2015 at 12:56am
I do not paint things, only the difference between things. -Henri Matisse Introduction How many times you have used the command diff or  git diff  to compare files?. In the simplest case, diff compares and analyzes the content of two files and prints the lines that are different. Essentially, it outputs a set of instructions […]

Drupal CMS Powerstart Tutorial 1: Introduction and Overview

Posted by Sooper Drupal Themes on January 7, 2015 at 11:20pm
With Drupal CMS Powerstart you can build a beautiful responsive CMS website in 5 minutes powerstart-3dfoldout.jpg Drupal CMS Powerstart

That basically covers the primary goal of the CMS Powerstart distribution: to make Drupal easier and less intimidating to new users. Drupal has a problem: it is relatively difficult to set up and has a steep learning curve. This impedes Drupal's growth as a small-business CMS and by extension it is costing the Drupal community as a whole precious talent: beginning developers, designers and enthusiasts who learn Wordpress and develop awesome plugins and themes for Wordpress because it was too difficult to get started with Drupal.

Another project that tries to make Drupal into something more comprehensible is Backdrop CMS, but I believe Drupal can be user-friendly and developer friendly without needing a fork. While Backdrop focuses on creating a more newbie-friendly code architecture I'm trying to focus on awesome tools Drupal offers to 'develop' websites without writing any code. 

If you are reading this, you probably at some point installed Drupal and realized that it's powerful modular architecture and contrib modules make it a way more extendable and customizable tool than say, Wordpress. We love Drupal because in many ways its better than the competition, better than Joomla, Django, sharepoint or Wordpress. Still, somehow even very prominent Drupal agencies choose to build their site in Wordpress. And they are right, for a small responsive website, you can download and customize a themeforest theme and be done much quicker than with Drupal. What does Wordpress have that we lack? A built in WYSIWYG editor, handy shortcodes, WYSIWYG site building tools... and an enormous selection of premium themes. But it doesn't have a fine-grained permission system, views (unless you shell out 100 dollars for a premium plugin), webform etc.

In flexibility and extendibility Drupal is still better than Wordpress, but I think Drupal doesn't have to lag behind in user-friendliness and that's why I built this distribution; to offer fully configured CMS components and responsive design out of the box. Building this distribution was a challenge but it also showed me that Drupal has potential outsmart Wordpress in the areas where Wordpress is currently better. A common complaint about themeforest Wordpress themes is that their installations are heavy and slow. Thanks to the configuration-in-code architecture of CMS Powerstart I was able to make a custom-build interface so that you only get the code you really need:

http://www.sooperthemes.com/minisites/drupal-cms-powerstart-custom

Just pick the features you plan to use in your project and download a customized build. 

What do I get? At a Glance
  • Responsive Design
  • Fully configured CKEditor 4 WYSIWYG
  • Light and heavy WYSIWYG profiles
  • Media library for content images
  • Shortcodes for graphical elements
  • Shortcodes for complete Bootstrap 3 support in content
  • Image resizing that matches Bootstrap grid
  • Integrates Views and blocks with Bootstrap 3
  • Blog component*
  • Events component
  • Event registrations component
  • Portfolio component
  • News component
  • Contact form component
  • Demo content
  • SEO Optimized
  • Frontend and backend performance optimized

*In CMS Powerstart a component is a fully configured feature, often including a content type and one or more views and whatever else is needed to create a user-friendly, good looking website component.

Author Empowerment

WYSIWYG

Especially for beginning Drupal users, adding a WYSIWYG editor is a difficult task. Even experienced Drupal professionals can be surprised by some the capabilities of modern WYSIWYG systems like CKEditor 4. WYSIWYG editors are an important part of the author experience on your website and  CMS Powerstart has ships with 2 fully configured WYSIWYG profiles. There is a 'full' profile that offers a wide range of rich content tools and a 'simple' profile that shows a toolbar with only simple text editing tools. 

Shortcodes

Shortcodes allow you to create rich content and layouts without using any HTML or CSS code. Using WYSIWYG integration you can even generate all the codes without having to remember  the codes. This is great for clients who want to have control over columns and buttons in long pages but it can also be great  for site builders who know HTML and CSS. I personally prefer to use shortcodes over HTML to great bootstrap grids within content because using the WYSIWYG button I get a form that listsall the breakpoints that bootstrap uses and I can easily fill in column sizes that fit the content I'm working on right now.

Other shortcodes I like to use as a site builder are Bootstrap tooltips, popovers, carousels and other interactive elements, because I don't know all the  syntax of these elements by heart. It's great to just highlight a text or image in CKEditor and then use the shortcode button to create a popover bubble with additional information.

Media Library

A media library is great because it allows you to re-use assets on your website without having to re-upload them for every page. The Drupal media module is pretty incredible, it pulls together uploaded files, it can integrate media from many internet sources including youtube, media, soundcloud etc. It also gives you a nice overview and history of files that are part of your website and gives you a sense of control over content added by yourself and other contributors on your website. The downside of the media module is it's complexity: It was a lot of work to create a nice basic media library experience in CMS Powerstart and the finaly product uses the latest development branch and a number of patches to create a smooth user experience and integration with Bootstrap 3 column sizes in the image resizing interfaces. Luckily for you, this is now available to you in the CMS WYSIWYG component in Powerstart. 

Site builder tools

Plug and Play CMS Components

Drupal CMS Powerstart is built as a core distribution with add-on components. This architecture was chosen because from my experience with other Drupal distributions (and wordpress themes) I know that you often get much more features than you need. The result of this is not only a slower, heavier website but also an interface that is more complicated than it needs to be. If you want a website with a blog and a news section, you need need to have modules, content types, blocks and views for events and portfolio content. Your administration interface is cleaner and simpler if you only install the modules you will actually need, and that is what the custom build interface is for.

Bootstrap 3

Nowadays any website that isn't responsive is leaving money on the table. More and more internet users access websites on their portable devices. Google has also started integrating mobile-friendliness in their results page rankings so possible you are even missing out on desktop users when your site is not mobile friendly. This is why CMS Powerstart has made responsiveness an integrated part of the project. The powerful Bootstrap 3 responsive grid system is used throughout the Powerstart components: views, fields, and blocks are responsive out of the box.

The WYSIWYG component also includes an extensive bootstrap shortcodes library, giving you access to all Bootstrap 3 components right in the WYSIWYG.

If you are not familiar with Bootstrap 3, you can still use Powerstart together with a custom theme and custom grid. Being a designer myself I used to dislike any grid frameworks because it limits what you can do creatively, but the 12 column grid in Bootstrap 3 is divisible by 2, 3, and 4, making it a hugely practicaly tool to translate any content smoothly to devices of all sizes. I previously used custom grid system tools like Susy and Singularity but now I feel confident I can create anything I need with the Bootstrap 3 system. Bootstrap isn't the best choice to create that unique 7 column layout that you have in mind for some funky design concept, but really when is the last time you actually used a unique layout system for an edgy design concept? It's not worth the hassle. 

Themes

Works with any theme, 25 officially supported themes

The extra benefit you get from the officially supported themes is that I tested them and added code to the installer that puts blocks in the right regions. Powerstart is built to look as good as possible out of the box but to be as extendable as Drupal itself. This means you can develop themes (and modules) for CMS Powerstart as you would for any Drupal website. You can build a theme with or without Bootstrap 3 for Powerstart, but I would recommend giving Bootstrap a shot, it has proven to be a big time saver for me.

Premium Themes

Premium themes, especially the Glazed theme are available to take your Powerstart site to the next level, on a small budget. The Glazed premium theme is built for and with the CMS Powerstart distribution. It offers additional features including advanced theme options, premium shortcode elements and an advanced mega menu. The Glazed project and the CMS Powerstart distribution were developed together, and I hope that revenues generated from the premium themes club allow me to keep improving Powerstart, and to port it to Drupal 8. 

SEO done right

Drupal's SEO is not bad out of the box, but with additional modules and metatag configuration you can have top tier SEO, on par with the popular Wordpress+Yoast combination that is used by many SEO professionals. CMS Powerstart comes with automatic semantic path aliases and redirects, but also implements more advanced techniques to Drupal. For instance, the metatag module is used to limit duplicate content problems and focus your link power on the right pages. In the Events component this is done by putting no-index metatags on the Events archive views, which basically only contain duplicate content of your event pages. This makes sure your link juice is spent on actual event pages.  

100% Drupal

The CMS Powerstart project is a Drupal distribution. Distributions are installation profiles that install Drupal + a number of features that relate to a specific type of website. For example, for e-commerce there is Drupal Commerce and for advanced group/community websites there is Drupal Commons. Dries wrote about distributions in 2006:

The fact that Drupal 5.0 will support distributions is big, and most people have yet to see its full potential. I don't think that any other Open Source project has done something like this before -- or at least, not on the scale that we might end up doing this.

Dries Buytaert

Clearly there were high expectations of distributions in Drupal, even in 2006. From what I can see the concept of distributions did not really catch on as much as expected. I think this is in part because the framework to create distributions needed to mature but also because Drupal.org is not offering a good portal for distributions. That's why I chose to create a separate interface for composing and downloading CMS Powerstart. The one Distribution that did breaking through the 10.000 active users barrier is Drupal Commerce Kickstart, and it's easy to see why. They put a ton of effort into both the distribution and the installer. If CMS Powerstart gains some traction I hope to develop it into something of similar quality.

I will try to regulary write more tutorials to show you how Powerstart can be used to create awesome websites like civinex.nl and lorenagarcia.nl in record-breaking time. I promise the next tutorials will also be more tutorial-esque than this introduction.

Tags

planet drupal planet cms powerstart sooperthemes Drupal Themes distributions

Drupal

7.x

Backdrop CMS

Posted by Drupal Watchdog on January 7, 2015 at 7:17pm
Feature

Image of a tuning fork
Backdrop CMS is a fork of Drupal; it’s a Content Management System for the non-profits and small-to-medium sized businesses of the world. As Drupal moves itself closer to the Enterprise market, Backdrop CMS emerges to meet the needs of the little guys.

The goal of the project is to improve and simplify the code and architecture of Drupal 7 while minimizing the cost to the community. Backdrop was forked from an early version of Drupal 8, just before things started to change drastically: before the adoption of Symfony, before the conversion to PSR-0, and before widespread rewrites of many subsystems.
When Backdrop CMS is released, it will contain many of the same major new features as Drupal 8: configuration management, Views module in core, and rich text editing, to name a few. Each may have a few features the other does not, but the main difference between the two products is the underlying code.

We like to think of Backdrop CMS as the next logical step in Drupal's evolution. If you've worked with Drupal 7 code, the code in Backdrop will look very familiar to you. Modules and themes are written the same way as they were in Drupal 7, with a few minor improvements. You'll spot the differences caused by CMI and the new layout system, but you'll be able to find your way around the files easily. Drupal 8, on the other hand, is quite different.

When Drupal 7 was first released, adoption was slow. It was so slow that the overall number of Drupal installs actually declined for a while. A lot of contributors complained about the scope of changes, and Drupal 7 versions of modules and themes were painfully slow to appear. Yes, there are some complaints after every major release. Change is hard. But big changes are significantly harder.

Drupal installations over time

Part Three: Getting your Site onto the VM

Posted by Blink Reaction on January 7, 2015 at 6:16pm

In the last post, we got our VM up and running. Now we need to configure a hostname for it, as well as upload our site to the VM so we can start developing!

Configuring your Host OS

There’s one more step you need to perform in order for VDD to function properly on your system. You need to modify your machine’s hosts file so that you can visit your new VM by hostname instead of by typing in an IP Address.

How to Easily Create Drupal Webforms in Code

Posted by Aten Design Group on January 7, 2015 at 3:10pm

Drupal webforms are useful in a variety of contexts, but the most typical context is something like a contact form: user-facing functionality that needs to exist when a site launches, and be easily edited by a site owner post-launch. In that context, webforms should be created automatically for a smooth, predictable launch. There are a few ways you can do that, including the Webform Features module, the Universally Unique IDentifier (UUID) module or custom code, maybe following documentation on Drupal.org.

When making webforms on a recent site, none of these options appealed to me. I wanted to manage webforms in code pre-launch, then hand them to a content editor to manage (outside code) post-launch. The Features-based options for creating webforms were okay pre-launch, but would add overhead post-launch. And creating a webform node from scratch seemed overly complicated to manage pre-launch. So I wrote the interface I wanted for creating and managing Drupal webforms, and it's now in the Config in Code (CINC) module for anyone to use.

Here's the example linked above from Drupal.org, implemented in this new CINC-based approach:

$webform = CINC::init('Webform')->machine_name('Contact Us');
 
$components = array();
 
$components[] = CINC::init('WebformComponent')->set('form_key', 'gender')
  ->set('type', 'select')
  ->set('mandatory', 1)
  ->set('extra.items', "Mrs|Mrs\nMiss|Miss\nMr|Mr")
  ->set('extra.aslist', 1);
 
$components[] = CINC::init('WebformComponent')->set('form_key', 'name')
  ->set('name', 'Last name')
  ->set('mandatory', 1);
 
$components[] = CINC::init('WebformComponent')->set('form_key', 'first_name')
  ->set('mandatory', 1);
 
$components[] = CINC::init('WebformComponent')->set('form_key', 'city');
 
$components[] = CINC::init('WebformComponent')->set('form_key', 'country')
  ->set('type', 'select')
  ->set('extra.options_source', 'countries')
  ->set('extra.aslist', 1);
 
$components[] = CINC::init('WebformComponent')->set('form_key', 'email_address')
  ->set('type', 'email')
  ->set('mandatory', 1);
 
$components[] = CINC::init('WebformComponent')->set('form_key', 'subject')
  ->set('type', 'select')
  ->set('extra.items', "s1|Subject 1\nother|Other")
  ->set('extra.aslist', 1)
  ->set('mandatory', 1);
 
$components[] = CINC::init('WebformComponent')->set('form_key', 'message')
  ->set('type', 'textarea')
  ->set('mandatory', 1);
 
$components[] = CINC::init('WebformComponent')->set('form_key', 'mandatory_fields')
  ->set('type', 'markup')
  ->set('value', '<p>Fields with * are mandatory</p>')
  ->set('extra.format', 'full_html');
 
foreach ($components as $index => $component) {
  $webform->add_component(
    $component->set('weight', $index * 5)->set('extra.title_display', 'inline')
  );
}
 
$webform->add_email('somebody@example.tld');
 
$webform->create();

The line count on that (52) is less than a third of the non-CINC example on Drupal.org (170), and did not require any time clicking around in a browser to create and export the webform. The code is also far more readable than both a Features export and starting from scratch, which makes it more maintainable. You may look at that "city" component and think I left something out, but that's really the entire code needed for a textfield with a name matching its form_key. Sensible defaults are nice.

As an added bonus, the CINC interface can also be used to read, update, and delete existing webforms. So if you need your Drupal webforms in code and Features isn't the best option for some reason, I invite you to enjoy the ease of creating webforms programmatically with CINC.

Speeding up Drupal 8 module creation using Drupal Console

Posted by lakshminp.com on January 7, 2015 at 2:27pm

Though Drupal 8 is technically advanced compared to its predecessor, writing a module involves a lot of boilerplate code. There were many gotcha moments when I forgot to add a namespace and got puzzling errors.
Fortunately, all that code can be generated automatically using a tool called the Drupal Console.
Drupal Console is another cool addition to the Proudly Found Elsewhere school of thought as it leverages the Symfony Console component to handle the CLI part.

Installing

Note that Drupal Console supports only Drupal 8.0.0-beta4 at the time of writing this.

Get the latest version:

$ curl -LSs http://drupalconsole.com/installer | php

Move it to somewhere convenient so that it can be used throughout the system:

$ mv console.phar /usr/local/bin/drupal

Go to the drupal root directory of any Drupal 8 beta4 setup and run:

d8$ drupal list
Drupal version Drupal Console 0.5.2 - prod

Usage:
 [options] command [arguments]

Options:
 --help (-h)           Display this help message.
 --quiet (-q)          Do not output any message.
 --verbose (-v|vv|vvv) Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug.
 --version (-V)        Display this application version.
 --ansi                Force ANSI output.
 --no-ansi             Disable ANSI output.
 --no-interaction (-n) Do not ask any interactive question.
 --bootstrap-file (-b) Path to Drupal bootstrap file (core/includes/boostrap.inc).
 --shell (-s)          Launch the shell.
 --env (-e)            The Environment name. (default: "prod")
 --no-debug            Switches off debug mode.

Available commands:
 cr                            Rebuild and clear all site caches.
 drush                         Run drush into console
 help                          Displays help for a command
 list                          Lists commands
cache
 cache:rebuild                 Rebuild and clear all site caches.
config
 config:debug                  Show the current configuration
container
 container:debug               Displays current services for an application
generate
 generate:command              Generate commands for the console
 generate:controller           Generate controller
 generate:entity:config        Generate EntityConfig
 generate:entity:content       Generate EntityContent
 generate:form:config          Generate ConfigFormBase
 generate:module               Generate a module
 generate:plugin:block         Generate plugin block
 generate:plugin:imageeffect   Generate image effect plugin
 generate:service              Generate service
router
 router:debug                  Displays current routes for an application
 router:rebuild                Rebuild routes

Usage

Drupal Console currently supports generating PSR-4 compliant code for plugins, controllers, modules, services, entities and forms.It also has basic debugging commands for listing current configuration and routes.
Never write a Drupal 8 module from scratch again. Use Drupal Console instead!

Resources

Using HD Bitcoin wallets with Drupal Coin Tools

Posted by Jonathan Brown on January 7, 2015 at 1:10pm

Previously: Drupal / Bitcoin BIP 70 / PKI certificates

Each Coin Tools payment needs its own Bitcoin address. This is necessary so that it is clear whether or not the payment has been completed. It is also important for preserving anonymity.

In order to participate in the Bitcoin network, a Drupal website must talk to a Bitcoin node. Currently Coin Tools utilises the reference implementation, bitcoind.

bitcoind has wallet functionality built in. In fact, it was originally released as a desktop wallet for Microsoft Windows. By default, bitcoind will pre-generate a pool of 100 pairs of addresses and corresponding private keys. This pool will be increased as necessary.

This presents a number of problems. If data-loss were to occur on the server, the private keys could be unrecoverable and therefore the funds stored on the addresses would be unspendable. If a hacker gains access to the server they could copy the keys and steal the funds. The private keys can be encrypted, but the password is exposed on the server when generating new keys and spending funds.

To solve these problems, key pairs could be pre-generated in a secure environment and then the public addresses uploaded to the server.

Logistically this is challenging. A much more robust solution to this problem is to use Hierarchical Deterministic Wallets as described in BIP 32 (with draft extensions in BIPs 43, 44 & 45).

HD wallets are composed of a tree of pairs of extended public (xpub) and extended private (xprv) keys derived from a single seed or mnemonic sentence. An xprv can generate its child xpubs and child xprvs. An xpub can only generate its child xpubs. Any extended key can be converted into it's non-extended variant that cannot generate children.

A non-extended public key can be converted into a payment address. A non-extended private key can be used to spend funds that are held on the payment address it is associated with.

An example extended public key is:
xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8

An example extended private key is:
xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi

Extended key pairs are also considered to be either hardened or non-hardened. One of the properties of extended keys is that if an attacker knows a non-hardened private key and the parent xpub, they are able to determine the parent xprv.

In situations where private keys are to be distributed, for example within a company, hardened derivation must be used to prevent other private keys at the same level from being determined.

A further property of extended keys is that xpubs are not capable of generating hardened child public keys at all. This is fine because in an untrusted environment (with only a non-hardened xpub) no private keys will be present.

Payment addresses in an HD wallet can be considered to be either internal or external. External addresses are used when funds are being paid into an account from outside the wallet. Internal addresses are used as change addresses.

The default wallet layout is shown below:

HD wallets have many use-cases and BIP 32 identifies several.

"Unsecure money receiver" is the use-case to solve the problem described in this blog post.

The idea is to maintain an HD wallet in a secure environment. An account would be created in this wallet for the purpose of receiving payments in a specific Coin Tools payment type. The xpub for external addresses from this account would then be exported and added to the configuration of the payment type within Drupal.

Despite the obvious complexity of HD wallets, the concept of creating an account for a specific person, organisation or reason and exporting the xpub is actually very simple. The key point is that only one authority should be making payments into an specific xpub, otherwise addresses would be used multiple times. Scanning for unused addresses would not be an effective strategy to prevent this. Stealth addresses could become a solution for allocation of payment addresses without an authority.

Coin Tools can "interrogate" the provided xpub. The results of this process will be displayed, including the first four addresses that can be generated from the xpub and the relative path of the next address Coin Tools will generate:

Every key pair in the wallet has a path specifying the indexes at each level in the hierarchy, for example M/44'/0'/0'/0/3. Absolute paths have either an m or M as their first component. Relative paths have an index as their first component. In the example above we can see that the xpub has a depth of 3, so relative paths start with describing the index at depth 4.

A ' or H character after an index in the path indicates that the index is actually i+231. This means that keys at this level have hardened derivation.

According to BIP 43 (draft), the index at level 1 should be the hardened index of the BIP that describes the layout of the hierarchy beneath it. In the example above it is 44, meaning that it is using the layout from BIP 44 instead of the default one from BIP 32.

Despite the fact that many wallets are now HD, support for exporting account xpubs is currently quite low. However, some HD wallets that do not allow xpubs to be exported for regular accounts will allow xpubs to be exported from multisig accounts, for example Coinkite. In the future Coin Tools will support generation of addresses from multisig xpubs.

The only wallets that I know of that will export an xpub from a non-multisig account are Wallet32 and Electrum.

Both these wallets export xpubs that allow derivation of both the external (0/i) and internal (1/i) addresses. This is useful for watching an account balance but means that an entity making the payments into the account has greater ability to spy on subsequent transactions than would otherwise be possible. Coin Tools is currently hard coded to use the relative path 0/i. This will need to be made configurable as Coinkite xpubs do not need any prefix on the index.

It is essential that the addresses generated by Coin Tools match those generated by the wallet otherwise the account will not receive the payments. The xpub in the previous screenshot was exported from a Wallet32 account. In the following screenshot we can see that the addresses displayed in Wallet32 are the same as those generated by Coin Tools:

In theory when an xpub is imported the addresses should be scanned to make sure the xpub has not been used before. However, bitcoind does not maintain the correct indexes to be able to quickly list transactions for arbitrary addresses. When Coin Tools needs to receive a payment on an address from an xpub, it adds it as a watch-only address using the "importaddress" bitcoind command. The "rescan" parameter is set to false which means that transactions that happened before the address was added are not detectable. If this parameter is set to true it can take many minutes even on an SSD to import each address.

Coin Tools uses the Drupal State API to maintain the next index for each xpub. If there are more unreceived payments in a row than the gap limit of the wallet software, the wallet will loose track of later payments. To avoid this happening, payments that expire should maybe have their addresses put in a pool for re-use. However this may cause a problem if someone records the payment address and then satisfies the payment at a later time after it has expired.

Of course, if a hacker gained access to the web server they could change an xpub to their own. This would mean that until the problem was detected and the service shut down the hacker would be receiving the funds instead of the intended recipient. While damaging, this would be nowhere near as bad as the total loss of a hot wallet.

In order to facilitate handling of HD wallets, Coin Tools was converted to use the BitWasp PHP Bitcoin library instead of Gogulski.

Drupal Field collection vs Drupal Compound fields

Posted by OpenLucius on January 7, 2015 at 9:14am

We are currently working on a great project where Drupal is going to be primarily used for backend content management. The frontend will be developed in Knockout JS.

In order to exchange data between these two systems we are building an API in Drupal using the 'Services' module. We will exchange data via a 'RESTful' API.

Content model

Currently we are working on modelling the data: defining content types and fields.

In concept the content type 'Story' is displayed as follows:

Integrating Twitter feed to your Drupal site

Posted by Kristian Polso on January 7, 2015 at 7:00am
Twitter API can be a major PITA sometimes, but luckily there are modules for Drupal that makes integrating it to your website easy.

Drupal core critical issues sprint in Princeton, Jan. 29 to Feb. 1

Posted by Drupal core announcements on January 7, 2015 at 3:24am
Start:  2015-01-29 (All day) - 2015-02-01 (All day) America/New_York Sprint Organizers:  pwolanin davidhernandez

Timed to coincide with the 4th DrupalCamp NJ and focusing on issues that were not addressed at the recent sprint in Ghent, Belgium.

The focus of this sprint will be resolving critical issues around menu, menu link, and routing issues in Drupal 8.

Dates: Wednesday, January 29 through Sunday, February 1
Location: Princeton University in Princeton, NJ. (See the camp website for details.)
Travel: From Newark Airport (EWR), a good option is the Newark Airport to Princeton Junction train.

Confirmed attendees for this area of focus include pwolanin, dawehner, kgoel, and mpdonadio. Additional attendees may include xjm, Wim Leers, effulgentsia, and beejeebus.

Most of the travel expenses for attendees to work on menu, menu link, and routing issues are being paid for by a grant from the new Drupal Association Drupal 8 Accelerate program.

Additionally, local participants plan to work on core issues related to finishing the "Classy" theme in core so that the base "Stark" theme lives up to its name and serves as a true blank slate of HTML.

We only have limited additional space available, so please contact pwolanin if you'd like to participate in the sprint. Everyone is welcome attend the camp (while tickets last!) and the Drupal mentoring and collaboration day on Feb 1.

Many of the expected attendees participated in person or remote at this past summer's Drupal 8 at the Jersey Shore sprint.

AttachmentSize jerseyshore-gallery1.jpg162.94 KB

Pages

Subscribe with RSS Subscribe to Drupal.org aggregator - Planet Drupal