Drupal Association blog: Call for Design Partners

Planet Drupal - Thu, 2017/02/09 - 12:33am

The Drupal Association is seeking a design partner for creative, graphic and website design services for a new DrupalCon brand. We're looking for people who understand the Drupal community, Drupal the project, software innovation, and our extreme nerdiness - and know how to turn these things into compelling designs that are functional, fun, and make people look twice. 

Main Deliverables

  • Overall conference branding
  • Content hierarchy and IA for the DrupalCon website
  • Design and theming
  • Digital and print graphics design

Scope of Work

The design partner's work will reinforce a positive brand image of DrupalCon to attendees and within the Drupal community year-round. The design should reflect DrupalCon's position as a major international software conference and the community connections that make DrupalCon a unique event. The SOW may include, but is not limited to, the following:

  • Overall creative design of DrupalCon brand
  • Digital outreach: newsletter templates, social media profiles (theme/icons), badges, ads
  • Signage: venue signage, banners, sponsor signs
  • Materials: slide decks, volunteer/staff clothing, giveaway items
  • Print: letterhead/templates, badgelettes, sponsorship guide
  • Style guide: production and use guides
  • Theming for the DrupalCon website


The design partner will coordinate final design deliverables and production schedule with Drupal Association staff, and will actively participate in weekly planning meetings. 

Proposal Process

Please download the complete RFP which outlines the proposal process and requirements, and provides specific instructions on submission and question and answer processes. 


Proposals are due February 22, 2017 23:49 EST (UTC-5). Please refer to the RFP for a full award timeline. 

Selection Criteria

The respondent whole proposal best meets the needs of the project will be selected according to the following criteria:

  • Thoroughness of proposal
  • Demonstrated understanding of the project
  • Quality of work samples provided
  • Outcome of phone/video interview
  • Availability and responsiveness of the project team


The Drupal Association's budget for DrupalCon design work is $30,000. The designer or company will also receive public recognition on the site via footer credits for 3 years and volunteer credits, and will receive a Bronze Sponsorship for the 2018 North America DrupalCon. 


Mediacurrent: Rethinking Theme Structure in Drupal 8

Planet Drupal - Wed, 2017/02/08 - 9:50pm

Most web pages share pieces that are reused throughout the entire site. While I’ve heard them called different things, I prefer to call them components. Some examples include the header, footer, main navigation, logo, slideshow and so on. Most of these can be broken down into smaller components as well. For example, maybe the header is a specific layout that includes the main navigation and the logo.


Mediacurrent: If You Wanna Be My Vendor ...

Planet Drupal - Wed, 2017/02/08 - 6:16pm

If you wanna be my vendor, you’ve gotta get with my friends: Drupal, Open Source, and Communication.


Acquia Developer Center Blog: 246: Don't miss Drupal Camp London 2017!

Planet Drupal - Wed, 2017/02/08 - 5:54pm

A conversation about the event and why you should be there, too, this time around with Ben Wilding and Waliur Rahman, members of the 2016 Drupal Camp London organizing team.

Come along March 3-5, 2017, to Europe's biggest (best?) community event on the calendar!

Tickets and information here: http://drupalcamp.london

Skill Level: BeginnerIntermediateAdvanced

Acquia Developer Center Blog: Drupal 8 Module (Distro!) of the Week: Open Social

Planet Drupal - Wed, 2017/02/08 - 4:51pm

This week: Open Social, a community-building distribution // Drupal 8 has more and more features available practically every day. Alongside module migrations and new projects, the Drupal community’s latest major release also offers new ways of solving common problems. Some functionality has moved to Drupal core and new modules have taken up the torch along the way. In this series, the Acquia Developer Center is profiling useful solutions--modules, themes, distros, and more--available for Drupal 8.

Tags: acquia drupal planetopen socialintranetcommunity

clemens-tolboom opened pull request addwiki/wikibase-api#44

On github - Wed, 2017/02/08 - 3:24pm
Feb 8, 2017 clemens-tolboom opened pull request addwiki/wikibase-api#44 Add more libs to composer.json 1 commit with 3 additions and 0 deletions

Deeson: Delivering great work is easier when the client is having fun

Planet Drupal - Wed, 2017/02/08 - 12:01pm

I know putting the words “fun” and “work” together is a strange concept for some people, but I think it can be achieved. Teams that have fun collaborate better and strong collaboration is a key ingredient to any successful project.

Fun could mean different things to different people, so for the benefit of this article let's just say that ‘fun’ means the team get along and enjoy what they are doing.

Here are a couple of ideas on how to inject some fun into your projects.

Kick off with some games

Deeson believe it's worth investing in the human foundations of our relationship and play a game on the kick off day. Not just any game, but a game which can have a meaningful pay-off further down the line or help foster a good relationship, for example one which might help the client get used to working in an agile manner. The tennis ball game is a good example of this.

Create a sense of shared identity

Coming up with a name and a ‘brand’ for a project, something short and snappy ideally, is a fun way to create a shared sense of identity and ownership between the project team. Once the project name has been decided, the designer could create a logo for the project which can then go on all presentations and documentation.

You could even go one step further and have some merchandise made; mugs are great, but things like t-shirts and stuffed toys work too. The items should only be available to the project team. This will get the whole team engaged with the project.

Add some bounce to the process

When working in Scrum, the team has a stand-up every morning to say what they did yesterday, what they are doing today and if they have any blockers. Now although the guidelines say that you shouldn’t invite the product owner to a standup. However, in an agency to client situation, this could mean the product owner could feel left out. So invite the product owner along to standups and encourage them to take part. The ideal standup would be everyone in the same room giving their update, but if this is not possible then have a video call, this makes it feel more personal.

Within a sprint there will be a few meetings, but try and make one of them in person. Sprint planning is a good meeting to have in person, as its easier to discuss things with everyone in the same room than having everyone on a video call.

When having meetings use a timer and the pomodoro method, so have a set goal for the next 25 minutes and then have a 5 minute break to get a drink or talk to the team and client about non work related things.

When in sprint planning, you can add a gaming element by using planning poker cards. These cards have the double benefit of being quite a laid back way of estimating tasks, but it also eliminates unhelpful bias and allows the team to make individual and impartial decisions on the length of time needed to complete a story.

Clear communication enables strong relationships

Having a team retrospective really helps a team to bond. In this meeting it's always worth considering the prime directive. "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."

The outcomes of the retrospective should be discussed and if any changes are needed, then they should be made and tried out on the next sprint. We won’t want anyone on the team being unhappy or annoyed as this could damage the relationships that have been built.

It can be useful to try some different approaches to retrospectives to keep them fresh. For example, you could get use the sailboat retrospective.

Most importantly - celebrate together!

If a team is doing all of the above then I would say that they are on the right track. But after all the hard work and effort you’ve put in, it’s a good idea to let your hair down and celebrate a major release or significant project milestone. Get the project team together to either have a meal or a drink and take time to reflect on what’s been achieved by the collective.

Breaking down the ‘client vs agency’ dynamic, and helping everyone become part of one team, is a key step towards having fun and delivering great, innovative work.  


Third & Grove: Boston Herald Drupal Case Study

Planet Drupal - Wed, 2017/02/08 - 9:00am
Boston Herald Drupal Case Study antonella Wed, 02/08/2017 - 03:00

Drupal CMS Guides at Daymuse Studios: Products & Product Types in Drupal Commerce Module Guide

Planet Drupal - Wed, 2017/02/08 - 2:49am

Our first Drupal Commerce Module Guide begins our e-commerce site creation tutorial. We need to understand what Product and Product Types are and how to implement them.


Deeson: Getting started with Drupal 8 and Composer

Planet Drupal - Wed, 2017/02/08 - 12:00am

At Deeson we are constantly looking for ways to improve the way we work, iterating on past projects to incorporate new techniques and best-practices.

We starting playing with Composer recently, as a tool for speeding up Drupal module updates. There were a few quirks, but it generally worked.

Then we discovered the Drupal Composer project, which makes it much simpler to manage Drupal core as well as modules.

This is great! We can use Composer to install and update Drupal core, modules and themes, and all in a consistent manner; anyone can run Composer and end up with the exact same set of code.

So now we can start excluding some of the off-the-shelf code from our Git repository (contrib modules, themes, and libraries.) This slims down our repositories and speeds up development for the whole team.

Combined with our approach to managing settings we’re really starting to limit the amount of custom stuff in the docroot now.

Having recently completed a site using this approach I started thinking: “Why do we even need the docroot in Git?”

So we got rid of it! One of the many benefits of working in self-managing teams!

We now have a very flat repository structure where the entire docroot is compiled during deployments. The project repository contains a CMI config directory, settings.php, modules and themes directories, and the all-important composer.json which manages everything that isn’t project-specific custom code.

Internally we use Bitbucket pipelines to manage building and deploying our projects.

Every commit triggers a pipelines build. The docroot is built, tests are run, and if all goes well, it gets pushed to the hosting platform.

We have put together a small Composer script which simply symlinks the modules, themes and settings into the docroot when running composer install. The rest of the build is vanilla composer.

Our composer.json is based on the version provided by Drupal Composer, but with a change to the post-install-cmd and post-update-cmd hooks.

"scripts": { "drupal-scaffold": "DrupalComposer\\DrupalScaffold\\Plugin::scaffold", "pre-install-cmd": [ "DrupalProject\\composer\\ScriptHandler::checkComposerVersion" ], "pre-update-cmd": [ "DrupalProject\\composer\\ScriptHandler::checkComposerVersion" ], "post-install-cmd": [ "@drupal-scaffold", "DrupalProject\\composer\\DeesonScriptHandler::createRequiredFiles" ], "post-update-cmd": [ "@drupal-scaffold", "DrupalProject\\composer\\DeesonScriptHandler::createRequiredFiles" ] }

Here we have replaced the script handler plugin with our own customised version, which creates the symlinks mentioned above during composer install and composer update. We also run the Drupal Scaffold plugin on every Composer install or Composer update, to ensure that all of the extra Drupal files like index.php and update.php exist in the docroot.

Taking the Drupal docroot out of our project repositories has required a shift in the way we think about developing Drupal projects, but ultimately we believe it has streamlined and simplified our development workflows.

We have turned this approach into a Drupal 8 Quick Start template, which can be used to very quickly get up and running with Drupal 8 using a composer-based workflow. The project is available on Github. PRs welcome!


Agaric Collective: Help kick the door for new contributors to Drupal back open (and get credit for it)

Planet Drupal - Tue, 2017/02/07 - 10:15pm

After years of giving a terrible initial experience to people who want to share their first project on Drupal.org, the Project Applications Process Revamp is a Drupal Association key priority for the first part of 2017.

A plan for incentivizing code review of every project, not just new ones, after the project applications revamp is open for suggestions and feedback.

Which makes it excellent timing that right now you can get credit on your Drupal.org profile and that of your organization, boosting marketplace ranking, for reviewing the year-old backlog of project applications requesting review. The focus is on security review for these project applications, but if you want to give a thorough review and then give your thoughts on how project reviews (for any project that opts in to this quality marker) should be performed and rewarded going forward, now's the time and here's the pressing need.


InternetDevels: Drupal 8 SEO Checklist module: your reliable website optimization adviser

Planet Drupal - Tue, 2017/02/07 - 5:18pm

To do: improve your Drupal website’s SEO. This sounds like a pretty big task when it’s written out like that on your list! ;) Big tasks are easier to cope with when they are divided into clear, smaller steps. Great news! You can have a smart adviser, named SEO Checklist module, who can give you this list of steps and prompt you how to fulfill them.

Read more

Flocon de toile | Freelance Drupal: Create an action for custom mass updates with Drupal 8

Planet Drupal - Tue, 2017/02/07 - 4:00pm

Drupal 8 makes it possible to carry out certain mass actions on the site's contents, such as publishing or unpublishing massively contents, positioning them at the top of lists, etc. It may be useful to provide to certain user profiles some customized actions related to the specificities of their site, such as highlighting certain taxonomy terms, changing the value of a specific field, and thus avoiding heavy and tedious update operations to users on each of the content to be modified.


Drupal Association blog: Drupal in Europe - Community Survey

Planet Drupal - Tue, 2017/02/07 - 3:17pm

TL;DR If you are a European community member, please take our community survey about Drupal in Europe.

After 6+ years working at the Drupal Association and knowing so many members around the world, it’s easy for me to think I know what is going on with the Project. But, it is a big world and each region, country, and local market has unique, evolving needs.

To avoid assuming the best way to help the community, I am asking for your input. I'm gathering insight one region at a time. I’ll share the feedback with staff and the Drupal Association Board to refine how we serve the community.

I’m starting first with our European community. This is so it's well timed with our DrupalCon Europe planning. In fact, the Drupal Association Board meets on 23 and 24 February where we will strategize how we can best support the European community. We’ll use your input to drive that discussion.

I’m collecting input in a few ways. Recently, I held roundtable discussions with various community organizers. Now I’m opening up the discussion to all who Drupal in Europe. Please tell me how the Drupal Association can best support Drupal by taking this community survey before February 16th.

Thanks for sharing your thoughts and needs. I look forward to hearing from you.


2bits: How to configure Varnish Cache for Drupal with SSL Termination Using Pound or Nginx

Planet Drupal - Tue, 2017/02/07 - 1:49pm

Secure Socket Layer (SSL) is the protocol that allows web sites to serve traffic in HTTPS. This provides end to end encryption between the two end points (the browser and the web server). The benefits of using HTTPS is that traffic between the two end points cannot be deciphered by anyone snooping on the connection. This reduces the odds of exposing sensitive information such as passwords, or getting the web site hacked by malicious parties. Google has also indicated that sites serving content exclusively in HTTPS will get a small bump in Page Rank.

Historically, SSL certificate issuers have served a secondary purpose: identity verification. This is when the issuing authority vouches that a host or a domain is indeed owned by the entity that requests the SSL certificate for it. This is traditionally done by submitting paper work including government issued documentation, incorporation certificates, ...etc.

Historically, SSL certificates were costly. However, with the introduction of the Let's Encrypt initiative, functional SSL certificates are now free, and anyone who wants to use them can do so, minus the identity verification part, at least for now.

Implementing HTTPS with Drupal can be straightforward with low traffic web sites. The SSL certificate is installed in the web server, and that is about it. With larger web sites that handle a lot of traffic, a caching layer is almost always present. This caching layer is often Varnish. Varnish does not handle SSL traffic, and just passes all HTTPS traffic straight to Drupal, which means a lot of CPU and I/O load.

This article will explain how to avoid this drawback, and how to have it all: caching in Varnish, plus serving all the site using HTTPS.

The idea is quite simple in principle: terminate SSL before Varnish, which will never know that the content is encrypted upstream. Then pass the traffic from the encryptor/decryptor to Varnish on port 81. From there, Varnish will pass it to Apache on port 8080.

We assume you are deploying all this on Ubuntu 16.04 LTS, which uses Varnish 4.0, although the same can be applied to Ubuntu 14.04 LTS with Varnish 3.0.

Note that we use either one of two possible SSL termination daemons: Pound and Nginx. Each is better in certain cases, but for the large part, they are interchangeable.

One secondary purpose for this article is documenting how to create SSL bundles for intermediate certificate authorities, and to generate a combined certificate / private key. We document this because of the sparse online information on this very topic.

Install Pound aptitude install pound Preparing the SSL certificates for Pound

Pound does not allow the private key to be in a separate file or directory from the certificate itself. It has to be included with the main certificate, and with intermediate certificate authorities (if there are any).

We create a directory for the certificates:

mkdir /etc/pound/certs

cd /etc/pound/certs

We then create a bundle for the intermediate certificate authority. For example, if we are using using NameCheap for domain registration, they use COMODO for certificates, and we need to do the following. The order is important.

cat COMODORSADomainValidationSecureServerCA.crt \
  COMODORSAAddTrustCA.crt \
  AddTrustExternalCARoot.crt >> bundle.crt

Then, as we said earlier, we need to create a host certificate that includes the private key.

cat example_com.key example_com.crt > host.pem

And we make sure the host certificate (which contains the private key as well) and the bundle, are readable only to root.

chmod 600 bundle.crt host.pem Configure Pound

We then edit /etc/pound/pound.cfg

# We have to increase this from the default 128, since it is not enough
# for medium sized sites, where lots of connections are coming in
Threads 3000

# Listener for unencrypted HTTP traffic
  Port    80
  # If you have other hosts add them here
    HeadRequire "Host: admin.example.com"
      Port 81
  # Redirect http to https
    HeadRequire "Host: example.com"
    Redirect "https://example.com/"
  # Redirect from www to domain, also https
    HeadRequire "Host: www.example.com"
    Redirect "https://example.com/"

# Listener for encrypted HTTP traffic
  Port    443
  # Add headers that Varnish will pass to Drupal, and Drupal will use to switch to HTTPS
  HeadRemove      "X-Forwarded-Proto"
  AddHeader       "X-Forwarded-Proto: https"
  # The SSL certificate, and the bundle containing intermediate certificates
  Cert      "/etc/pound/certs/host.pem"
  CAList    "/etc/pound/certs/bundle.crt"
  # Send all requests to Varnish
    HeadRequire "Host: example.com"
      Port 81
  # Redirect www to the domain
    HeadRequire "Host: www.example.com.*"
    Redirect "https://example.com/"

Depending on the amount of concurrent traffic that your site gets, you may need to increase the number of open files for Pound. To do this, edit the file /etc/default/pound, and add the following lines:

# Increase the number of open files, so pound does not log errors like:
# "HTTP Acces: Too many open files"
ulimit -n 20000

Do not forget to change the 'startup' line from 0 to 1, otherwise pound will not start.

Configure SSL Termination for Drupal using Nginx

You may want to use Nginx instead of the simpler Pound in certain cases. For example, if you want to handle redirects from the plain HTTP URLs to the corresponding SSL HTTPS URls. Pound cannot do that. It redirects to the home page of the site instead.

Also, if you want to process your site's traffic using analysis tools, for example Awstats, you need to capture those logs. Although Pound can output logs in Apache combined format, it also outputs errors to the same log, at least on Ubuntu 16.04, and that makes these logs unusable by analysis tools.

First install Nginx:

aptitude install nginx

Create a new virtual host under /etc/nginx/sites-available/example.com, with this in it:

# Redirect www to no-www, port 80
server {
  server_name www.example.com;

  # Replace this line with: 'access_log off' if logging ties up the disk
  access_log /var/log/nginx/access-example.log;
  # Permanent redirect
  return 301 https://example.com$request_uri;

# Redirect www to no-www, SSL port 443
server {
  listen 80 default_server;
  listen [::]:80 default_server ipv6only=on;

  server_name example.com;

  # Replace this line with: 'access_log off' if logging ties up the disk
  access_log /var/log/nginx/access-example.log;
  # Permanent redirect
  return 301 https://$host$request_uri;

server {
  listen 443 ssl default_server;
  listen [::]:443 ssl default_server ipv6only=on;

  server_name example.com;

  # We capture the log, so we can feed it to analysis tools, e.g. Awstats
  # This will be more comprehensive than what Apache captures, since Varnish
  # will end up removing a lot of the traffic from Apache
  # Replace this line with: 'access_log off' if logging ties up the disk
  access_log /var/log/nginx/access-example.log;

  ssl on;

  # Must contain the a bundle if it is a chained certificate. Order is important.
  # cat example.com.crt bundle.crt > example.com.chained.crt 
  ssl_certificate      /etc/ssl/certs/example.com.chained.crt;
  ssl_certificate_key  /etc/ssl/private/example.com.key;

  # Test certificate
  #ssl_certificate     /etc/ssl/certs/ssl-cert-snakeoil.pem;
  #ssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key;

  # Restrict to secure protocols, depending on whether you have visitors
  # from older browsers
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

  # Restrict ciphers to known secure ones

  ssl_prefer_server_ciphers on;
  ssl_ecdh_curve secp384r1;
  ssl_stapling on;
  ssl_stapling_verify on;

  add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
  add_header X-Frame-Options DENY;
  add_header X-Content-Type-Options nosniff;

  location / {
    proxy_pass               ;
    proxy_read_timeout                 90;
    proxy_connect_timeout              90;
    proxy_redirect                     off;

    proxy_set_header Host              $host;
    proxy_set_header X-Real-IP         $remote_addr;
    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header X-Forwarded-Port  443;
    proxy_buffers                      8 24k;
    proxy_buffer_size                  2k;

Then link this to an entry in the sites-enabled directory

cd /etc/nginx/sites-enabled

ln -s /etc/nginx/sites-available/example.com

Then we add some performance tuning parameters, by creating a new file: /etc/nginx/conf.d/tuning. These will make sure that we handle higher traffic than the default configuration allows:

worker_processes       auto;

worker_rlimit_nofile   20000;

events {
  use epoll;
  worker_connections 19000;
  multi_accept       on;

http {
  sendfile           on;
  tcp_nopush         on;
  tcp_nodelay        on;
  keepalive_timeout  65;
  keepalive_requests 10000;
  client_body_buffer_size 128k;   

We now have either Pound or Nginx in place, handling port 443 with SSL certifcates, and forwarding the plain text traffic to Varnish.

Change Varnish configuration to use an alternative port

First, we need to make Varnish work on port 81.

On 16.04 LTS, we edit the file: /lib/systemd/system/varnish.service. If you are using Ubuntu 14.04 LTS, then the changes should go into /etc/default/varnish instead.

Change the 'ExecStart' line for the following:

Port that Varnish will listen on (-a :81)
Varnish VCL Configuration file name (/etc/varnish/main.vcl)
Size of the cache (-s malloc,1536m)

You can also change the type of Varnish cache storage, e.g. to be on disk if it is too big to fit in memory (-s file,/var/cache/varnish/varnish_file.bin,200GB,8K). Make sure to create the directory and assign it the correct owner and permissions.

We use a different configuration file name so as to not overwrite the default one, and make updates easier (no questions asks during update to resolve differences).

In order to inform systemd that we changed a daemon startup unit, we need to issue the following command:

systemctl daemon-reload Add Varnish configuration for SSL

We add the following section to the Varnish VCL configuration file. This will pass a header to Drupal for SSL, so Drupal will enforce HTTPS for that request.

# Routine used to determine the cache key if storing/retrieving a cached page.
sub vcl_hash {

  # This section is for Pound

  if (req.http.host) {
  else {

  # Use special internal SSL hash for https content
  # X-Forwarded-Proto is set to https by Pound
  if (req.http.X-Forwarded-Proto ~ "https") {

Change Apache's Configuration

If you had SSL enabled in Apache, you have to disable it so that only Pound (or Nginx) are listening on port 443. If you do not do this, Pound and Nginx will refuse to start with an error: Address already in use.

First disable the Apache SSL module.

a2dismod ssl

We also need to make Apache listen on port 8080, which Varnish will use to forward traffic to.

Listen 8080

And finally, your VirtualHost directives should listen on port 8080, as follows. It is also best if you restrict the listening on the localhost interface, so outside connections cannot be made to the plain text virtual hosts.


The rest of Apache's configuration is detailed in an earlier article on Apache MPM Worker threaded server, with PHP-FPM.

Configure Drupal for Varnish and SSL Termination

We are not done yet. In order for Drupal to know that it should only use SSL for this page request, and not allow connections from plain HTTP, we have to add the following to settings.php:

// Force HTTPS, since we are using SSL exclusively
  if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') {
    $_SERVER['HTTPS'] = 'on';

If you have not already done so, you also have to enable page cache, and set the external cache age for cached pages. This is just a starting point, assuming Drupal 7.x, and you need to modify these accordingly depending on your specific setup.

// Enable page caching
$conf['cache'] = 1;
// Enable block cache
$conf['block_cache'] = 1;
// Make sure that Memcache does not cache pages
$conf['cache_lifetime'] = 0;
// Enable external page caching via HTTP headers (e.g. in Varnish)
// Adjust the value for the maximum time to allow pages to stay in Varnish
$conf['page_cache_maximum_age'] = 86400;
// Page caching without bootstraping the database, nor invoking hooks
$conf['page_cache_without_database'] = TRUE;
// Nor do we invoke hooks for cached pages
$conf['page_cache_invoke_hooks'] = FALSE;

// Memcache layer
$conf['cache_backends'][]    = './sites/all/modules/contrib/memcache/memcache.inc';
$conf['cache_default_class'] = 'MemCacheDrupal';
$conf['memcache_servers']    = array('' => 'default');
$conf['memcache_key_prefix'] = 'live';

And that is it. Now restart all the daemons:

service pound restart
service nginx restart # If you use nginx instead of pound
service varnish restart
service apache2 restart

Check that all daemons have indeed restarted, and that there are no errors in the logs. Then test for proper SSL recognition in the browser, and for correct redirects.

For The Extreme Minimalist: Eliminating Various Layers

The above solution stack works trouble free, and has been tested with several sites. However, there is room for eliminating different layers. For example, instead of having Apache as the backend web server, this can be replaced with Nginx itself, listening on both port 443 (SSL), and 8080 (backend), with Varnish in between. In fact, it is possible to even remove Varnish altogether, and use Ngnix FastCGI Cache instead of it. So Nginx listens on port 443, decrypts the connection, and passes the request to its own cache, which decides what is served from cache versus what gets passed through to Nginx itself on port 8080, which hands it over to PHP and Drupal.

Don't let the words 'spaghetti' and 'incest' take over your mind! Eventually, all the oddities will be ironed out, and this will be a viable solution. There are certain things that are much better known in Apache for now in regards to Drupal, like URL rewriting for clean URLs. There are also other things that are handled in .htaccess for Apache that needs to gain wider usage within the community before an Nginx only solution becomes the norm for web server plus cache plus SSL.

Apache MPM Worker Multithreaded with PHP-FPM is a very low overhead, high performance solution, and we will continue to use it until the Nginx only thing matures into a wider used solution, and has wider use and support within the Drupal community to remain viable for the near future.

Tags: Contents: 

Vardot: Install Apache Solr 5.x for a Drupal Website on Ubuntu

Planet Drupal - Tue, 2017/02/07 - 1:24pm
How to Read time: 2 minutes

To install Apache Solr and run it with a Drupal website on an Ubuntu server. Follow these steps:

Install Java

You need to make sure you have Java installed.
To check run this command:

java -version

If it's not installed, simply install from packages:

sudo apt-get -y install openjdk-7-jdk jetty


Install Latest Apache Solr 5.x

Download the latest zip file release 5.x.x from http://mirror.cc.columbia.edu/pub/software/apache/lucene/solr/

Unzip the downloading: 

unzip solr-5-x-x.zip;

More the unzipped folder to where is should be:

sudo mv solr-5-x-x /usr/local/solr cd /usr/local/solr


Configuring Apache Solr for your Drupal site

Make a copy of the Solr core to be used for Drupal sites

cp -r example/ drupal/

Create cores for your sites. Every core is an instance of a Drupal site:

cd drupal/multicore sudo cp -r core0 MYSITENAME

Edit the solr.xml to add your new core:

sudo vim solr.xml

and add a new core similar to:

<core name="My Site Name" instanceDir="MYSITENAME" />


Replace the default Solr configuration with the Drupal  Solr configuration provided from the Search API Solr Search module.

sudo rm -r MYSITENAME/conf sudo cp -r /PATH/TO/DRUPAL/sites/all/modules/contrib/search_api_solr/solr-conf/5.x /usr/local/solr/drupal/multicore/conf/MYSITENAME/conf


Start Solr

cd .. java -Dsolr.solr.home=multicore -jar start.jar


Create Solr user

sudo useradd -d /usr/local/solr -M -s /usr/sbin/nologin solr sudo chown -R solr:root /usr/local/solr


Add Solr as a Service

Download the init.d script to start Apache Solr. Thanks to 2bits.

wget http://2bits.com/sites/2bits.com/files/solr-init.d.sh_.txt sudo mv solr-init.d.sh_.txt /etc/init.d/solr

Edit the file to suit your environment and change the SOLR_HOME=/opt/solr/example environment variable (line 18) to /usr/local/solr/drupal

sudo vim /etc/init.d/solr

Replace line 18 to be:



Make the service to work properly:

sudo chmod a+rx /etc/init.d/solr sudo update-rc.d solr defaults


Access Solr

Your Solr URL will be: http://localhost:8983/solr/#

If you want to setup authentication for Solr, please follow: http://2bits.com/articles/configuring-apache-solr-4x-drupal-password-aut...

Tags:  Drupal Solr Setup Guide Drupal Planet Title:  Install Apache Solr 5.x for a Drupal Website on Ubuntu

Drupal Modules: The One Percent: Drupal Modules: The One Percent — Contact Emails (video tutorial)

Planet Drupal - Mon, 2017/02/06 - 10:39pm
Drupal Modules: The One Percent — Contact Emails (video tutorial) NonProfit Mon, 02/06/2017 - 15:39 Episode 18

Here is where we bring awareness to Drupal modules running on less than 1% of reporting sites. Today we'll investigate Contact Emails, a module which allows a single contact form submission to be sent to multiple users each of which contains unique subject and body fields.


Drupal @ Penn State: Web components, Polymer and decoupling design in Drupal

Planet Drupal - Mon, 2017/02/06 - 9:54pm

UPDATE: You should also read this great post from Mediacurrent: Benefits of decoupled architecture