Skip to Content

Drupal

Configurator plugin API (cfr)

New Drupal Modules - 11 January 2016 - 5:31am

A plugin framework based on composition, interfaces and annotations.

A lot of plugin types and plugin implementations can be found in renderkit. You should look there for some inspiration.

A good start is to use this in combination with entdisp and/or listformat, which make some of the renderkit plugins available in views and other places in Drupal.

Categories: Drupal

Annertech: Tutorial: Create a Weather and News Reader App with Ionic and Drupal

Planet Drupal - 11 January 2016 - 4:55am
Tutorial: Create a Weather and News Reader App with Ionic and Drupal

During the Christmas break, I decided to give myself a challenge: increase my knowledge of app building, AngularJS, and Ionic Framework. Since I didn't know very much about any of them, that was the easy part. I then gave myself a second task - build a hybrid app for my local town that would give us home, current weather, and news tabs, with all content being derived from online data sources.

Categories: Drupal

Deeson: Rainmaker: Local Linux Development Containers for the Discerning Drupal Developer

Planet Drupal - 11 January 2016 - 4:11am

Rainmaker is a local development environment for developers. It makes use of Linux Containers to rapidly allow you to clone your whole development environment - including the codebase, files and database.

In simple terms, this lets you have one local development environment which can be branched to create other containers for development of specific features. A bit like Gitflow - but for everything, not just the codebase.

If this sparks your interest then please bear with me whilst I take you on a journey on how we got here.

The Problem

As a Drupal developer building and maintaining Drupal sites my time is broken up between:

  • Investigating and resolving bugs/defects with the current live/production version of a site
  • Applying security fixes and recommended module updates
  • Building new features

At Deeson we use Gitflow and utilise:

  • “hotfix” branches for fixing bugs, applying security updates and recommended modules updates
  • “feature” branches for site additions and new site features

We do all of our development locally creating Git tags and releasing the tagged Git revision to the production site.

Drupal 7 is notorious for putting configuration into the database that backs the site so we utilise the Drupal Features contrib module to get configuration of content types, fields, display modes, etc out of the database and into code where it can be version controlled.

In spite all of the above it is still not completely possible to prevent the Drupal database containing artefacts from other iterations of the Drupal site as you switched between your branches in Git.

This is not ideal as those artefacts can prevent the site from working correctly with the current branch that you are working with.

Real example

Consider this scenario. We are working on a new feature in a Gitflow feature branch. We have a content type named “news” with an existing field of “title” and we are adding a field named “byline”.

We used Drupal Features to get the configuration for “byline” into our “news” feature module. During the course of our development we have to make a change to the field settings for “title” in the production site.

We create a new Gitflow “hotfix” branch and check it out. If we were to list the state of our Drupal Features we would find that the “news” feature is showing as overridden. Why? Because the site database contains configuration for the “byline” field which is attached to the “news” content type and those settings are not in the “news” feature in our hotfix branch.

So, what can we do to avoid those artefacts from getting in the way of our site development?

We could dump the state of the database to disk before switching to another branch and after switching branch restore that branch’s database. Drupal databases can grow large and this can be a slow process and not very efficient for small changes we might need to make. It is also prone to human error.

OK, so why not create a database for each branch of our site?

Whilst there is an initial setup cost per branch, this is more efficient than the previous approach.

However, we would need to keep changing the database name in the Drupal settings or come up with some clever logic allowing Drupal to select the correct database based on branch. Once again this is still prone to human error.

The above approach does not solve the problem of preventing artefacts in our Solr indices. So, maybe we create separate Solr cores per site branch to avoid this? While that could work we are now growing the initial branch setup and maintenance costs.

Instead, I will simply create a new installation of the Drupal site, with its own database, Solr core. I will get a copy of the production database, maybe even the sites files, and reindex the site content into Solr.

Now we are on the right track. But the setup cost of each new branch is now massive to the point we would have to ask ourselves whether what we are going to work on warrants the setup costs or could we just live with the risk of artefacts and avoid all of this?

The Nirvana of Containerised Development

At Deeson we have been trying to solve the challenges above now for a few months and we believe we have found a strategy that is free from the kinds of human error that has been discussed above.

Imagine the scenario where we have a sort of Virtual Machine for each of the branches of a Drupal site we are working on.

Each VM runs its own database, Solr core, has its own public/private filesystem. If we had a copy of the production version of a site running in a VM, we could simply clone that VM, but the cloning would need to be quick and efficient.

Enter Linux Containers (or LXC). Linux Containers are like lightweight Virtual Machines running inside of Linux. If you place the filesystem of each container on a filesystem like BTRFS then it is possible for a Linux Container to be cloned in seconds. If we could network those containers so that our host machine could reach them and if we could introduce some DNS resolution so each container could have a unique name, then we could potentially have found our optimal solution.

Well, we have been working really hard at Deeson to make this happen and we are pleased to introduce to you the development environment we are using - Rainmaker.

This is being used in anger now but still in development. If you want to try out the latest Alpha then follow the links below - otherwise stay tuned for more updates!

Categories: Drupal

Clarify

New Drupal Modules - 11 January 2016 - 2:54am
Categories: Drupal

ThinkShout: Five Years

Planet Drupal - 11 January 2016 - 2:30am

Five years ago today, Sean and I met on the rainy steps of our attorney’s office in downtown Portland. We walked inside and proceeded to sign a small mountain of paperwork to form ThinkShout, Incorporated. Then, the two of us biked back to the 100 square foot office we’d been sharing for the previous year to figure out what the heck it meant to start a company together.

Apart from our name and commitment to helping organizations that are making a positive impact in the world, it’s safe to say that pretty much everything else at ThinkShout has changed since that first day, including the grey in our beards! Personally, the challenges we face with constant change are among the things I like most about my job. As I often say, running ThinkShout has been a new job every 6 months or so, and I’m more excited than ever to see what the future will hold.

In thinking about all that the team has accomplished and everything we’ve experienced these last five years, I spent some time looking at my first annual wrap-up post. What immediately stands out to me is that when we first started the company, most of our focus and pride came from talking about our technology contributions. We dreamt of being the “smartest geeks in the room” and bragged about how everyone at ThinkShout wrote code. Wow, was that ever naive and foolish. Just one of the many, MANY, lessons that Sean I learned as we stumbled down this path. We now understand that it takes so much more than solid technology to help an organization accomplish its goals. You need strategists to define solutions, designers to create delightful user experiences, and project managers to guide projects to success.

Of course, we are still inspired by open source innovations. In fact, this year the aggregate install base of our Drupal contributions peaked at 60,000 websites and we released perhaps our most innovative solution yet, RedHen Raiser, a viral fundraising platform based on RedHen CRM.

At the same time, our understanding of what it means to build a sustainable, values-driven business has matured. We have grown our team to 21 full-time staff, adding service offerings such as user experience design and digital fundraising strategy. We have also grown our leadership team, creating a “small council” of directors who’ve been tasked with making sure that we are responsive to the needs of both our staff and our customers.

It’s because of the strength of this team that we’ve also been able to work with some amazing clients this last year, including the relaunch of the Southern Poverty Law Center’s website, and the kickoff of a new website for The Humane Society of America. We launched 11 client websites and helped 43 organizations craft compelling digital experiences for their constituents.

This last year saw us focus on more than just our client engagements, as we increased our investment into community engagement by almost 50%. We hosted and sponsored over a dozen local events, many focused on fostering diversity in the tech industry. Similarly, we sponsored six regional and five national conferences, with our team leading over 30 hours of community trainings at these events.

We also undertook a major initiative to redefine our mission, vision, and values. Having these guideposts are critical so we don’t “lose our way” as we continue to grow. And one of my proudest experiences of being part of this team, we achieved our long time goal of becoming B Corp certified. B Corp certification provides us with guidelines, metrics, and a community of practice for all of the business decisions that we make in support of our team, our clients, our local community, and the environment. B Corp certification is our a roadmap for continuing to make intentional choices that put people and the planet above profit as we grow and continue to change over the next five, ten, fifteen years and beyond.

Categories: Drupal

Cesium

New Drupal Modules - 11 January 2016 - 1:58am

CesiumJS is an open-source JavaScript library for world-class 3D globes and maps.

This module provides the CesiumJS library integration into your Drupal project.

How to use Using a function

<?php
libraries_load('cesium');
?> In a form

<?php
$form['element']['#attached']['libraries_load'][] = array('cesium');
?>
Categories: Drupal

Commerce Billdesk

New Drupal Modules - 11 January 2016 - 1:54am
Categories: Drupal

OSTraining: Drupal 8 Themes for Beginners

Planet Drupal - 10 January 2016 - 5:21pm

A couple of years ago, we realized that a lot of Drupal beginners were asking us for simple, good-looking Drupal themes.

These beginners didn't want sub-themes, base themes, frameworks or complicated installs. So that meant no Omega, Zen, Fusion or Bootstrap. These beginners just wanted a theme could be installed easily and didn't look embarrassing. That lead to "Recommended Themes for Drupal Beginners", one of the most popular posts on this blog.

Now that Drupal 8 is here, we've started to hear the same question: "What theme should beginners use to create their first site?"

Unfortunately, the news is not good at the moment. Only 86 themes are ready for Drupal 8, and I could only find 3 that are suitable for beginners.

Categories: Drupal

Attiks: Dream permissions

Planet Drupal - 10 January 2016 - 12:57pm

The Drupal 7 admin/people/permissions is always been troublesome for big Drupal sites, there are some flaws, we hope we have solved.

By Peter Droogmans

Categories: Drupal

Phponwebsites: Drupal 7 – Hide Promoted to front page & Sticky at top of lists options

Planet Drupal - 10 January 2016 - 8:54am
    This blog describes how to hide "Promoted to front page" and "Sticky at top of lists" options from node form in drupal 7. When adding or editing a node, you can see "Publishing options" at bottom of the page which contains 'Published', 'Promoted to front page' and 'Sticky at top of lists' checkbox options. It should look like below image:


       The "Published" option is used to publish the content. The "Promoted to front page" option is used to display content in the front page. The 'Sticky at top of lists' option is used to keep the content sticked to the top of front page. If you don't want to show "Promoted to front page" and "Sticky at top of lists" options, then you can hide those options using hook_form_alter(), hook_form_FORM_ID_alter() and hook_form_BASE_FORM_ID_alter().

Hide Promoted to front page & Sticky at top of lists options in single node form:
       If you want to hide "Promoted to front page" and "Sticky at top of lists" options only in single node form, then you can remove those options from node form using either hook_form_alter() or hook_form_FORM_ID_alter() in drupal 7.  For example, we go to hide those options from article node form.
/**
 * Implement hook_form_alter().
 */
function phponwebsites_form_alter(&$form, &$form_state, $form_id) {
  // to hide promoted to front page option
  if (isset($form['options']['promote'])) {
    $form['options']['promote']['#access'] = FALSE;
  }

  // to hide sticky at top of lists option
  if (isset($form['options']['sticky'])) {
    $form['options']['sticky']['#access'] = FALSE;
  }
}
     Now you go to article node form and check whether "Promoted to front page" and "Sticky at top of lists" options are hidden or not. You couldn’t see those options in article node form. It should look like below image:

Hide Promoted to front page & Sticky at top of lists options in multiple node forms:
     If you want to hide "Promoted to front page" and "Sticky at top of lists" options in all node forms, then you can remove those options using  hook_form_BASE_FORM_ID_alter() in drupal 7.
/**
 * Implement hook_form_BASE_FORM_ID_alter().
 */
function phponwebsites_form_node_form_alter(&$form, &$form_state, $form_id) {
  // to hide promoted to front page option
  if (isset($form['options']['promote'])) {
    $form['options']['promote']['#access'] = FALSE;
  }

  // to hide sticky at top of lists option
  if (isset($form['options']['sticky'])) {
    $form['options']['sticky']['#access'] = FALSE;
  }
}
     Now you could not see those options in all node forms. Now you know how to hide "Promoted to front page" and "Sticky at top of lists" options from node form in drupal 7.Related articles:
Add new menu item into already created menu in Drupal 7
Add class into menu item in Drupal 7
Create menu tab programmatically in Drupal 7
Add custom fields to search api index in Drupal 7
Categories: Drupal

Théodore 'nod_' Biadala: Drupal gets a feature request out of the blue

Planet Drupal - 10 January 2016 - 2:42am

Word is that Drupal is getting a frontend framework. From the multiple options it seems EmberJS is currently a little ahead of Angular and React. As said in Dries original post as well as in the drupal core issue created, nothing is final and everyone interested is asked to check that the set of library in the comparison is sufficient and more importantly that the criteria used for evaluation are relevant.

Discussing those details is not what this post is about, like others I've been questioning the move from Dries. Since many of us are professionals, let's put this in a professional setting and pretend that Dries is just another client making a feature request seemingly out of the blue. To him the problem and solution is clear — obvious even — and it is the only way to achieve his vision. Let's check.

Client side (pun intended)

Drupal's user interfaces for content modeling (Field UI), layout management (Panels), and block management would benefit from no page refreshes, instant previews, and interface previews. These traits could also enrich the experience of site visitors; Drupal's commenting functionality could similarly gain from these characteristics and resemble an experience more like the commenting experience found in Facebook.

Should we decouple Drupal with a client-side framework?.

Pretty weak set of reasons. What is described later in the post can be achieved though regular Ajax and some resonable amount of javascript. Hardly a need for a frontend framework… until you remember what else Dries has been writing about.

As the Drupal community, we need to stop thinking of Drupal as a "content management platform" and start looking at it as a "digital experience platform" used to create ideal visitor experiences.

From content management to digital experience management.

Ideal as in enriched as in, for example, Acquia Lift. Don't get your pitchforks just now, there is no hidden agenda, just finish reading.

How serious is the client

Sometimes features can be swept under the rug and everyone will feel better in the long term. Sometimes the client does not let it go. So how serious is Dries about this? The two posts directly related to frameworks contain 3 387 words and if you include the related posts you can add 10 394 more words. A busy person doesn't write a short story just for fun. So I'd say he is pretty serious about this, and if you read the trail of posts this is not going away.

Client needs

We know a few things about what the client is trying to address:

  1. He expects the web to be completely different in 10 years.
  2. Most sites will need personalization.
  3. Better UX is crucial.
  4. One solution fitting core and contrib.

Since there needs to be one solution, it has to be in core from the start because contrib is not disciplined enough (by design) to come up with one homogeneous solution in less than 10 years.

A little extrapolation

If you have in mind all the posts Dries has been writting on the topic for the past two years it makes sense that web components or websockets do not address the issue of rich interfaces the way a frontend framework would, also in this discussion any PHP-based solution is off-topic. It looks to me that Dries is trying to get the community as well as Drupal ready for what he believes is coming. I deeply disagree on what the future holds for the web but it doesn't mean nothing should be done, just in case. At worst we'll burn the new people who came to help us switch to the new framework.

Solution

All in all, I would agree that under those assumptions, a framework is a valid tool to be using. Putting my JS maintainer hat on I would suggest to jQueryUI-it. Put it in core and use it anecdotally, and hope contrib will pick it up. Also we should chose the framework with the strongest opinion on how to do things. Because Drupal back-end is rather strongly opinionated about what the PHP should look like. It makes sense the JS should be the same.

On Acquia bashing

I've spent more than 2 years as an Acquia consultant, working closely with the Office of the CTO on several big D8 improvements so I've seen how the community is treated from the inside and I've only seen good will towards it. Sometimes things are downplayed, not out of malice, but out of concern for the issue at hand. Which is why I think Dries didn't explicitly mentioned Acquia Lift — but still hinted to it — to not get dragged in an argument about Acquia's influence. There is nothing wrong with that since compared to the fears expressed during D8 cycle, we're far from the worst scenario possible.

On that topic, when people say that Acquia, big companies or startups are influencing Drupal I think they're taking a shortcut. It's more like Acquia clients are influencing Dries, and in turn he steers Drupal to what he thinks is right. But don't forget that between clients and Drupal there is a filter, it's Dries. So far I think we can agree he's been pretty great at Dictatoring Drupal. So let's at least give him the benefit of the doubt.

Put your pitchforks back and grab some paint, there is a bikeshed to paint.

Categories: Drupal
Syndicate content


Google+
about seo