Drupal Feeds

MidCamp - Midwest Drupal Camp: Call for Volunteers

Feeds from Drupal.org - Tue, 2017-03-21 19:12
We need you!

Want to give back to the Drupal Community without writing a line of code? Volunteer to help out at MidCamp 2017.  We’re looking for people to help with all kinds of tasks including: 

Setup/Teardown
  • For setup, we need help making sure registration is ready to roll, and getting T-shirts ready to move.

  • For teardown, we need to undo all the setup including packing up all the rooms, the registration desk, cleaning signage, and making it look like we were never there.

Registration and Ticketing
  • We need ticket scanners, program dispersers, and people to answer questions.

Room Monitors
  • Pick your sessions and count heads, make sure the speakers have what they need to survive, and help with the in-room A/V

If you’re interested in volunteering or would like to find out more, please contact us.

Volunteer!

Categories: Straight From Drupal

Acquia Lightning Blog: Forward Revisions and Translated Content

Planet Drupal - Tue, 2017-03-21 18:46
Forward Revisions and Translated Content Adam Balsam Tue, 03/21/2017 - 14:46

Core contributors are currently working on a solution for #2766957 Forward revisions + translation UI can result in forked draft revisions. This issue can affect users of Workbench Moderation (that is, users of Lightning) too though.

The problem presents itself when:

  • The site uses Lightning Workflow
  • Content Translation is enabled with at least one additional language defined (let's say English and Spanish) 
  • A piece of content exists where:
    • There is a published English and a published Spanish version of the content.
    • Both the English and Spanish version have unpublished edits (AKA forward revisions).
  • An editor publishes the forward revision for either the English or Spanish version (let's say English).

The result is the existing published Spanish version becomes unpublished - even though the editor took no action on that version at all. This is because the system is marking the unpublished Spanish version as the default revision.

A workaround exists in the Content Translation Workflow module. If you are still using Drupal core 8.2.x (which, as of this writing, Lightning is) you will also need a core patch that adds a getLoadedRevisionId() method to ContentEntityBase.

Workaround Summary
  1. Apply this core patch.
  2. Add the Content Translation Moderation module to your codebase and enable it.

For more information and demonstration of the bug and the fix, see the video below.

Note: This is an alpha module with known issues and, by definition, is not covered by the Drupal Security policy and may have security vulnerabilities publicly disclosed.

Note: The Content Translation Workflow module works around the original issue by creating an additional revision based on the current default revision. This preserves existing forward revisions and their content, but effectively makes them past (rather than forward) revisions.

Bonus: The author of Content Translation Workflow, dawehner, has also created a companion module Content Translation Revision which adds a nice UI to translate individual revisions.

Acquia Lightning Blog: Forward Revisions and Translated Content

Feeds from Drupal.org - Tue, 2017-03-21 18:46
Forward Revisions and Translated Content Adam Balsam Tue, 03/21/2017 - 14:46

Core contributors are currently working on a solution for #2766957 Forward revisions + translation UI can result in forked draft revisions. This issue can affect users of Workbench Moderation (that is, users of Lightning) too though.

The problem presents itself when:

  • The site uses Lightning Workflow
  • Content Translation is enabled with at least one additional language defined (let's say English and Spanish) 
  • A piece of content exists where:
    • There is a published English and a published Spanish version of the content.
    • Both the English and Spanish version have unpublished edits (AKA forward revisions).
  • An editor publishes the forward revision for either the English or Spanish version (let's say English).

The result is the existing published Spanish version becomes unpublished - even though the editor took no action on that version at all. This is because the system is marking the unpublished Spanish version as the default revision.

A workaround exists in the Content Translation Workflow module. If you are still using Drupal core 8.2.x (which, as of this writing, Lightning is) you will also need a core patch that adds a getLoadedRevisionId() method to ContentEntityBase.

Workaround Summary
  1. Apply this core patch.
  2. Add the Content Translation Moderation module to your codebase and enable it.

For more information and demonstration of the bug and the fix, see the video below.

Note: This is an alpha module with known issues and, by definition, is not covered by the Drupal Security policy and may have security vulnerabilities publicly disclosed.

Note: The Content Translation Workflow module works around the original issue by creating an additional revision based on the current default revision. This preserves existing forward revisions and their content, but effectively makes them past (rather than forward) revisions.

Bonus: The author of Content Translation Workflow, dawehner, has also created a companion module Content Translation Revision which adds a nice UI to translate individual revisions.

Categories: Straight From Drupal

Palantir: Competitive Analysis: The Key to a Woman's Healthy Heart - Part 1

Planet Drupal - Tue, 2017-03-21 18:45
Competitive Analysis: The Key to a Woman's Healthy Heart - Part 1 brandt Tue, 03/21/2017 - 13:45 Michelle Jackson Mar 21, 2017Photo of woman holding up paper cutout of heart over face

In the healthcare field, meeting the needs of patients can be a matter of life and death.

In this post we will cover...
  • How health systems can conduct competitive analysis

  • How navigation organization and prioritization impacts the ability of people to find information on specific health topics such as heart disease and its impact on women’s health

  • How competitive analysis can help health systems conduct a cursory evaluation and improve information architecture to better serve people suffering from critical illnesses

  • How looking at peer competitors can help health systems better serve the needs of patients and their caregivers

Strategy work is essential to a project's success.

Let's Chat.

Competitive analysis is an exercise, the importance of which transcends the borders of many industries, including healthcare. By taking a look at how your site compares to your competitors, you can ultimately make changes that allow you to better serve your patient’s specific needs.

In recognition of Women’s History Month, we are focusing on women’s health, specifically heart disease, the number one cause of death for women in the United States. We are also honing in on on DrupalCon-host city Baltimore, which has launched several initiatives to combat cardiovascular disease. The goal is to take a look at how two health systems in Charm City categorize and present information about cardiovascular disease on their public-facing websites.

Let’s imagine you have been tasked by the American Heart Association (AHA) to compare and evaluate websites of local health systems in the field of cardiology in how they serve women patients who suffer from cardiovascular disease. Where do we begin? What competitors will we look at? What dimensions or features/site attributes are we comparing? What key tasks are important to patients and caregivers? How does search impact the site visitor journey to each competitor website.

By the time you finish reading this post, you will have the know-how to do a competitive analysis for a health-system or hospital website with a focus on particular health specialties and demographics. You will be able to see how your website measures against the competition at the specialty level and also in meeting the needs of specific patient and caregiver audiences.

What is competitive analysis?

As we discussed in Competitive Analysis on a Budget, competitive analysis is a user experience research technique that can help you see how your site compares with competitor websites in terms of content, design, and functionality. It can also lead to better decision-making when selecting new design and technical features for your site (e.g. search filter terms or search listing display). In this post, we’ll focus on the navigation and internal menu labels as our dimensions.

A Tale of Two Hospitals

Johns Hopkins Medicine and the University of Maryland Medical Center are two large university hospitals local to Baltimore that have centers dedicated to women and heart disease. The two centers are considered direct competitors because both offer the same service and function in the same way.

Fast Facts for Context
  • Women’s heart disease symptoms are complex and often differ from mens’ symptoms. 
  • Women suffering from heart disease may not experience any symptoms at all.
  • In 2015, the Baltimore City Health Department released a report that cited cardiovascular disease as the leading cause of death in the city.
  • According to the 2015 Maryland Vital Statistics Annual Report, approximately 1 in 4 deaths in the Baltimore Metro Area were related to heart disease.
  • National and statewide statistics confirm cardiovascular disease is the leading cause of death for men and women.
It all begins with search

Search plays a key role in how patients and caregivers, especially women, find information about health conditions and treatment. In 2013, Pew Research’s Health Online Report noted that “women [were] more likely than men to go online to figure out a possible diagnosis.” The report also noted that “77% of online health seekers say they began at a search engine such as Google, Bing, or Yahoo.”

Specific search queries will likely bring this group of site visitors to a specific page, rather than to the homepage. This means the information architecture of health system internal pages plays a key role in providing patients and caregivers with information and resources about medical conditions and services. Competitive analysis can help us understand if and how these pages are meeting patient and caregiver needs.

Keywords are key

Keyword selection drastically impacts the results that are returned during a patient and caregiver search query. To demonstrate this, let’s start with a basic keyword search to evaluate how sites are optimizing search for topics like women and heart disease. As shown below, keywords can transform the information-seeking experience for women.

 Google search with “women heart disease baltimore md” as key wordsFigure 1: Google search with “women heart disease baltimore md” as key words

The first figure shows the search query results for “women heart disease baltimore md.” Johns Hopkins Women’s Cardiovascular Health Center and University of Maryland Medical Center Women’s Heart Program landing pages are both listed in the search results (Figures 2 and 3).

 Johns Hopkins Women’s Cardiovascular Health Center landing pageFigure 2: Johns Hopkins Women’s Cardiovascular Health Center landing page

 

 University of Maryland Medical Center Women’s Heart Health Program landing pageFigure 3: University of Maryland Medical Center Women’s Heart Health Program landing page

 

 Google search with “heart disease hospital baltimore md” Figure 4: Google search with “heart disease hospital baltimore md”

Search significantly impacts patient and caregiver access to health and hospital information. Google provides results based on previous search behavior, so results may vary by browser and search history, among other factors. We tried these terms using a private session and when logged into Google and saw little to no variance.

As shown in Figure 4, using different keywords in the search query yields different search results. “Heart disease hospital baltimore md” returns Johns Hopkins Heart & Vascular Institute as one of the top search results, but University of Maryland Medical Center’s Heart and Vascular Center is not returned as a top result when logged into Google Chrome on during a private session.

This is important to note because the University of Maryland Medical Center may want to look into methods to improve search engine optimization. There are different ways to address the absence of your website or landing page, product or service at the top of the site visitor’s search results listing.

Menu hierarchy and landing pages - when alphabetization complicates user experience

If women with heart disease choose keywords like “heart disease hospital baltimore md,” and do not indicate their gender in their query, they are brought to Heart & Vascular Health landing pages for each respective health system. Both landing pages use alphabetization to organization centers and programs, Because the centers or programs dedicated to women and heart disease begin with “W,” they are situated at the bottom of the internal navigations.

This may pose a challenge to patients and caregivers entering the site from search queries that omit the word “women” (i.e. heart disease hospital baltimore md). These search query examples are not meant to represent the most common queries for people looking for information about heart disease in Baltimore; rather they demonstrate how different search queries can yield different results for people seeking this information.

 Johns Hopkins Heart & Vascular Institute landing pageFigure 5: Johns Hopkins Heart & Vascular Institute landing page

 

 University of Maryland Medical Center Heart and Vascular CenterFigure 6: University of Maryland Medical Center Heart and Vascular CenterInternal Menu Labeling and Nesting

Now that we see how search impacts visitor pathways to the health system sites, let’s take a closer look at how Johns Hopkins Medicine and the University of Maryland Medical Center, differ in presenting information in the internal menus for the centers and programs dedicated to women’s heart disease and heart health.

 Johns Hopkins Heart & Vascular Institute landing page navigationFigure 7: Johns Hopkins Heart & Vascular Institute landing page navigation

Multiple internal navigations within the Johns Hopkins Heart & Vascular Institute landing page and the current placement of the Women’s Cardiovascular Health Center at the bottom of the navigation hierarchy might make it challenging for patients looking for this particular center. Since centers provide services for patients, the placement of “centers of excellence” under “clinical services” may complicate site visitors’ understanding of resources and the relationship between services and centers. These types of naming conventions should be examined more closely.

 Johns Hopkins Heart & Vascular Institute landing page internal navigationsFigure 8: Johns Hopkins Heart & Vascular Institute landing page internal navigations

 

 University of Maryland Medical Center Women’s Heart Health Program landing page navigationsFigure 9: University of Maryland Medical Center Women’s Heart Health Program landing page navigations

Like its competitor, the University of Maryland Medical Center has multiple internal navigations, which may also be cumbersome to users. Patients and caregivers have too many options which may make it difficult for them to understand what they should do on this page. It may also make it challenging for them to complete key tasks (i.e. researching risk factors, find a physician, schedule an appointment, etc).

The University of Maryland Medical Center’s “Centers and Services might resonate better with site visitors because they can find both Centers and Services under “Centers and Services;” Johns Hopkins Medicine’s placement of Centers of Excellence under Clinical Services could be confusing. Patients typically go to a center to receive clinical services; they don’t often go to a clinical service to find a center.

The University of Maryland Medical Center’s Heart & Vascular Center use of “Services’” for one of its navigations might not be intuitive to site visitors. “Services” plays the role of a catch-all for conditions (i.e. aortic disease), topics (i.e. women’s heart health) and treatment options (i.e. heart and lung transplant) and may make it challenging for visitors to find what they are looking for on this page.

More specifically, a patient or caregiver looking for women’s heart health may not necessarily expect to find a program under “Services.” These items could be surfaced more quickly and more efficiently organized within Centers and Services so that the pathways to Women’s Heart Health are more intuitive to patients and their caregivers.

We’ll know if this is the case after we test these health system site pages with real visitors.

 Competitive analysis matrixFigure 10: Competitive analysis matrixIn sum

So how do you design a website for women who may have asymptomatic heart disease? How do you integrate the needs of potential patients who experience neck and back pain as a symptom of their heart disease? We can gain a better understanding of specific cases like this by understanding the user journey of patients who exhibit non-traditional symptoms of heart disease and their caregivers by conducting competitive usability tests of these sites.

So what next?

Now that we’ve provided a cursory analysis and heuristic evaluation of the internal navigations of two health system sites, we’ll perform user tests on the websites to validate the some of the hypotheses we discuss in this blog post and compare the content and design of the two health system sites. Keep an eye out for that post in a couple weeks!

We want to make your project a success.

Let's Chat.

Palantir: Competitive Analysis: The Key to a Woman's Healthy Heart - Part 1

Feeds from Drupal.org - Tue, 2017-03-21 18:45
Competitive Analysis: The Key to a Woman's Healthy Heart - Part 1 brandt Tue, 03/21/2017 - 13:45 Michelle Jackson Mar 21, 2017Photo of woman holding up paper cutout of heart over face

In the healthcare field, meeting the needs of patients can be a matter of life and death.

In this post we will cover...
  • How health systems can conduct competitive analysis

  • How navigation organization and prioritization impacts the ability of people to find information on specific health topics such as heart disease and its impact on women’s health

  • How competitive analysis can help health systems conduct a cursory evaluation and improve information architecture to better serve people suffering from critical illnesses

  • How looking at peer competitors can help health systems better serve the needs of patients and their caregivers

Strategy work is essential to a project's success.

Let's Chat.

Competitive analysis is an exercise, the importance of which transcends the borders of many industries, including healthcare. By taking a look at how your site compares to your competitors, you can ultimately make changes that allow you to better serve your patient’s specific needs.

In recognition of Women’s History Month, we are focusing on women’s health, specifically heart disease, the number one cause of death for women in the United States. We are also honing in on on DrupalCon-host city Baltimore, which has launched several initiatives to combat cardiovascular disease. The goal is to take a look at how two health systems in Charm City categorize and present information about cardiovascular disease on their public-facing websites.

Let’s imagine you have been tasked by the American Heart Association (AHA) to compare and evaluate websites of local health systems in the field of cardiology in how they serve women patients who suffer from cardiovascular disease. Where do we begin? What competitors will we look at? What dimensions or features/site attributes are we comparing? What key tasks are important to patients and caregivers? How does search impact the site visitor journey to each competitor website.

By the time you finish reading this post, you will have the know-how to do a competitive analysis for a health-system or hospital website with a focus on particular health specialties and demographics. You will be able to see how your website measures against the competition at the specialty level and also in meeting the needs of specific patient and caregiver audiences.

What is competitive analysis?

As we discussed in Competitive Analysis on a Budget, competitive analysis is a user experience research technique that can help you see how your site compares with competitor websites in terms of content, design, and functionality. It can also lead to better decision-making when selecting new design and technical features for your site (e.g. search filter terms or search listing display). In this post, we’ll focus on the navigation and internal menu labels as our dimensions.

A Tale of Two Hospitals

Johns Hopkins Medicine and the University of Maryland Medical Center are two large university hospitals local to Baltimore that have centers dedicated to women and heart disease. The two centers are considered direct competitors because both offer the same service and function in the same way.

Fast Facts for Context
  • Women’s heart disease symptoms are complex and often differ from mens’ symptoms. 
  • Women suffering from heart disease may not experience any symptoms at all.
  • In 2015, the Baltimore City Health Department released a report that cited cardiovascular disease as the leading cause of death in the city.
  • According to the 2015 Maryland Vital Statistics Annual Report, approximately 1 in 4 deaths in the Baltimore Metro Area were related to heart disease.
  • National and statewide statistics confirm cardiovascular disease is the leading cause of death for men and women.
It all begins with search

Search plays a key role in how patients and caregivers, especially women, find information about health conditions and treatment. In 2013, Pew Research’s Health Online Report noted that “women [were] more likely than men to go online to figure out a possible diagnosis.” The report also noted that “77% of online health seekers say they began at a search engine such as Google, Bing, or Yahoo.”

Specific search queries will likely bring this group of site visitors to a specific page, rather than to the homepage. This means the information architecture of health system internal pages plays a key role in providing patients and caregivers with information and resources about medical conditions and services. Competitive analysis can help us understand if and how these pages are meeting patient and caregiver needs.

Keywords are key

Keyword selection drastically impacts the results that are returned during a patient and caregiver search query. To demonstrate this, let’s start with a basic keyword search to evaluate how sites are optimizing search for topics like women and heart disease. As shown below, keywords can transform the information-seeking experience for women.

 Google search with “women heart disease baltimore md” as key wordsFigure 1: Google search with “women heart disease baltimore md” as key words

The first figure shows the search query results for “women heart disease baltimore md.” Johns Hopkins Women’s Cardiovascular Health Center and University of Maryland Medical Center Women’s Heart Program landing pages are both listed in the search results (Figures 2 and 3).

 Johns Hopkins Women’s Cardiovascular Health Center landing pageFigure 2: Johns Hopkins Women’s Cardiovascular Health Center landing page

 

 University of Maryland Medical Center Women’s Heart Health Program landing pageFigure 3: University of Maryland Medical Center Women’s Heart Health Program landing page

 

 Google search with “heart disease hospital baltimore md” Figure 4: Google search with “heart disease hospital baltimore md”

Search significantly impacts patient and caregiver access to health and hospital information. Google provides results based on previous search behavior, so results may vary by browser and search history, among other factors. We tried these terms using a private session and when logged into Google and saw little to no variance.

As shown in Figure 4, using different keywords in the search query yields different search results. “Heart disease hospital baltimore md” returns Johns Hopkins Heart & Vascular Institute as one of the top search results, but University of Maryland Medical Center’s Heart and Vascular Center is not returned as a top result when logged into Google Chrome on during a private session.

This is important to note because the University of Maryland Medical Center may want to look into methods to improve search engine optimization. There are different ways to address the absence of your website or landing page, product or service at the top of the site visitor’s search results listing.

Menu hierarchy and landing pages - when alphabetization complicates user experience

If women with heart disease choose keywords like “heart disease hospital baltimore md,” and do not indicate their gender in their query, they are brought to Heart & Vascular Health landing pages for each respective health system. Both landing pages use alphabetization to organization centers and programs, Because the centers or programs dedicated to women and heart disease begin with “W,” they are situated at the bottom of the internal navigations.

This may pose a challenge to patients and caregivers entering the site from search queries that omit the word “women” (i.e. heart disease hospital baltimore md). These search query examples are not meant to represent the most common queries for people looking for information about heart disease in Baltimore; rather they demonstrate how different search queries can yield different results for people seeking this information.

 Johns Hopkins Heart & Vascular Institute landing pageFigure 5: Johns Hopkins Heart & Vascular Institute landing page

 

 University of Maryland Medical Center Heart and Vascular CenterFigure 6: University of Maryland Medical Center Heart and Vascular CenterInternal Menu Labeling and Nesting

Now that we see how search impacts visitor pathways to the health system sites, let’s take a closer look at how Johns Hopkins Medicine and the University of Maryland Medical Center, differ in presenting information in the internal menus for the centers and programs dedicated to women’s heart disease and heart health.

 Johns Hopkins Heart & Vascular Institute landing page navigationFigure 7: Johns Hopkins Heart & Vascular Institute landing page navigation

Multiple internal navigations within the Johns Hopkins Heart & Vascular Institute landing page and the current placement of the Women’s Cardiovascular Health Center at the bottom of the navigation hierarchy might make it challenging for patients looking for this particular center. Since centers provide services for patients, the placement of “centers of excellence” under “clinical services” may complicate site visitors’ understanding of resources and the relationship between services and centers. These types of naming conventions should be examined more closely.

 Johns Hopkins Heart & Vascular Institute landing page internal navigationsFigure 8: Johns Hopkins Heart & Vascular Institute landing page internal navigations

 

 University of Maryland Medical Center Women’s Heart Health Program landing page navigationsFigure 9: University of Maryland Medical Center Women’s Heart Health Program landing page navigations

Like its competitor, the University of Maryland Medical Center has multiple internal navigations, which may also be cumbersome to users. Patients and caregivers have too many options which may make it difficult for them to understand what they should do on this page. It may also make it challenging for them to complete key tasks (i.e. researching risk factors, find a physician, schedule an appointment, etc).

The University of Maryland Medical Center’s “Centers and Services might resonate better with site visitors because they can find both Centers and Services under “Centers and Services;” Johns Hopkins Medicine’s placement of Centers of Excellence under Clinical Services could be confusing. Patients typically go to a center to receive clinical services; they don’t often go to a clinical service to find a center.

The University of Maryland Medical Center’s Heart & Vascular Center use of “Services’” for one of its navigations might not be intuitive to site visitors. “Services” plays the role of a catch-all for conditions (i.e. aortic disease), topics (i.e. women’s heart health) and treatment options (i.e. heart and lung transplant) and may make it challenging for visitors to find what they are looking for on this page.

More specifically, a patient or caregiver looking for women’s heart health may not necessarily expect to find a program under “Services.” These items could be surfaced more quickly and more efficiently organized within Centers and Services so that the pathways to Women’s Heart Health are more intuitive to patients and their caregivers.

We’ll know if this is the case after we test these health system site pages with real visitors.

 Competitive analysis matrixFigure 10: Competitive analysis matrixIn sum

So how do you design a website for women who may have asymptomatic heart disease? How do you integrate the needs of potential patients who experience neck and back pain as a symptom of their heart disease? We can gain a better understanding of specific cases like this by understanding the user journey of patients who exhibit non-traditional symptoms of heart disease and their caregivers by conducting competitive usability tests of these sites.

So what next?

Now that we’ve provided a cursory analysis and heuristic evaluation of the internal navigations of two health system sites, we’ll perform user tests on the websites to validate the some of the hypotheses we discuss in this blog post and compare the content and design of the two health system sites. Keep an eye out for that post in a couple weeks!

We want to make your project a success.

Let's Chat.
Categories: Straight From Drupal

Noopener Filter

Latest Drupal Modules - Tue, 2017-03-21 16:46

This project adds a filter that enables it to add rel="noopener" to all WYSIWYG added links.
This is done in order to prevent window.opener from being exploited.
For more information on this subject check out: https://mathiasbynens.github.io/rel-noopener/

Categories: Straight From Drupal

Code Enigma: Do you really need composer in production?

Planet Drupal - Tue, 2017-03-21 16:26
Do you really need composer in production? Language English Return to Blog Do you really need composer in production?

It is now a common practice to use composer as part of the deployment stack. Is this always such a good idea?

Photo of Pascal MorinTue, 2017-03-21 16:26By pascal

The recipe goes like this : gitignore your "vendor" directory (or whatever folder your dependencies end up in), but commit your composer.lock file, then deploy. Your CI job will then « composer install » all the dependencies where there belong to, magically reproducing your initial files layout exactly how they were.

There are generally a few additional steps involved in between though. Typically, you lost half a day figuring out the right file permissions so that the var/cache of your app can be cleared and recreated properly by the webserver user, wondered for days why some of the builds were randomly failing before realizing that no token was set in this given job, meaning github API rate limit was sometime hit. Then another good day or two finding out how to apply two patches for the same projects when they slightly conflict. And your sysadmin might be slightly suspicious about those files being downloaded and executed directly on production outside of any VCS, and anxiously watching for exploit reports.

Now, you will assure me, you’ve nailed all that, and, apart from an occasional network glitch preventing packages to be fetched, all is running smoothly. Great.

But please, re-read above. Why are you doing all this? To "reproduce your initial files layout exactly how they were". Then why don’t you just commit the files and push them, then?

That is normally the point in the discussion when you’re supposed to use the words « reproducible » and « best practices ».

Reproducible

*/

Right, but what is more reproducible than moving prebuilt files around? You played the recipe once already on your dev environment, taking the risk of re-running it on production feels a bit like recompiling binaries from source simply because you can.

Composer is not magic. What it does is grab a bunch of PHP files, ensuring they are at the right version and that they end up in the right place, so they can play nicely together. Once you have the resulting file set already, why would you want to redo this over and over on each and every environment?

Best practices

Let’s have a closer looks at what is stated in the Composer documentation and the reasons why the project recommends not committing your dependencies:

  • large VCS repository size and diffs when you update code;
  • duplication of the history of all your dependencies in your own VCS; and
  • adding dependencies installed via git to a git repo will show them as submodules.

I’ll just ignore the repository size (because, frankly ?) and focus on the diff and history parts.

For one, the argument here is slightly misleading: reading the statement, you might be under the impression your repository will contain the whole git history of each and every dependency in your project. Nope, it will not. What you will end up with, along the life of your project, is the history of updates to your dependencies after your initial commit.

Which is rather the most important point here. This is a good thing! Why would not you want to be able to look at - and keep track of in your VCS - what was in update from Guzzle 3.8.0 to 3.8.1 or what difference there is between ctools 8.x-3.0-alpha27 and alpha26? Your « live » project is not only your custom code.

What would you find most useful, next time your client opens a ticket because the image embedding in the WYSIWYG editor has stopped working since the last release, when looking back at the commit « Upgrade contrib module media_entity from 8.x-1.5 to 8.x-1.6 » ? Seeing a one line hash change in composer.lock, or seeing a nice diff of the actual changes in code, so you can track down what went wrong?

The .git submodules point is fair, but easy to workaround, as explained on this very same best practices page. Also keep in mind it only applies if you use dev versions or obscure non-packaged dependencies.

*/

 

So, to sum it up, if you use Composer to build your code in production, you get:

   - Un-needed and time consuming deployment complexity increase, with small but real risks of failure on each and every build for external cause

   - No auditing of changes that are not your own custom code

   + Easier handling of .git « false » submodules for a few dev dependencies

 

On the other hand, if you commit the "vendor" directory, you get:

   + Easier and straightforward deployment

   + All code that lands on production gets audited/versioned

   - Small amount of work involved in dealing with possible .git « false » submodules

 

 

Then why ?

*/

But then, why is that such a widespread practice? I can only guess here, but I suspect there are several factors at play:

  • Fashion, to some extent, must play a role. There are very good reasons to do this for certain workflows, which may lead people to think that it can apply to any deployment workflow.
  • The fact that it is presented as « best practice » on the Composer project page. Many people apply it without questioning whether it is applicable to their use case.

My interpretation is that, more fundamentally, the root cause is confusion between "deploying" code and "distributing" code.

Moving a « living thing » for one environment over to another environment is not the same process as making a component or app available for other projects to reuse and build upon. Composer is a fantastic building tool, it is great for the latter case, and using it to assemble your project totally makes sense. Using it as a deployment tool, less so.

If we take another look at the arguments above from a distribution perspective, the analysis is totally different:

  • Large VCS repository size and diffs when you update code.
  • Duplication of the history of all your dependencies in your own VCS.

Indeed, in this use case, it all makes total sense: you definitively do not need the whole git history of any component you are re-using for your project. Nor do you want your repo for the nice web-crawler library you contribute on GitHub to contain the Guzzle codebase you depend upon.

In short, think about the usage. If you maintain, say, a Drupal custom distro that you use internally as a starting point for your projects, by all means yes, ignore the vendor directory. Build it with Composer when you use it to start a new project. And continue to use Composer to manage dependencies updates in your dev environment. However, once this is no longer a re-usable component, but instead a living project that will need to be deployed from environment to environment, do yourself a favour and consider carefully whether using Composer to deploy really brings any benefit.

 

 

 

BlogIntegrating Drupal with Microsoft SharePoint 2013 BlogIntroducing Blackfire on Code Enigma servers BlogThe Entity Reference Autocomplete module BlogSAML ADFS authentication in Drupal

Code Enigma: Do you really need composer in production?

Feeds from Drupal.org - Tue, 2017-03-21 16:26
Do you really need composer in production? Language English Return to Blog Do you really need composer in production?

It is now a common practice to use composer as part of the deployment stack. Is this always such a good idea?

Photo of Pascal MorinTue, 2017-03-21 16:26By pascal

The recipe goes like this : gitignore your "vendor" directory (or whatever folder your dependencies end up in), but commit your composer.lock file, then deploy. Your CI job will then « composer install » all the dependencies where there belong to, magically reproducing your initial files layout exactly how they were.

There are generally a few additional steps involved in between though. Typically, you lost half a day figuring out the right file permissions so that the var/cache of your app can be cleared and recreated properly by the webserver user, wondered for days why some of the builds were randomly failing before realizing that no token was set in this given job, meaning github API rate limit was sometime hit. Then another good day or two finding out how to apply two patches for the same projects when they slightly conflict. And your sysadmin might be slightly suspicious about those files being downloaded and executed directly on production outside of any VCS, and anxiously watching for exploit reports.

Now, you will assure me, you’ve nailed all that, and, apart from an occasional network glitch preventing packages to be fetched, all is running smoothly. Great.

But please, re-read above. Why are you doing all this? To "reproduce your initial files layout exactly how they were". Then why don’t you just commit the files and push them, then?

That is normally the point in the discussion when you’re supposed to use the words « reproducible » and « best practices ».

Reproducible

*/

Right, but what is more reproducible than moving prebuilt files around? You played the recipe once already on your dev environment, taking the risk of re-running it on production feels a bit like recompiling binaries from source simply because you can.

Composer is not magic. What it does is grab a bunch of PHP files, ensuring they are at the right version and that they end up in the right place, so they can play nicely together. Once you have the resulting file set already, why would you want to redo this over and over on each and every environment?

Best practices

Let’s have a closer looks at what is stated in the Composer documentation and the reasons why the project recommends not committing your dependencies:

  • large VCS repository size and diffs when you update code;
  • duplication of the history of all your dependencies in your own VCS; and
  • adding dependencies installed via git to a git repo will show them as submodules.

I’ll just ignore the repository size (because, frankly ?) and focus on the diff and history parts.

For one, the argument here is slightly misleading: reading the statement, you might be under the impression your repository will contain the whole git history of each and every dependency in your project. Nope, it will not. What you will end up with, along the life of your project, is the history of updates to your dependencies after your initial commit.

Which is rather the most important point here. This is a good thing! Why would not you want to be able to look at - and keep track of in your VCS - what was in update from Guzzle 3.8.0 to 3.8.1 or what difference there is between ctools 8.x-3.0-alpha27 and alpha26? Your « live » project is not only your custom code.

What would you find most useful, next time your client opens a ticket because the image embedding in the WYSIWYG editor has stopped working since the last release, when looking back at the commit « Upgrade contrib module media_entity from 8.x-1.5 to 8.x-1.6 » ? Seeing a one line hash change in composer.lock, or seeing a nice diff of the actual changes in code, so you can track down what went wrong?

The .git submodules point is fair, but easy to workaround, as explained on this very same best practices page. Also keep in mind it only applies if you use dev versions or obscure non-packaged dependencies.

*/

 

So, to sum it up, if you use Composer to build your code in production, you get:

   - Un-needed and time consuming deployment complexity increase, with small but real risks of failure on each and every build for external cause

   - No auditing of changes that are not your own custom code

   + Easier handling of .git « false » submodules for a few dev dependencies

 

On the other hand, if you commit the "vendor" directory, you get:

   + Easier and straightforward deployment

   + All code that lands on production gets audited/versioned

   - Small amount of work involved in dealing with possible .git « false » submodules

 

 

Then why ?

*/

But then, why is that such a widespread practice? I can only guess here, but I suspect there are several factors at play:

  • Fashion, to some extent, must play a role. There are very good reasons to do this for certain workflows, which may lead people to think that it can apply to any deployment workflow.
  • The fact that it is presented as « best practice » on the Composer project page. Many people apply it without questioning whether it is applicable to their use case.

My interpretation is that, more fundamentally, the root cause is confusion between "deploying" code and "distributing" code.

Moving a « living thing » for one environment over to another environment is not the same process as making a component or app available for other projects to reuse and build upon. Composer is a fantastic building tool, it is great for the latter case, and using it to assemble your project totally makes sense. Using it as a deployment tool, less so.

If we take another look at the arguments above from a distribution perspective, the analysis is totally different:

  • Large VCS repository size and diffs when you update code.
  • Duplication of the history of all your dependencies in your own VCS.

Indeed, in this use case, it all makes total sense: you definitively do not need the whole git history of any component you are re-using for your project. Nor do you want your repo for the nice web-crawler library you contribute on GitHub to contain the Guzzle codebase you depend upon.

In short, think about the usage. If you maintain, say, a Drupal custom distro that you use internally as a starting point for your projects, by all means yes, ignore the vendor directory. Build it with Composer when you use it to start a new project. And continue to use Composer to manage dependencies updates in your dev environment. However, once this is no longer a re-usable component, but instead a living project that will need to be deployed from environment to environment, do yourself a favour and consider carefully whether using Composer to deploy really brings any benefit.

 

 

 

BlogIntegrating Drupal with Microsoft SharePoint 2013 BlogIntroducing Blackfire on Code Enigma servers BlogThe Entity Reference Autocomplete module BlogSAML ADFS authentication in Drupal
Categories: Straight From Drupal

myDropWizard.com: Most common Drupal site building pitfalls and how to avoid them! (Part 2 of 3)

Planet Drupal - Tue, 2017-03-21 16:24

This is the second in a series of articles, in which I'd like to share the most common pitfalls we've seen, so that you can avoid making the same mistakes when building your sites!

myDropWizard offers support and maintenance for Drupal sites that we didn't build initially. We've learned the hard way which site building mistakes have the greatest potential for creating issues later.

And we've seen a lot of sites! Besides our clients, we also do a FREE in-depth site audit as the first step when talking to a potential client, so we've seen loads of additional sites that didn't become customers.

In the last article, we looked at security updates, badly installed module code and issues with patching modules, as well as specific strategies for addressing each of those problems. In this article, we'll look at how to do the most common Drupal customizations without patching!

NOTE: even though they might take a slightly different form depending on the version, most of these same pitfalls apply equally to Drupal 6, 7 and 8! It turns out that bad practices are quite compatible with multiple Drupal versions ;-)

myDropWizard.com: Most common Drupal site building pitfalls and how to avoid them! (Part 2 of 3)

Feeds from Drupal.org - Tue, 2017-03-21 16:24

This is the second in a series of articles, in which I'd like to share the most common pitfalls we've seen, so that you can avoid making the same mistakes when building your sites!

myDropWizard offers support and maintenance for Drupal sites that we didn't build initially. We've learned the hard way which site building mistakes have the greatest potential for creating issues later.

And we've seen a lot of sites! Besides our clients, we also do a FREE in-depth site audit as the first step when talking to a potential client, so we've seen loads of additional sites that didn't become customers.

In the last article, we looked at security updates, badly installed module code and issues with patching modules, as well as specific strategies for addressing each of those problems. In this article, we'll look at how to do the most common Drupal customizations without patching!

NOTE: even though they might take a slightly different form depending on the version, most of these same pitfalls apply equally to Drupal 6, 7 and 8! It turns out that bad practices are quite compatible with multiple Drupal versions ;-)

Categories: Straight From Drupal

AJAX assets plus

Latest Drupal Modules - Tue, 2017-03-21 15:39

WIP.

Categories: Straight From Drupal

netForum Single Sign On

Latest Drupal Modules - Tue, 2017-03-21 14:22

netFORUM Single Sign on. Allows users to sign in to Drupal using Avectra netFORUM credentials.

This module allows for Single Sign On between netFORUM and Drupal site. Users can sign in to Drupal site using their netFORUM credentials.

We have additional modules available that compliment this SSO module. Listed below

Security Groups - Allows you to restrict content on your Drupal CMS site, based on the users Membership status in netFORUM.

Categories: Straight From Drupal

InternetDevels: Great responsive Drupal themes for construction websites: built for builders!

Planet Drupal - Tue, 2017-03-21 14:12
 built for builders!

We once offered you a selection of free responsive Drupal themes,
as well as advanced tutorials on creating themes and subthemes.
Today, our focus will be very specific: we will discuss

Read more

InternetDevels: Great responsive Drupal themes for construction websites: built for builders!

Feeds from Drupal.org - Tue, 2017-03-21 14:12
 built for builders!

We once offered you a selection of free responsive Drupal themes,
as well as advanced tutorials on creating themes and subthemes.
Today, our focus will be very specific: we will discuss

Read more
Categories: Straight From Drupal

InternetDevels: Great responsive Drupal themes for construction websites: built for builders!

Planet Drupal - Tue, 2017-03-21 14:12
 built for builders!

We once offered you a selection of free responsive Drupal themes,
as well as advanced tutorials on creating themes and subthemes.
Today, our focus will be very specific: we will discuss

Read more

InternetDevels: Great responsive Drupal themes for construction websites: built for builders!

Feeds from Drupal.org - Tue, 2017-03-21 14:12
 built for builders!

We once offered you a selection of free responsive Drupal themes,
as well as advanced tutorials on creating themes and subthemes.
Today, our focus will be very specific: we will discuss

Read more
Categories: Straight From Drupal

Content translation workflow

Latest Drupal Modules - Tue, 2017-03-21 13:49

Let's assume you have enabled workbench_moderation + multilingual content. Now you've some published content in multiple languages.

Without this module you are not able to create published versions in just one language, without unpublishing the others.

Please use it with caution

Categories: Straight From Drupal

Acquia Developer Center Blog: Cultivating Open Source and Drupal in China

Planet Drupal - Tue, 2017-03-21 13:18
china map

Following on from my previous blog posts around how Drupal and open-source are growing in China, we must start looking at how the overall ecosystem can be nurtured to turn one of the most populous countries in the world on to Drupal.

Tags: acquia drupal planet

Acquia Developer Center Blog: Cultivating Open Source and Drupal in China

Feeds from Drupal.org - Tue, 2017-03-21 13:18
china map

Following on from my previous blog posts around how Drupal and open-source are growing in China, we must start looking at how the overall ecosystem can be nurtured to turn one of the most populous countries in the world on to Drupal.

Tags: acquia drupal planet
Categories: Straight From Drupal

Agiledrop.com Blog: AGILEDROP: Drupal Logos representing National Identities

Planet Drupal - Tue, 2017-03-21 10:23
We are now very deep into our »Druplicon marathon«. After already presenting you Drupal Logos in Human and Superhuman forms, Drupal Logos as Fruits and Vegetables, Druplicons in the shapes of Animals and Drupal Logos taking part in the outdoor activities, it's now time to look at Drupal Logos representing the national identities. A sense of belonging to one nation can be very strong. National identities are therefore also present in various Druplicons. Latter mostly represent active or inactive Drupal Groups from the specific countries. These groups connect Drupalistas from that specific… READ MORE

Pages

Subscribe to My Drupal aggregator