Web APIs are not just useful when making headless sites in Drupal: large Drupal sites often hold valuable information that could also be useful outside the site's context. Media companies might want to expose historical media content, community sites could show data about their community activities, e-commerce sites tend to open an API for their affiliates and partners.
While it is possible to use Drupal 7 and Drupal 8 as an API backend, a lot of functionalities that describe a mature API service do not come out of the box. In this post we will explain what key concepts you have to keep in mind when designing an API service, why they are important and how APIgee Edge can make it easier to build a full-featured API webservice in Drupal successfully.
Dependency Injection in Drupal 8 Plugins can trip you up if you focus on the Dependency Injection part and forget about the Plugin part. This blog post shows key differences to keep in mind when you're working with D8 Plugins.
Time for a little confession. I didn't intend to showcase DrupalVM as a DIY Drupal hosting solution when I conceived this series idea. Jeff Geerling, DrupalVM's creator hinted at using DrupalVM as a viable solution for small to medium sites in the first post of the series. It was an idea worth exploring and the result is this post.
I have had many differences with the Drupal Association in the past, starting with the many clashes we had with their erstwhile leadership when we were organising DrupalCon Copenhagen 2010, so I’ll admit I wasn’t their biggest fan before the latest events.mikl Thu, 2017-03-23 - 07:42 Tags Drupal Planet Drupal
The Drupal community is committed to welcome and accept all people. That includes a commitment to not discriminate against anyone based on their heritage or culture, their sexual orientation, their gender identity, and more. Being diverse has strength and as such we work hard to foster a culture of open-mindedness toward differences.
A few weeks ago, I privately asked Larry Garfield, a prominent Drupal contributor, to leave the Drupal project. I did this because it came to my attention that he holds views that are in opposition with the values of the Drupal project.
I had hoped to avoid discussing this decision publicly out of respect for Larry's private life, but now that Larry has written about it on his blog and it is being discussed publicly, I believe I have no choice but to respond on behalf of the Drupal project.
It is not for me to share any of the confidential information that I've received, so I won't point out the omissions in Larry's blog post. However, I can tell you that those who have reviewed Larry's writing, including me, suffered from varying degrees of shock and concern.
In the end, I fundamentally believe that all people are created equally. This belief has shaped the values that the Drupal project has held since it's early days. I cannot in good faith support someone who actively promotes a philosophy that is contrary to this.
While the decision was unpleasant, the choice was clear. I remain steadfast in my obligation to protect the shared values of the Drupal project. This is unpleasant because I appreciate Larry's many contributions to Drupal, because this risks setting a complicated precedent, and because it involves a friend's personal life. The matter is further complicated by the fact that this information was shared by others in a manner I don't find acceptable either.
It's not for me to judge the choices anyone makes in their private life or what beliefs they subscribe to. I certainly don't take offense to the role-playing activities of Larry's alternative lifestyle. However, when a highly-visible community member's private views become public, controversial, and disruptive for the project, I must consider the impact that his words and actions have on others and the project itself. In this case, Larry has entwined his private and professional online identities in such a way that it blurs the lines with the Drupal project. Ultimately, I can't get past the fundamental misalignment of values.
First, collectively, we work hard to ensure that Drupal has a culture of diversity and inclusion. Our goal is not just to have a variety of different people within our community, but to foster an environment of connection, participation and respect. We have a lot of work to do on this and we can't afford to ignore discrepancies between the espoused views of those in leadership roles and the values of our culture. It's my opinion that any association with Larry's belief system is inconsistent with our project's goals.
Second, I believe someone's belief system inherently influences their actions, in both explicit and subtle ways, and I'm unwilling to take this risk going forward.
Third, Larry's continued representation of the Drupal project could harm the reputation of the project and cause harm to the Drupal ecosystem. Any further participation in a leadership role implies our community is complicit with and/or endorses these views, which we do not.
It is my responsibility and obligation to act in the best interest of the project at large and to uphold our values. Decisions like this are unpleasant and disruptive, but important. It is moments like this that test our commitment to our values. We must stand up and act in ways that demonstrate these values. For these reasons, I'm asking Larry to resign from the Drupal project.
(Comments on this post are allowed but for obvious reasons will be moderated.)
We recently had the opportunity to work on a Symfony app for one of our Higher Ed clients that we recently built a Drupal distribution for. Drupal 8 moving to Symfony has enabled us to expand our service offering. We have found more opportunities building apps directly using Symfony when a CMS is not needed. This post is not about Drupal, but cross posting to Drupal Planet to demonstrate the value of getting off the island. Writing custom authentication schemes in Symfony used to be on the complicated side. But with the introduction of the Guard authentication component, it has gotten a lot easier.Read more...
Windows 10 is the only release Acquia's BLT officially supports. But there are still many people who use Windows 7 and 8, and most of these people don't have control over what version of Windows they use.
Drupal VM has supported Windows 7, 8, and 10 since I started building it a few years ago (at that time I was still running Windows 7), and using a little finesse, you can actually get an entire modern BLT-based Drupal 8 project running on Windows 7 or 8, as long as you do all the right things, as will be demonstrated in this blog post.
Between the rush of product updates we're putting out lately, a moment of reflection...
Like many other Drupal shops and theme/product developers I've been taking it easy with major investment in D8. But times are changing. Now we are seeing a time where Google searches including Drupal 8 are more numerous than searches containing Drupal 7. This is by no means a guarantee that D8 is a clear winner but to me it is a sign of progress and it inspires enough confidence to push ahead with our Drupal 8 product upgrades. SooperThemes is on schedule to release our Drupal themes and modules on Drupal 8 soon and I'm sure it will be great for us and our customers.
2017 will be an interesting year for Drupal, a year in which Drupal 8 will really show whether it can be as popular as it's younger brother. The lines in the chart might be crossing but Drupal 8 some way to go before it is as popular as 7. Understanding that Drupal 8 is more geared towards developers one might say it never will, but I think that it's important for the open web that Drupal will stay competitive in the low end market. Start-ups like Tesla and SpaceX have demonstrated how Drupal can grow along with your business all the way towards IPO and beyond.Is your business ready for Drupal 8?
Personally I think I will need a month or 2 before I can say I'm totally comfortable with shifting focus of development to Drupal 8. Most of my existing customers are on Drupal 7 and my Drupal 7 expertise and products will not be irrelevant any time soon. One thing that is holding me back is uncertainty about media library features in Drupal 8, I hope the D8media team will be successful with their awesome work that puts this critical feature set in core.
If you are a Drupal developer, themer, or business owner, how do you feel about Drupal 8? Are you getting more business for Drupal 8 than Drupal 7? How is your experience with training yourself or your staff to work with Drupal 8 and it's more object oriented code?
Let me know in the comments if you have anything to share about what Drupal 8 means to you!
As you can understand from name itself it’s basically used to Alter an email created with drupal mail in D7/ MailManagerInterface->mail() in D8. hook_mail_alter() allows modification of email messages which includes adding and/or changing message text, message fields, and message headers.
Email sent rather than drupal_mail() will not call hook_mail_alter(). All core modules use drupal_mail() & always a recommendation to use drupal_mail but it’s not mandatory.
$message: Array containing the message data. Below are the Keys in this array include:
- 'id': The id of the message.
- 'to': The…
I fully embraced the motto “go big or go home” when I started to think about my first solo community presentation for Stanford Drupal Camp 2017. I wanted to force myself to learn a subject well enough that I could explain it to others. I like a challenge, so I set my eyes on understanding the fundamentals of Git. My presentation slides can be found here: https://legaudinier.github.io/Ready-Git-Set-Go/#.
My trusty microphone, camera, and I recorded a few great conversations at DrupalCon in Mumbai that have never been released until now. Today, a conversation with Rakesh James, who credits Dries for giving him a way to live and support his family with Drupal. Rakesh is an extraordinary and generous person; he's personally paid that forward, giving others in India the chance to change their lives, too, by teaching hundreds of people Drupal and giving them a shot at a career, too. He's also a top 30 contributor to Drupal 8 core.
Rakesh told me about the moment he both discovered and fell in love with Drupal. His manager gave him permission to check out Drupal for a project, "I started it with Drupal 5. I got a big error. My senior [colleague] said I could post on Drupal.org because he was sitting far away and could not debug for me. I posted the error ... After one hour somebody from the community replied that it would be better if you started with Drupal 6. That was amazing. If you post it, somebody from the [other side] of the planet replied to me, 'You should do this.' From that amazing [moment] till now, I have that feeling. All the time when you go to the community and post something, you'll be getting the right answer. In an hour's time. That is so amazing."
"I feel like when I have gotten something, I should give back to others who are struggling. If they have a little education, know how to play with the computer, I should teach them Drupal. That is the best way of doing it. I spread the word because I got something. The people are around, this magic should be with them also ... So they will have a better life. They'll have a better salary. It's a better way to do that; teach the kids in pre-university colleges. We should teach them. I volunteer my time for that. Two Saturdays a month, we go out to the colleges. Every first Saturday, we have a community meet-up; the other Saturday we go to a college and teach them Drupal."
If you have any doubts about Rakesh's sincerity in all this, watch how moved he is in the video from about 10:30 to 11:50 :-)
DrupalCon Asia Mumbai 2016 was almost exactly a year ago now. Of all the conferences I have been to, Mumbai was probably my favorite. I met an incredible, active, enthusiastic Drupal community that welcomed everyone with open arms, incredible food (!), and a LOT of selfies :-)Subscribe to the podcast!
Subscribe to the Acquia Podcast in iTunes and rate this episode!
Subscribe via our RSS feed.Skill Level: BeginnerIntermediateAdvanced
Drupal 8 core provides for solid REST capabilities out-of-the-box, which is great for integrating with a web service or allowing a third-party application to consume content. However, the REST output provided by Drupal core is in a certain structure that may not necessarily satisfy the requirements as per the structure the consuming application expects.
In comes normalizers that will help us alter the REST response to our liking. For this example, we will be looking at altering the JSON response for node entities.
Tomorrow I'll be giving a workshop about the Drupal 8 media. As part of it we'll build a "media" site from scratch. We will start with the standard Drupal installation, add modules and configuration and see how far we can get.
If you are planning to attend the workshop and want to be fully productive I'd ask you to take some time and prepare your development environment. We will need Drupal 8 checkout with the following modules:
- Entity API
- Entity browser
- Entity embed
- Field formatter
- Inline entity form
- Media entity
- Media entity image
- Media entity Instagram
- Media entity Slideshow
- Media entity Twitter
- Slick media
- URL embed
- Video embed field
You can download all dependencies manually or use the project template that I provided for you. Simply clone the repository and run composer install in the project root.Enjoyed this post? There is more! Want to learn Entity browser? Possible solution for knowledge sharing in the Drupal 8 media domain Call for Drupal 8 media ecosystem co-maintainers
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.
We need ticket scanners, program dispersers, and people to answer questions.
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.
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
- Apply this core patch.
- 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.
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.
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.Figure 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).Figure 2: Johns Hopkins Women’s Cardiovascular Health Center landing page
Figure 3: University of Maryland Medical Center Women’s Heart Health Program landing page
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.Figure 5: Johns Hopkins Heart & Vascular Institute landing page
Figure 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.Figure 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.Figure 8: Johns Hopkins Heart & Vascular Institute landing page internal navigations
Figure 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.Figure 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.
It is now a common practice to use composer as part of the deployment stack. Is this always such a good idea?Tue, 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 ».
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?
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