Skip to Content

Planet Drupal

Syndicate content - aggregated feeds in category Planet Drupal
Updated: 13 hours 22 min ago

Lullabot: Better, then Bigger: Cultivating the Drupal Community

16 September 2015 - 8:02am

Each year at the largest Drupal conferences in the world, Dries Buytaert, the creator and project lead of Drupal, presents keynotes about the current “State of Drupal.” These events are well known in the Drupal community as “Driesnotes” (Dries, obviously influenced by Steve Jobs, has quoted Jobs in his keynotes and has even ended multiple Driesnotes with “one more thing,” much like a Stevenote). Frequently, Dries will clarify ideas from his keynotes on his personal blog, which was the case in a post from last year titled “Scaling Open Source communities.” While his title suggests a focus on open source software, his more immediate ambition is scaling Drupal. Indeed, Dries conflates “Drupal” with “Open Source” in his article, concluding, “we can scale Drupal development to new heights and with that, increase Open Source’s impact on the world.” Dries would like to grow Open Source (he likes to capitalize these words) by growing Drupal.

It was certainly not the first discussion about scaling the Drupal community, but when Dries first made his case for “scaling” in Amsterdam in 2014, many seasoned Drupalers immediately realized this was not a typical Driesnote. Dries referenced a variety of economic theories, covering topics such as “public goods,” the “free rider problem,” “self-interest theory,” “collective action theory,” “selective benefits,” and “privileged groups.” He was not talking about the average number of times Drupal had been downloaded each day or charting the number of contributed modules, as he often did in previous “states of Drupal” talks. Dries was engaging in analysis. He warned the audience that he had been reading “lots of economic papers,” admitted that “there’s an academic hidden inside me,” and pleaded, “please don’t fall asleep.” That such a talk required these disclaimers revealed the level of patience our community typically has had for academically-oriented analysis. Dries proceeded in his keynote (but not his blog post) to cite peer-reviewed articles from the economist Paul Samuelson and the American ecologist Garrett Hardin, and he extrapolated ideas from economist Mancur Olson’s well-known 1965 book, The Logic of Collective Action. Rather than just see Dries presenting, the audience witnessed Dr. Buytaert historicizing. The British journalist Will Self once remarked, “Visionaries, notoriously, are quite free from ratiocination and devoid of insight.” With his new ideas based on economic theories, Dries contested the stereotype. The reaction from the community was generally positive, with his talk garnering such accolades as “historic” and “the best Dries keynote ever.”

This Driesnote signaled a more nuanced critique from an entrepreneur more accustomed to discussing books about Drupal than books from academic presses. More important, since Dries started promoting his ideas about economic theory, some of what he suggested has become reality. It probably comes as little surprise that this “benevolent dictator” can get things done. On his blog and in his talks he suggested various changes to, such as improved organizational profile pages featuring more statistics and adding corporate attributions to individual commit credits in Drupal code (a topic he had blogged about previously). He offered other concrete suggestions that might very well still be in the works, including new advertising opportunities on in exchange for fixing bugs, the opportunity for organizations to get better visibility on the job board, and the ability to sort the marketplace page by contributions rather than just alphabetically. All of his suggested improvements were technical in nature, and ostensibly designed to benefit organizations.

To his great credit, Dries maintains an openness to other ideas. In his Amsterdam keynote, Dries said, “these are not final solutions. These are just ideas, and I hope they will be starting points for discussion” (34:53). He said, “this is just me brainstorming” (43:49), and that we should keep working at building our community, “even if it takes us years to get it right” (47:27). Accordingly, here I try to adopt a constructivist approach that adds to – rather than subtracts from – what Dries suggested. I am here to assemble, not debunk. I bring the same attitude that I aspire to when dealing with any of my colleagues, which is to assume positive motivation – I assume that Dries, like my co-workers, has good intentions (others of Dries’s critics seem to forget this). Like Dries, I care deeply about the Drupal community and I would like to understand more about the problems we face, what Drupal means, and how various changes might affect our community dynamics. In the remainder of this article, I will spend most of my effort dissecting Dries’s suggestions, the logic behind them, and how they compare to the theories of the economic theorists he cites. Finally, I will offer a few of my own suggestions. I believe that we will be most successful not merely by convincing more people to work with us through technological manipulations, but instead by focusing on improving interactions within the community and a goal of cultivating social solidarity. In other words, I will argue that instead of using technology to grow our community, we should focus our efforts on adjusting our culture in order to improve our technology.

What Is the Problem?

Before we can discuss solutions, we should consider the problems that need solving. Dries mentions generalized goals of attracting “more contributors” to the Drupal project in order to “try more things and do things better and faster,” without interrogating what “better” means or why “faster” should be a goal. His solutions seem to suggest that we should lure organizations to get more involved by hiring Drupal core developers, although Dries admits that “hiring Drupal talent is hard.” That Dries does not make explicit the benefits of growing the community beyond increasing our capacity to do things “better and faster” indicates that he understands the problem to be obvious. But is the problem actually that straightforward? Does bigger mean better? Should we consider goals beyond growing the community?

Evgeny Morozov, a rigorous thinker with a combative style, would label Dries’s approach “solutionism.” In To Save Everything, Click Here: The Folly of Technological Solutionism, Morozov writes, “Solutionism presumes rather than investigates the problems that it is trying to solve” (6). Morozov is frustrated by the prevalence of solutionism in technology debates and he dislikes any debate that presupposes the inherent worth of technologies such as “the Internet” (nowadays, Morozov always puts “the Internet” in scare quotes) or Open Source. I agree, and for our purposes, we should not assume that scaling open source, or Drupal, is a venture of unquestionable worth. Do we grow Drupal for social reasons? Are we politically motivated? Is this activism? Is this a philosophical debate? Or should we all just assume economic motivations? Whatever the impetus, I feel that when we talk about growing Drupal, we should not approach this activity as one with absolute value.

One potential benefit might be to increase business. Perhaps Dries feels it unnecessary to explain his motives. Dries is not just a developer, he’s also a successful entrepreneur. Dries discusses his ideas about “scaling” on his blog, which is also the place where he posts his annual “retrospectives” about his Drupal company, Acquia. In other words, Dries uses his blog not just to share personal information and news related to the Drupal project, he also uses his blog for business. So it seems quite probable that he wants to do more than grow the community, and that his goal is also to grow his company. Dries has fully committed himself to Drupal, and as the value of the Drupal software increases, so does the value of his Drupal company. One can hardly fault someone who has to answer to investors and who seeks to take his company public.

Another possibility is that Dries needs to defend his company. Dries is keenly aware that Acquia contributes disproportionately more to the Drupal project than any other company, and he understandably seeks to change this situation. Indeed, multiple times during his presentation Dries discusses the ratio of contributors. Dries says that it is “all about this ratio” (26:29 minutes into his talk) and that changing the ratio “will fundamentally change the dynamics of the community” (26:40). I agree with the latter part of his suggestion in that growing the community beyond Acquia will ease the “exploitation” of Acquia. While “exploitation” may seem a bit strong in this context, I borrow this word from one of Dries’s primary informants, Mancur Olson, who uses it repeatedly in The Logic of Collective Action. Olson believes there exists a “systematic tendency for ‘exploitation’ of the great by the small” (29). So applying Olson’s idea to Dries’s subject, we could understand why Acquia – run by the founder of Drupal, offering Drupal services, and employing more Drupal contributors than any other organization – has to carry the most weight. We should not feel too bad, however, because while it may be that Acquia contributes disproportionately to Drupal, it is also true that Acquia benefits disproportionately as Drupal gets better. Arguably, Dries and his company have the most to gain when others participate in Drupal.

While Acquia grows with Drupal, there are certainly many others in the Drupal community that stand to benefit as well, especially the many other Drupal “agencies” (including Lullabot, where I work) as well as Acquia’s many partners. Dries writes, “my company Acquia currently employs the most full-time contributors to Drupal but does not receive any exclusive benefits in terms of monetizing Drupal. While Acquia does accrue some value from hiring the Drupal contributors that it does, this is something any company can do.” Certainly another part of Dries’s project is to entice Drupal agencies to contribute. But doesn’t this happen already? Don’t agencies understand that the prospect of scaling Drupal will lead to more clients and that it is in their best interest to contribute to Drupal? This topic of individuals contributing to groups is, in fact, one of the main subjects in Olson’s book, with his main point being that as groups get larger, rational individuals are less likely to participate. Olson’s thesis is that in large groups, “rational, self-interested individuals will not act to achieve their common or group interests” (2). Consequently, it is not difficult to understand why Dries was drawn to Olson’s theories – Olson’s study offers multiple perspectives on why individuals do not contribute to large groups, which Dries can use to help understand why all of these Drupal agencies do not fund as many Drupal core developers as Acquia. Even better, it offers multiple ideas about how to entice these agencies to help make Drupal “better and faster.”

While it would seem that Dries is focused primarily on growing Acquia and other Drupal businesses, he would also like to attract individuals. He later clarified his goal in a comment of a curious blog post, maintaining that he “proposed ways to increase the social capital of both individuals and organizations.” His most immediate goal is not, in fact, to “scale Open Source.” Rather, he seeks to encourage individuals and organizations to contribute to Drupal. And from Olson, Dries learns more methods for coercion, another term that Olson uses frequently in his book. Olson believes that members of a group will not “act to advance their common or group objectives unless there is coercion to force them to do so, or unless some separate incentive, distinct from the achievement of the common or group interest, is offered to the members of the group individually on the condition that they help bear the costs or burdens involved in the achievement of the group objectives” (2). Olson talks at length about various types of incentives – social, selective, economic, etc. – that would make participation in a group more rational.

It can be quite tricky to grok the motivations of the organizations and individuals that contribute to the Drupal project. Olson focuses primarily on individuals who are rational and self-interested. Olson’s subjects are individuals that “rationally seek to maximize their personal welfare” (2). In a similar manner, Dries believes “modern economics suggest that both individuals and organizations tend to act in their own self-interest,” even as he admits that contributions to Drupal are “often described as altruistic.” Dries’s discussion of “self-interest” hints at the difficulties in characterizing the motivations for participating in our community, and the need for subtlety. Especially with Drupal agencies, it can be difficult to generalize motivations. For example, I was recently talking with a senior member of the Drupal community, and a former Lullabot employee, who described Lullabot as a “lifestyle company” that seemingly puts the needs of its employees ahead of profit, and that is extremely selective when evaluating potential projects. His description of Lullabot feels apt, and by no means exclusive to Lullabot. Four Kitchens takes a similar approach with its employees by striving to cultivate a “culture of empowerment.” Think Shout goes a step further, having recently become a B Corp, which is a type of for-profit company that is required to make a positive impact on society and the environment. Or consider Enjoy Creativity, a nonprofit organization – required to act for the public good – that builds Drupal sites for churches and ministries. These kinds of Drupal agencies seem motivated by goals that are different from – if not in conflict with – traditionally capitalist goals where “the common good” is, as Ayn Rand put it, “merely a secondary consequence.” We might conclude that sometimes we just help others for no rational reason, and that, as Nietzsche famously observed, “in everything one thing is impossible: rationality.” Or we might adopt a more optimistic view, as Dries did in The Next Web, and conclude that “capitalism is starting to become more collaborative rather than centered around individual ownership.”

So it seems there exists a wide variety of potential problems that need solving, although few of them feel urgent. First, Acquia has too much control. One of our goals should be to ensure that Drupal is understood as institutionally independent and that no single company dictates its future. I agree with Dries in that we should work to change the ratio of developers contributing code to Drupal. Second, we should ensure that Drupal continues to welcome a wide variety of individuals and organizations, both those that have the resources to contribute to core and those that do not. Drupal must not be construed as something only for business. After all, we do not know if Drupal will survive without individual contributors. Finally, we should strive to adapt to change and continue to make decisions that are understood as welcoming as well as benefiting a broader community. It is fine to desire more individual and organization participation, but not if that means alienating significant groups within the community. In other words, rather than asking if a change will grow the Drupal project, we should ask if it will improve the Drupal project.

Drupal: Public Good or Collective Good?

Perhaps even more confounding than articulating Drupal’s problems is the task of determining what Drupal is. Previously I explored the “cultural construction of Drupal” and various narratives about Drupal in our community. Dries offers yet another narrative when he states clearly his belief that “Open Source projects are public goods.” He arrives at this conclusion because he feels that open source meets the two relevant criteria of “non-excludability” (“it is impossible to prevent anyone from consuming that good”) and “non-rivalry” (“consumption of this good by anyone does not reduce the benefits available to others”). Again, this is Dries borrowing from economic theory, and on the surface this seems like a useful way of thinking about Drupal, as well as free software.

Dries’s use of the term “public good” is not problematic in that a large body of research uses this term. However, returning to Olson, it seems unlikely that he would call Drupal a “public good” and that he would have instead used the term “collective good” or “common good.” Olson characterizes public goods as government goods. I arrived at this conclusion not only because Olson based his research on Paul Samuelson’s work – whose essay mentioned “collective,” not “public,” goods – or because the title of Olson’s book is the Logic of Collective Action, but also because Olson made statements like this in his book: “The common or collective benefits provided by governments are usually called ‘public goods’ by economists” (14, emphasis added). Olson was actually quite specific about this distinction between “public” and “collective” goods: “A state is first of all an organization that provides public goods for its members, the citizens; and other types of organizations similarly provide collective goods for their members” (15). Even so, Dries very clearly compared Drupal to other public goods that eventually became the purview of the government – on one slide he placed Drupal alongside roads, schools, parks, streetlights, and defense. He was clear that each of these goods went from “invention” to “product” to “utility,” and that each was controlled by “volunteers,” then “business,” then “government.”

While Dries certainly was not suggesting that the government take over control of Drupal, it seems a curious choice to compare Drupal to government projects. It makes for an interesting thought experiment to consider what happens when we understand Drupal as a public good, controlled by the government. Olson’s study, after all, concerns groups (representing individuals) that work for common interests. So to begin, it would make sense that the Drupal Association – a nonprofit “dedicated to helping the open-source Drupal CMS project flourish” – would be the group that represents we, the Drupal community. Partially akin to one of Olson’s labor unions, the Drupal Association works for a common interest. But what branch of the government would control Drupal? Would this also be the Drupal Association, with Dries as its president, moving under the purview of the government? Or would the government hire the core committers, with Dries still in his role as the benevolent dictator? But enough of that. One could (and should) object that comparing Drupal to the government is obtuse, and that it suggests a kind of economic determinism in which Drupal would become a government utility, which is clearly not anyone’s goal. I would agree, and while this may seem silly to construct a building with the lights on and nobody home, it helps to reveal what we already know – we do not actually want the government involved in Drupal. Many people in our community, including Dries, do not really consider Drupal to be like other government projects. Drupal is our project. We make it what we want and we do not want to (nor can we, really) hand the keys over to the government.

So what happens when we shift the focus to free software as a “collective” good? To be clear, this use of “collective” does not signify “the collective life of humanity” (as Philip Gilbert Hamerton once put it), but rather a group of individuals acting together. Conceiving of Drupal as a “collective” rather than a “public” can be helpful for a variety of purposes. For one, it helps to explain why Holly Ross, the executive director of the Drupal Association, talks openly and thoughtfully about why she is starting to question whether the most appropriate tax classification for the Drupal Association is 501c3 – an organization that exists for the public good – or if it should more appropriately be classified as a 501c6, a trade organization whose purpose is to grow the businesses that support it. While I was quite taken aback when she admitted this to me, I can understand the thesis. It seems quite likely that our community is moving away from the notion of Drupal as something for the public and instead something for our collective. The internal deliberations of the Drupal Association are yet another indication that our group is gradually becoming more business focused.

In the end, it does not especially matter if Drupal is a public good or a collective good if our focus is on improving the Drupal project. Our group, like the large organizations that Olson analyzes, is growing not just in members and contributors, but also in complexity of problems. We have a wide variety of ways to understand our community and its corresponding problems. A growing percentage of our membership is both self-interested and economically motivated, while other factions lean toward the selfless or the seemingly irrational. How one understands our community, and the problems that need solving, greatly informs how we go about finding solutions.

The Trouble with Technical Fixes

Dries likes to fix problems with technology because, like countless entrepreneurs before him, Dries has great faith in technology. He writes, “We truly live in miraculous times. Open Source is at the core of the largest organizations in the world. Open Source is changing lives in emerging countries. Open Source has changed the tide of governments around the world.” Talk of “miraculous times” is a bold assertion. It’s also an example of an attitude that Morozov, that pugnacious and insightful technology critic, describes in his book, To Save Everything, Click Here, as “epochalism”, or “to believe one is living in truly exceptional times” (36). The problem with this attitude, Morozov claims, is that it leads to unhealthy beliefs about technology. What Dries claims for Open Source is quite similar to what others had envisioned for the telegraph, radio, telephone, television, personal computers, and countless other technologies, which Morozov takes up in his book, The Net Delusion. Morozov cites a bevy of ideas with eerily familiar conjecture, some of which are worth noting here. For example, in 1858, a New Englander editorial proclaimed: “The telegraph binds together by a vital cord all the nations of the earth” (276). In 1921 the president of GE predicted that radio would be “a means for general and perpetual peace on earth” (278). And just a few years later, the New York Times critic Orrin Dunlap would foresee that “Television will usher in a new era of friendly intercourse between the nations of the earth” (280). Fast forward to 2014 and we read Dries making similar prognostications about open source changing organizations and governments. This belief in technology entices us into using it for new purposes.

Dries’s choice of a technical solution is confusing. In addition to works by Samuelson and Olson, Dries cites in his keynote a well-known article by Garrett Hardin titled “Tragedy of the Commons” (20:45). Dries is vague about how he understands this article (he accidentally calls it a “book”), which makes it all the more curious why he would mention it. The epigraph of the article reads, “The population problem has no technical solution; it requires a fundamental extension in morality” (emphasis added). What is more, Hardin’s first sentence contains the following quotes from Weisner and York: “It is our considered professional judgment that this dilemma has no technical solution. If the great powers continue to look for solutions in the area of science and technology only, the result will be to worsen the situation” (1243). Hardin was bullish in his suspicion of “technical solutions,” reiterating his position four years later in the preface to his 1972 book, Exploring New Ethics for Survival: “For too long have we supposed that technology would solve the ‘population problem.’ It won’t.” Like Morozov, Hardin is suspect of technical fixes to complex problems. Since Hardin’s essay focused on “a class of human problems” that he described as “no technical solution problems,” perhaps there was another aspect that Dries found helpful.

Hardin, who contends “it takes courage to assert that a desired technical solution is not possible” (1243), had agonized over how to convey his conclusions. Hardin also believes that we cannot succeed by appealing to conscience or by making people feel guilty. Hardin, like Olson, speaks of “coercion” to counteract the effects of self-interest. Hardin recommends that we cannot appeal to a person’s “sense of responsibility” but rather that in order to make changes we instead need a “mutually agreed upon coercion,” and that it may require infringing on personal liberties. He talks of the need to take away freedoms for the common good. Thirty years later, in 1998, Hardin would describe the ideas he presented in his earlier essay as his “first attempt at interdisciplinary analysis.” He felt that he was trying to solve a problem so large – the human overpopulation problem – that he could not employ simple, technological fixes, and that it would be necessary to draw on conclusions derived from multiple disciplines. People, not computers, would have to work together.

Moreover, there are pitfalls with technological fixes beyond what Hardin construes (and again, I draw inspiration from Morozov and others). For example, introducing technological fixes can irritate existing social conflicts. Organizations that have long flourished in the Drupal community might be embarrassed by the new profile pages and might be less inclined to contribute, not more. Technological fixes can also distract, or act as mechanisms for denying the existence of deeper social problems – higher listings on the marketplace page, for example, will not distract individuals and organizations that are upset by Acquia’s sales techniques or who have concerns about its influence on Drupal Association webinars. When technological fixes do not work, they can have the effect of making us think that we just need a different technological fix. Dries seems to express just this attitude when he writes, “There are plenty of technical challenges ahead of us that we need to work on, fun ideas that we should experiment with, and more.” If these are intellectually challenging problems that require serious discussions, and not just “fun ideas,” we will never get to the point of solving our problems.

Perhaps the most troublesome trait of technological fixes is when they close down thoughtful contributions by people with knowledge about addressing social and political problems. Dries broaches the topic of “social capital” in his Amsterdam keynote (28:24), saying, “this is where we are good.” But he follows that up, suggesting that “altruism” and “social capital” are not scalable (31:37) and that these are not solutions for Drupal (31:55). Why close down discussion of these topics and abandon ideals that have served the community so well? What would happen if, rather than discarding these modes of investigation, we dug deeper to find alternative answers? What if the solution to scaling Drupal lies not with technology? What if, rather than use technology to change our community and culture we reverse our efforts and instead focus on making adjustments to our culture in order to improve our technology? Or perhaps we should only consider technological fixes that support broader efforts to improve the Drupal project rather than simply grow it? As the German philosopher Martin Heidegger put it, “the essence of technology is by no means anything technological.”

Sprouting Social Solidarity

When I suggest we need to look beyond technical solutions, this is not necessarily contra Dries. In another, much shorter blog post on “Open Source and social capital” – posted less than a month before his post about “scaling Open Source” – Dries concluded, “social capital is a big deal; it is worth understanding, worth talking about, and worth investing in. It is key to achieving personal success, business success and even happiness.” Plus, Dries has written about “fostering inclusivity and diversity” on his blog. Like Dries, I do not believe that there is only one way to grow the Drupal community. We can use technology to support our broader goals, so discarding all technological fixes is not my objective. Rather, I am suggesting an approach to cultivating our community that mirrors how we make changes to Drupal code – we carefully consider how each change will improve the overall project, never assuming that more automatically means better.

What is more compelling to me than technological fixes is to examine how Drupal and cultures around the globe shape each other, and how we can create more situations where more individuals make the choice to start participating in our community. This mode of investigation requires a multidisciplinary approach, a broader understanding not just of economic transactions, but also human interactions. I agree with Lars Udéhn’s assessment that “Olson’s theory of collective action has proved inadequate and must be replaced by a theory assuming mixed motivations” (239). The last time I checked, Drupal’s unofficial slogan is not “come for the code, stay for the economy” – it’s about community, and that is where I believe we should concentrate our efforts.

While I found Dries’s turn to analysis refreshing, I also question that his informants offer the most helpful of ideas. Hardin changed his mind many times over his career, a fact he readily admits, so it would seem reasonable to explore his later ideas. Samuelson’s article, with its thick prose and mathematical formulas, feels quite unrelated to Drupal. It seems reasonable that someone like Dries, with all his responsibilities, should not be compelled to trace the history of theories of rationalism and social action from Aristotle to Descartes to Kant to Max Weber and beyond – especially not in a single Driesnote. If only we did not have those pesky clients to help and 529s to fund, we could explore more of these ideas. All of this is but a reminder that Dries’s sources are certainly not the last words on these subjects.

Not to pick on Olson, but it also does not seem as though he considered the full force of social solidarity to Marx’s thinking about motivation. In his Economic and Philosophical Manuscripts, Marx writes of workers who get together to further their shared goal, “but at the same time, they acquire a new need – the need for society – and what appears as a means had become an end.” For Marx, building relationships was another form of production, and social solidarity was a key component for bringing about change (for more detailed critiques of Olson’s interpretation of Marx, see, for example, Gomberg or Booth below). Likewise, social solidarity is a significant force in the Drupal community. In my local Drupal community we not only have a monthly “user group” meeting, but every month we also have a “jam session” (coder meetup), community “lab hours,” and a social meetup at a bar. Many individuals in our community help organize the Twin Cities DrupalCamp, attend the nearby DrupalCorn or DrupalCamp Midwest, and travel to the annual North American DrupalCon (DrupalCons, organized by the Drupal Association, are the largest Drupal conferences in the world). The people we interact with become important to our lives – not just collaborators, but friends. “It is not the consciousness of men that determines their existence,” Marx wrote in A Contribution to the Critique of Political Economy, “but their social existence that determines their consciousness.”

We, as a community, would benefit from questioning our own unexamined beliefs, no matter what discomfort it may cause. We should continue to ask if successful programs like D8 Accelerate – a project that funds Drupal core development through grants – truly benefit our community, or if they might foster a collective motivated primarily by money. The way Drupal production is organized affects our understanding of it, and how we choose to coerce individuals matters. While many would prefer economic incentives and hard science over humanities, some in our community are marginalized and brushed aside by such priorities. Perhaps we will determine that it is in our best interest to ensure that our community exists more for the public than for our collective. It could be that programs like D8 Accelerate negatively affect solidarity.

If IRC and issue queues online beget lively debates at conferences and code sprints in person, we should continue to examine each of those interactions. For instance, I agree with Larry Garfield when he writes, “The new contributor first commit is one of #DrupalCon’s most important rituals.” At the end of a week-long conference, the community code sprint occurs on the final day. During this sprint, veteran Drupalers train new contributors about the peculiarities of contributing code to the Drupal code base. Near the end of the day, one or more lucky individuals are picked to go in front of everyone else where Dries commits that person’s contribution. Personally, it was this event that got me hooked on the Drupal community. This symbolic act welcomes people to our community, demonstrates their worth, and gives future contributors some extra motivation as they work toward finding problems to solve.

Moreover, we should promote a wide variety of events, encouraging more meetups, social events, and quasi-productive gatherings where code and conversation flow freely. The Drupal Association has already made steps in the right direction when they announced the results of their survey and their resulting “new approach to community at DrupalCon.” The community theme in this announcement was comprehensive: “Community Keynote,” “Community Kickoff,” “Community BoFs,” “Community Training,” and “Community Sprints.” One could argue that the Drupal Association is bringing these activities back, and that previously they did not require the “community” prefix.

Finally, I hope to see more thoughtful writing from our community about our community. The complexity of our community makes this a difficult task for an outsider. In addition to recommendations about “how to configure a View” and “how to make a page load faster” on Planet Drupal, many of us would like to know how other local Drupal communities work. What has been successful? How do they grow their membership? What does it mean to grow membership? The problem is not that we never discuss these issues, it is that we tend not to interrogate these issues more thoroughly “in print.” Drupal Watchdog is a step in the right direction, with its slightly longer form articles that allow the community to share their ideas in a more considered manner than a traditional blog post. While sharing ideas is nice, it can be even more helpful to share our ideas after they have been improved by an editor. While there are many issues of Drupal Watchdog that contain content that I find less engaging, I am glad that it allows for a wider range of voices.

All too often we incorrectly describe Drupal as a means to an end, detached from a political agenda. We forget that organizations use Drupal not only as a tool, or even because of the community. Some organizations, such as the Free Software Foundation, clearly choose their software, including Drupal, for philosophical reasons first. Or consider the American Booksellers Association (ABA), an organization engaged in political and trade-related efforts geared toward helping independently owned bookstores. The ABA’s hundreds of Drupal websites represent just one component of their larger political project. Like so many nonprofits, the ABA has a staff of passionate individuals dedicated to the cause, and their conception of Drupal must not conflict with their ideals. Consequently, I would like to see more posts on Planet Drupal that test the boundaries of the guidelines, which discourage “posts that don’t provide valuable, actionable content.” It would be nice to see more thoughtful articles that discuss political agendas and activities, and then describe how Drupal supports those activities. Countless people are inspired to use Drupal for reasons that have nothing to do with technology, and we should consider encouraging more of these stories.

While I have many other ideas that I am tempted to suggest here, those ideas are more properly topics for another article. That said, I think we can certainly benefit from studying other free software communities. When I was sitting in the audience for the DriesNote at DrupalCon Los Angeles in May, I suggested on Twitter that it “sounds like @Dries gets lots of inspiration from proprietary products (Pinterest, Pandora), rather than from other free software.” Dries later saw my tweet and clicked the “Favorite” button. I think we would benefit not just from discussing other free software projects, but also interrogating the thinking about them. The kind of scholarship that I have found most illuminating is not that of economists, but rather work like Gabriella Coleman’s anthropological studies of the Debian community and groups associated with Anonymous, as well as Christopher Kelty’s ethnographic research into free software. There is a great deal to be gained by considering our ideas about Drupal in light of what we know about the Linux community, the Fedora project, OpenStack, and other large free software communities, while acknowledging that the Drupal community is complex and that there are no easy answers or solutions.

The distinguished literary theorist Terry Eagleton has remarked, “most people are too preoccupied with keeping themselves afloat to bother with visions of the future. Social disruption, understandably enough, is not something most men and women are eager to embrace” (194). I understand why many in our community would not be quick to embrace any sort of radical change, but I also think it’s important that we talk about these issues. We cannot offload all of our problem solving to technology. To change what we think, we must change what we do. Making the case that the Drupal project should focus on its community and culture might seem less exciting the innovative technical solutions, but I hope to have highlighted just a few of the approaches to understanding our community that could prove beneficial, and that we should be careful as we consider which of them to adopt. Dries, in his recent turn to historicizing, is on the right track, and I hope the conversation continues.

Works Cited

Booth, Douglas E. “Collective Action, Marx’s Class Theory, and the Union Movement.” Journal of Economic Issues 12 (1978): 163-185.

Coleman, Gabriella. Coding Freedom: The Ethics and Aesthetics of Hacking. Princeton: Princeton University Press, 2012.

Coleman, Gabriella. Hacker, Hoaxer, Whistleblower, Spy: The Many Faces of Anonymous. New York: Verso, 2014.

Eagleton, Terry. Why Marx Was Right. New Haven: Yale University Press, 2011.

Gomberg, Paul. “Marxism and Rationality.” American Philosophical Quarterly 26 (1989): 53-62.

Hamerton, Philip Gilbert. The Intellectual Life. New York: Macmillan, 1875.

Hardin, Garrett. Exploring New Ethics for Survival: The Voyage of the Spaceship Beagle. New York: Viking Press, 1972.

Hardin, Garrett. “Extensions of ‘The Tragedy of the Commons.’” Science 280 (1998): 682-683.

Hardin, Garrett. “The Tragedy of the Commons.” Science 162 (1968): 1243-1248.

Heidegger, Martin. The Question Concerning Technology and Other Essays. New York: Garland, 1977.

Kelty, Christopher. Two Bits: The Cultural Significance of Free Software. Durham: Duke University Press, 2008.

Morozov, Evgeny. The Net Delusion: The Dark Side of Internet Freedom. New York: PublicAffairs, 2011.

Morozov, Evgeny. To Save Everything, Click Here: The Folly of Technological Solutionism. New York: Public Affairs, 2013.

Nietzsche, Friedrich. The Portable Nietzsche. Translated by Walter Kaufmann. New York: Penguin Books, 1977.

Olson, Mancur. The Logic of Collective Action: Public Goods and the Theory of Groups. Cambridge, Mass.: Harvard University Press, 1971.

Rand, Ayn. Capitalism, the Unknown Ideal. New York: New American Library, 1966.

Samuelson, Paul. “The Pure Theory of Public Expenditure.” The Review of Economics and Statistics 36 (1954): 387-389.

Self, Will. How the Dead Live. New York: Grove Press, 2000.

Udéhn, Lars. “Twenty-Five Years with ‘The Logic of Collective Action.’” Acta Sociologica 36 (1993): 239-261.

Categories: Drupal

Drupal Bits at Web-Dev: Module Release: Hook Update Deploy Tools

16 September 2015 - 6:53am

After working on several sites that were using hook_update_N() in install files to handle continuous site deployment by enabling modules, reverting features, updating menus and setting variables, we (CivicActions) built a handful of methods to more safely support that and issue better feedback when running `drush updb` or using update.php. 

Categories: Drupal

Pronovix: Join the upgrade Bingo and get free qualified Drupal 8 leads

16 September 2015 - 5:19am

To get site owners to start thinking about upgrading to Drupal 8 and to build anticipation for the upcoming release we are organising an upgrade Bingo and we want the whole Drupal community to benefit from it. If you want to get leads for site upgrades, Drupal 8 hosting, or paid Drupal 8 module development, you should not miss out.

Categories: Drupal

InternetDevels: 10 most famous and interesting Drupal websites

16 September 2015 - 4:38am

About 600 new websites appear in the world every minute. For sure, even not a half of them is run on Drupal, however, quality of this platform tells its own tale: developers of Twitter, Pinterest for business, eBay, Inc. and many other companies prefer Drupal as their CMS. Get ready: our Drupal team picked up 10 the most interesting and famous Drupal websites that will capture your attention.

10) Tesla Motors

Read more
Categories: Drupal

KnackForge: Drupal 7 audio player with download

16 September 2015 - 3:14am

In this post, I would like to explain how to have a download button for an audio file along with an audio player. My objective was to allow users to play the audio file using a media player and also allow them to download the file using a button.

For this purpose, I created a content type called "Media" with "field_audio" as the audio file field. I chose Mediafront module for the audio player. I hope setting up the audio player won't be that difficult, so let's move into the coding part.

I used hook_menu() for registering drupal path to define how audio download link should be handled.

function kf_menu() {   $items['download/media/%file'] = array( 'page callback' => 'kf_download_file', 'page arguments' => array(2), 'access arguments' => array('view media'), 'type' => MENU_CALLBACK, ); return $items; }

The important part of the code is in the menu callback, as this part of the code transfers the file to the client using HTTP.

Categories: Drupal

Mike Crittenden: How Drupal 7 Works, Part 3: The Router

16 September 2015 - 3:13am

This is a chapter out of my in-progress book, Drupal Deconstructed. You can read it online for free, download it as a PDF/ePUB/MOBI, or contribute to it on GitHub.

Alright! Now we're getting somewhere! Here's what we have so far. We have our request to /about-us and we've already run through a full Drupal bootstrap, thanks to index.php.

Now comes the fun part.

A quick summary

If you want the nickel tour of the Drupal menu router (or you don't want to look at any code), then you're in the right place. Here's what you can expect.

First, the very last line of the index.php file kicks things off by telling the menu system to figure out what the request is asking for, and serve it. This happens by looking at the menu_router database table to see if there are any rows that match the current URL.

Assuming we find a match (in this case, our about-us path has been converted during the bootstrap process to something like node/1234, which matches node/% in the menu_router table), we call whatever function the menu_router table tells us to call.

That function will be responsible for building the page content, and the rest is history (or, will be covered in other chapters).

Now, to dig a little deeper.

Step 0. Fetching the system URL for a path alias

We start with step 0 because it has already happened. Remember in the Bootstrap chapter that, during the DRUPAL_BOOTSTRAP_FULL phase, the drupal_path_initialize() function is called. That function just makes sure that $_GET['q'] is set (if it's not, then it sets it to the frontpage URL).

Then, more importantly, it runs through drupal_get_normal_path() to see if we are looking at a path alias rather than an internal path, and if so, replaces it with the internal path that it's aliasing.

All that is to say that by the time the bootstrap is done, $_GET['q'] is set to node/123 even though the initial request was for about-us, because it converts alias paths to system paths.

Step 1. Kick things off from index.php

Our index.php file calls the grand menu_execute_active_handler() function.

First, it checks to see if the site is offline and bypasses a lot of logic if that's the case. It even gives modules a chance to have their say as to whether the site is offline, using hook_menu_site_status_alter().

$page_callback_result = _menu_site_is_offline() ? MENU_SITE_OFFLINE : MENU_SITE_ONLINE; $read_only_path = !empty($path) ? $path : $_GET ['q']; drupal_alter('menu_site_status', $page_callback_result, $read_only_path);

Assuming it's online, then things finally start to get interesting.

From here, we call the menu_get_item($path) function, which does many things, all of which basically amount to "tell us everything we need to know about what to do with this path".

Step 2: Possibly rebuild the menu system

The first interesting thing that function does is check to see if we need to do a menu rebuild, and kicks one off if so.

if (variable_get('menu_rebuild_needed', FALSE) || !variable_get('menu_masks', array())) { if (_menu_check_rebuild()) { menu_rebuild(); } }

We'll assume for now that we don't need to rebuild the menu table, but later in this chapter we'll talk about what happens there.

Step 3: Find the most relevant menu_router row for this path

Still inside menu_get_item().

So with the assumption that we don't need to rebuild the menu system, we can continue on to actually finding what to do for the path we're on. To do that, we query the menu_router table. This table is the source of truth for "what do I need to do for this path?"

Here's the structure of it:

mysql> explain menu_router; +-------------------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------------------+--------------+------+-----+---------+-------+ | path | varchar(255) | NO | PRI | | | | load_functions | blob | NO | | NULL | | | to_arg_functions | blob | NO | | NULL | | | access_callback | varchar(255) | NO | | | | | access_arguments | blob | YES | | NULL | | | page_callback | varchar(255) | NO | | | | | page_arguments | blob | YES | | NULL | | | delivery_callback | varchar(255) | NO | | | | | fit | int(11) | NO | MUL | 0 | | | number_parts | smallint(6) | NO | | 0 | | | context | int(11) | NO | | 0 | | | tab_parent | varchar(255) | NO | MUL | | | | tab_root | varchar(255) | NO | MUL | | | | title | varchar(255) | NO | | | | | title_callback | varchar(255) | NO | | | | | title_arguments | varchar(255) | NO | | | | | theme_callback | varchar(255) | NO | | | | | theme_arguments | varchar(255) | NO | | | | | type | int(11) | NO | | 0 | | | description | text | NO | | NULL | | | position | varchar(255) | NO | | | | | weight | int(11) | NO | | 0 | | | include_file | mediumtext | YES | | NULL | | +-------------------+--------------+------+-----+---------+-------+ 23 rows in set (0.00 sec)

That's a lot of stuff right? The primary key is the path field, and everything else is just data about the given path. Here, we can find access arguments/callbacks, page arguments/callbacks, whether the page is a local task (tab) or a menu item or just a plain old callback, any theming alterations to consider, and a ton of other stuff.

So we have a path, and we need to fetch all that other stuff about it. But unfortunately we can't just query for the path, because we care about ancestors. That is to say that, given a URL of node/1234/edit, all of the following need to be returned as matches (in order of best match to worst match):

  • node/1234/edit
  • node/1234/%
  • node/%/edit
  • node/%/%
  • node/1234
  • node/%
  • node

Why? Well, because there probably isn't a row in menu_router with a path of exactly node/1234/edit. It's node/%/edit that will be our match, because that's the first one in that list that will actually exist in menu_router.

But remember, this is a simple example. What about a custom path of people/george/bio/picture/profile which ends up matching with our custom path of people/%/bio/picture/%? Can you see why it's important to ask for all possible ancestor paths, and that way we can find the one that's the most specific match, and use that?

So before we query menu_router, we need to call menu_get_ancestors($path) to fetch the possible ancestor paths for the given path. Only then can we query menu_router to find the path that fits the best. Here's how that all looks at a code level.

$original_map = arg(NULL, $path); $parts = array_slice($original_map, 0, MENU_MAX_PARTS); $ancestors = menu_get_ancestors($parts); $router_item = db_query_range('SELECT * FROM {menu_router} WHERE path IN (:ancestors) ORDER BY fit DESC', 0, 1, array(':ancestors' => $ancestors))->fetchAssoc(); Step 4. Allow altering the router item

Still inside menu_get_item().

Before we can continue on, we need to give modules the ability to alter the menu item right away, before anything else happens, using hook_menu_get_item_alter().

drupal_alter('menu_get_item', $router_item, $path, $original_map);

This differs from the more commonly used hook_menu_alter() in that this is at run-time, as opposed to hook_menu_alter() which only runs when the menu system is being built, and doesn't run as part of a page request.

Step 5: Check for access to the router item

You guessed it! Still inside menu_get_item().

This part is more confusing than you may expect.

It's confusing first of all because it happens in a function called _menu_translate() which means "translate" as in "translate placeholders in the URL to loaded entities (or other things), when needed". (It also translates the menu title to the appropriate language later in this same function, confusing things further).

To start, it needs to translate placeholders (i.e., "%" signs) in paths to the loaded entity if a load function exists for it. For example, if our path in menu_router is node/%node then this chunk of code will say "ok, I see %node as opposed to just %, therefore, I know I need to run node_load() on whatever is in that part of the URL, which in this case is 1234.

To do this, it runs _menu_load_objects() which calls the appropriate load function if there is one and, assuming we don't get an access error, a missing entity, or anything else which would cause a problem, put the result (i.e., the fully loaded entity) back into the menu router item for later use.

As a side note, this is a very common place to hit an access denied page, in cases where the user doesn't have access to whichever entity we're trying to load. For example, an anonymous user trying to view an unpublished node would fail at this step.

So we've made it this far, and we have a loaded entity (remember that the /about-us page we're talking about is a node), but we're not in the clear yet. We still haven't run the access_callback function given to us from the menu_router table.

That part happens via a call to _menu_check_access(), which basically runs the function set in access_callback if one exists, otherwise it falls back to user_access(), and includes any defined access_arguments. The fallback to user_access() means that we can just pass in a permission as access_arguments completely and leave out access_callback in our hook_menu() and it works out just peachy, which is a nice little shortcut.

And we have finally reached the end of menu_get_item()! Hooray!

Step 6: Call the appropriate function for this path

Back inside menu_execute_active_handler(), and here's what we know at this point:

  • We know that whether the user has access to this page or not
  • We know what function to run if the user does have access
  • We know which arguments to pass into that function, if any

We also know a lot of other stuff, but that's all details. Those 3 bullets are all we need at this point.

This little chunk of code is so nice and readable that I'm going to include it directly:

if ($router_item['access']) { if ($router_item['include_file']) { require_once DRUPAL_ROOT . '/' . $router_item['include_file']; } $page_callback_result = call_user_func_array($router_item['page_callback'], $router_item['page_arguments']); } else { $page_callback_result = MENU_ACCESS_DENIED; }

Nice and simple. If we have access, include any given include file if needed, call whatever the page_callback is, and include any given page_arguments. Or, if we don't have access, then just return the access denied page.

Step 7: Deliver the page

And finally, the work of the router is done, and we can just hand the work off to the callback assigned to this path.

$default_delivery_callback = (isset($router_item) && $router_item) ? $router_item['delivery_callback'] : NULL; drupal_deliver_page($page_callback_result, $default_delivery_callback);

Pretty, right? Yeah, not so much, but it definitely gets the job done.

What about (re)building the menu router?

I mentioned earlier that we'd talk about how the menu router gets assembled in the first place. In other words, what exactly happens in the oh-so-scary menu_rebuild() function that takes forever to run?

Well, it all happens in 3 simple steps.

list($menu, $masks) = menu_router_build(); _menu_router_save($menu, $masks); _menu_navigation_links_rebuild($menu);

Let's take it one by one.

Gather the router items

The menu_router_build() function basically calls all hook_menu() implementations and builds a giant array out of them.

This is actually an incredibly scary process. Don't be fooled by how simple menu_router_build() looks; the magic really happens in _menu_router_build() (underscore functions strike again!). Take a look at that one to see what I mean.

I won't go into much detail about what happens there, but the gist is that it takes the info provided to it by various hook_menu() implementations and figures out everything else that the menu_router table wants to store. That includes things like figuring out what the load_function should be based on named placeholders, figuring out if any given link exists in a custom navigation menu, inheriting access callbacks and page callbacks from parent paths if not explicitly defined, etc.

The end result is that we have all of the data given to us by all of the hook_menu() implementations, and it's in a format that menu_router will play nicely with.

Save the router items

Finally, an easy one. The _menu_router_save() function basically just does a giant db_insert() into the menu_router table for each menu item returned by menu_router_build().

It executes in batches of 20 to find a balance between performance and memory overhead, but other than that, there's nothing really tricky happening.

Update the navigation menus

Since hook_menu() lets you place menu items in actual user facing navigation menus using the MENU_NORMAL_ITEM type and the optional menu_name key, we need to actually do the work of putting those items into navigation menus. This happens in _menu_navigation_links_rebuild.

This little guy handles a lot of tough work. For each menu router entry, it'll add it to the appropriate menu, or update it if it's already there, or move it from one menu to another if that changed, or delete it if needed.

It's also smart enough to remove any items from menus that don't have matching router items anymore (so you don't have orphan menu items), or which have changed types from MENU_NORMAL_ITEM to another type. And to top it all off, it deletes them from the bottom up, meaning it starts with the ones with the greatest depth, so that it doesn't have to do as much re-parenting as it would if it deleted them in the opposite or a random order.

When does this happen?

That's all well and good, but what would trigger this to happen? How does Drupal know when it's time to run rebuild the menu router?

Turns out that lots of things trigger that, but it's a bit complicated because there are two ways it can be triggered.

  1. The menu_rebuild() function can be called directly, of course.
  2. The menu_rebuild_needed variable can be set to TRUE which will trigger a call to menu_rebuild() the next time the menu_get_item() is called (see the Possibly rebuild the menu system section of this chapter to see how that happens).

There are a couple obvious things that trigger menu rebuilds. One of the most common is drupal_flush_all_caches() function. Besides being called whenever you manually flush caches (which is about 9000 times a day if you're anything like me), it also gets called by system_modules_submit() when enabling a new module, so that the module's hook_menu() or hook_menu_alter() implementations (or other menu related hooks) can be respected.

Besides that one, there are a few other places that call menu_rebuild() directly. Most notably:

As far as places which set the menu_rebuild_needed variable to TRUE, achieving the same effect, we have a couple notable ones:

Those are the big ones as far as core is concerned. If you search the standard Drupal site's codebase for menu_rebuild then you'll find a bunch more, but most of them belong to either contrib modules or automated test cases. Runtime core code does a relatively good job of only doing a full menu rebuild when it's absolutely necessary.

This is a chapter out of my in-progress book, Drupal Deconstructed. You can read it online for free, download it as a PDF/ePUB/MOBI, or contribute to it on GitHub.

Categories: Drupal

Realityloop: What to see at DrupalCon Barcelona

16 September 2015 - 2:27am
16 Sep Jarkko Oksanen

Everyone in Realityloop will be attending the DrupalCon at Barcelona this year. There is always a lot to see in Drupal events and I've listed the things that excite me the most this year.

1. The Sessions

The sessions build the core of Drupal events. The sessions will be held on Tuesday-Thursday. It's always difficult to find the best sessions to go to, and often the quality of the speaker overshadows the interest of the topic. However the topic is still how we often choose our sessions. These some examples of the great sessions that we can attend, and that interested me personally the most from each day based on the topics!

  1. Serving the Internet of Things (IoT) with Drupal (Tuesday 14.00)
  2. Configuration Management in Drupal 8 (Wednesday 17.00)
  3. 10,000 hours distributed, why being remote is the best way to run a team (Thursday 14.15)

As you can see from these three examples, the session topics will vary greatly. See the full list of sessions here.

2. Birds of a Feather sessions

BOFs are informal small sessions that are held "on-the-spot" and often include a lot more discussion and happen in smaller groups. If you didnt get a chance to talk about your topic, or there is no session that you're interested in, go join or start a BOF!

Read more on BOFs

3. The Sprints

Sprints are the coding and hands-on part of a DrupalCon. Get together to fix issues in your favorite modules, or just get help setting up your first Drupal website. It is a great way to start contributing code back to the community!

There is a lot of sprints at this years DrupalCon.

  1. 19-20 September - Extended Sprints
  2. 21-24 September - Sprints at the Barcelona International Convention Center
  3. 21-24 September - 24-hour Supporter Sponsored Sprint Lounge at the Princess Hotel
  4. 25 September - General Sprints, Mentored Core Sprint, and First-Time Sprinter Workshop at the Barcelona International Convention Center
  5. 26-27 September - Extended Sprints at Makers of Barcelona

See an updated schedule and locations here.

Check out our earlier blog post about Sprints and what they are.

4. Community Social Events

Meeting the people face-to-face you work with on is one of the more fun parts of a DrupalCon. You can see the person who developed the modules you're working on, and ask a question about why they did something in a weird way. There are some community events that you should not miss.

  1. First time attendee social
  2. iKOS + Lingotek: Beers at the Booth
  3. Trivia Night

You can find a more comprehensive list on the event website.

5. The city of Barcelona

When you're in a DrupalCon and your days are booked with great sessions and sprinting, it might be hard to allocate some time for sightseeing. But dedicating some time for that will make the trip much more worth it.

Go see Tibidabo.

Jarkko Oksanen (jOksanen)

drupal planetdrupalconbarcelona
Categories: Drupal

Drupal core announcements: Your turn to provide feedback on the Drupal 8 cycle!

16 September 2015 - 2:10am

Dries Buytaert, the Drupal project lead, will facilitate a Drupal 8 retrospective discussion at DrupalCon Barcelona.

After more than four years of development, Drupal 8 is quickly approaching its first release candidate. This will be a landmark release with myriad new features and improvements. In addition to many technical changes, we innovated on how we collaborate on the Drupal project itself as well as on We involved more than three times the contributors of Drupal 7. Now it's time to take stock of the cycle, of where we've been and how it went, so we can keep improving. We'd like your input on the following:

  1. What worked well? What were the highlights of the Drupal 8 cycle?
  2. What didn't work well? What are lessons we've learned for upcoming releases or for the community as a whole?
  3. What concrete improvements can we make for future releases (both minor and major)? We welcome suggestions around teams, tools, or processes.

Please submit your answers online. Dries will gather the community's responses and use them as the basis for the open discussion at DrupalCon Barcelona.

Categories: Drupal

Morpht: Creating custom templates in WYSIWYG

15 September 2015 - 4:30pm

Creating responsive websites is easy these days with frameworks like Zurb’s Foundation and Bootstrap. The WYSIWYG API template plugin module allows us to predefine templates in WYSIWYG, helping editors to layout content for a mobile friendly website.

Categories: Drupal

Mediacurrent: Introducing Drupal Through Its Community

15 September 2015 - 2:21pm

When you ask people, “What makes Drupal different?” you can expect a variety of answers. Many people are likely to point to its flexibility. The technically-minded might reference Drupal’s hook system or Entity API. One of the most common answers, however, will be one that many people new to Drupal will find unexpected when discussing software: the Drupal community.

Categories: Drupal

DrupalCon News: Coffee breaks at DrupalCon

15 September 2015 - 12:18pm

DrupalCon is almost here, which means it's time to discuss one of the most controversial topics in our community: coffee!

Categories: Drupal

OSTraining: How to Use Aggregation and Compression in Drupal

15 September 2015 - 11:47am

By default, the Drupal 7 core loads around 20 different CSS and Javascript files.

So, in order to make your Drupal site run quickly, it's essential to load those files as quickly as possible. It's easy to get started by enabling the aggregation and compression options in Drupal.

Aggregation gathers all the files together and loads them as one. Compression reduces the size of each individual file, stripping out unnecessary characters, whitespace and implementing CSS shortcuts.

In this video, Robert Ring shows you how enable Drupal's core aggregation and compression options:

Categories: Drupal

Acquia Developer Center Blog: 10 New Features in Drupal 8 Core

15 September 2015 - 11:17am
Steve Burge

If you're reading this post in the Acquia Developer Center, I'm guessing that you may have used Drupal before.

You might be familiar with Drupal 6 or 7, and with some of the modules that shipped with those Drupal versions.

But, Drupal 8 is coming later this year -- a completely re-written version of the platform. This newest version will include lots of new features.

Here's an introduction to 10 new features that will be exciting when you use Drupal for the first time.

Tags: acquia drupal planet
Categories: Drupal

OSTraining: Introducing the 5 New Fields in Drupal 8

15 September 2015 - 11:13am

The Drupal 8 core has far more features than the Drupal 7 core. Many popular contributed modules have been included in the core, including five field types.

Here are the 5 new fields in Drupal 8:

  • Date
  • Email
  • Link
  • Telephone
  • Reference
Categories: Drupal

Cheeky Monkey Media: Require JS, Grunt, Bower, Foundation and Drupal - Part 2

15 September 2015 - 9:13am

Welcome back. If you just found this, you might want to start with Part 1 before reading on.

Okay, now we’re going into our custom theme folder (that’s based off the STARTER foundation sub-theme. Check out Justin’s Blog post, on how to set that up.

So, now that you’ve got your custom sub-theme...

Categories: Drupal

Drupal @ Penn State: Purespeed: Cache bin backends

15 September 2015 - 8:06am

Drupal is fantastic at caching itself (I mean, you've gotta be with a code base this hefty).  Drupal 8 will see the dawn of render cache in core which is why most metrics you see of D8 are uncached (because it's basically cheating its so fast cached). If you want to play around with Render Cache in D7, it can be done but still needs some work ( actually runs Render Cache backport to handle comments in issue queues among other things).

Categories: Drupal Understanding Drupal Security Advisories: The Risk Calculator

15 September 2015 - 7:06am

Every Wednesday, the Drupal Security Team publishes "Security Advisories" (or SA's) to tell users about security vulnerabilities in Drupal core and contrib modules, with advice on how to solve the issue so that their site is secure.

This is the first in a series of articles about how to better understand all the information in a security advisory, so that you know how to take the appropriate action for your site!

Not all security vulnerabilities are equal!

Some are highly critical and require immediate action (like SA-CORE-2014-005, aka Drupalgeddon, was) or your site could be irrepairably damaged and you'll have to restore from backups.

And while you should take action on any security advisory that affects your site as soon as possible (or hire someone else to do it), some security vulnerabilities present less risk, so you might choose to delay updating and focus on more important things in your business or personal life.

But how do you make that decision?

All security advisories come with a "Security risk" that is generated by the Risk Calculator, which is where the labels like "Less Critical" or "Highly critical" come from.

However, those labels aren't very instructive because they don't really tell you want your at risk of. 

Each security advisory also includes the full set of values provided to the Risk Calculator - which contain a wealth of information about the vulnerability - you just need to know how to decode and understand it.

That's what this article is about!

Read more to learn how to understand the Risk Calculator used in Drupal Security Advisories!

Categories: Drupal

Drupalize.Me: Speed Up CasperJS Tests By Skipping Unnecessary HTTP Resources

15 September 2015 - 6:02am

You know all those JavaScript tracking codes that get added to the footer of every page on your site? Google Analytics is the classical example, but there are tons of others out there. They are slowing your pages down, which in turn slows down your test suite. In this post we'll look at how you can skip unnecessary resources when using CasperJS for testing.

Categories: Drupal

Dries Buytaert: How Acquia is addressing the explosion of sites

15 September 2015 - 2:50am

I believe that the "digitalization" of the world is a "megatrend" that will continue for decades. On the one hand, organizations are shifting their businesses online, often inventing new ways to do business. On the other hand, customers are expecting a better and smarter user experience online.

This has led to two important sub-trends: (1) the number of sites an organization is creating and managing is growing at a rapid clip, (2) so is the underlying complexity of each website.

Forrester Research recently surveyed large enterprises about their website portfolio and found that on average they manage 268 properties across various channels. On top of that, each website is becoming more and more advanced. They evolved from simple HTML pages to dynamic websites to digital experience platforms that need to integrate with many other business systems. The combination of these two trends -- increasing number of sites and the growing complexity of each site -- poses real challenges to most organizations.

At Acquia, we are seeing this explosion of websites in the enterprise every day. Many organizations have different websites for different brands and products, want different websites for each country or region they operate in, or offer separate portals for their affiliates, dealers, agents or franchises. We're also seeing organizations, small and large, operate a large number of marketing campaign websites. These organizations aren't focused on scaling back their online properties but rather how best to manage them over time.

I outlined this trend and its challenges almost five years ago (see Acquia product strategy and vision) and most of it is still relevant today, if not more relevant. In this blog post, I want to give you an update and share some lessons learned.

Current situation

Most larger organizations run many different types of websites. It's not unusual for a small organization to have ten websites and for a large organization to have hundreds of websites. Some of our largest customers operate thousands of websites.

Most organizations struggle to manage their growing portfolio of digital properties. It's not unusual that an organization has more than 25 different content management systems. Often this means that different teams are responsible for them and that they are hosted on different hosting environments. It is expensive, creates unnecessary security risks, poses governance challenges, leads to brand inconsistency, makes it difficult to create a unified customer experience, and more. It costs large organizations millions of dollars a year.

Drupal's unfair advantage

When managing many sites, Drupal has an unfair advantage in that it scales from simple to complex easily. That scalability, coupled with a vast ecosystem of modules, elevate Drupal from a single site point solution to a platform on which you can build almost any kind of site: a brand site, a corporate website, a customer support community, a commerce website, an intranet, etc. You name it.

This is in contrast to many of Drupal's competitors that are either point solutions (e.g. SharePoint is mainly used for intranets) or whose complexity and cost don't lend themselves to managing many sites (e.g. Adobe Experience Manager and Sitecore are expensive solutions for a quick marketing campaign site, while WordPress can be challenging for building complex websites). So the first thing people can do is to standardize on Drupal as a platform for all of their site needs.

By standardizing on Drupal, organizations can simplify training, reduce maintenance costs, streamline security, and optimize internal resources – all without sacrificing quality or requirements. Standardizing on Drupal certainly doesn't mean every single site needs to be on Drupal. Transitioning from 25 different systems to 3 still translates into dramatic cost savings.

The Acquia advantage

Once an organization decides to standardize on Drupal, the question is how best to manage all these sites? In 2013 we launched Acquia Cloud Site Factory (ACSF), a scalable enterprise-grade multi-site management platform that helps organizations to easily create, deploy, and govern all their sites. Today, some of Acquia's biggest customers use ACSF to manage hundreds of sites - in fact on average an ACSF customer is currently managing 170 websites within their Site Factory platform and that number is growing rapidly.

Acquia commissioned Forrester Research to analyze the benefits to organizations who have unified their sites on a single platform. Forrester found that moving to a single platform dramatically reduced site development and support costs, conserved IT and marketing resources, and improved standardization, governance, and scalability — all while accelerating time-to-market and the delivery of better digital experiences.

One of the things we've learned is that a complete multi-site management solution needs to include advanced tools for both developers and content managers. The following image illustrates the different layers of a complete multi-site management solution:

The different layers of the Acquia Cloud Site Factory solution stack.

Let's go through these individually from the bottom up.

Infrastructure management

Consider an organization that currently has 50 websites, and plans to add 10-15 more sites every year. With ACSF these sites run on a platform that is scalable, secure, and highly reliable. This infrastructure also allows hardware resources to be logically isolated based on the site's needs as well as scaled up or down to meet any ad-hoc traffic spikes. These capabilities enable organizations to simplify multi-site management efforts and eliminate operational headaches.

Code management

If this organization with 50 sites had individual codebases for each site, that would be 50 disparate codebases to manage. With ACSF, the underlying code can be shared and managed in one central place but the content, configuration, and creative look-and-feel can be catered to each individual sites' needs. ACSF also enable developers to easily add or remove features from their codebases for individual sites. ACSF also comes with tools to automate the process of rolling out updates across all their sites.

Site management

Organizations with many sites also need efficient ways to manage and govern them effectively; from developer tools such as Git, Travis, or Behat that enable them to build, test, and maintain sites, to tools for non-developers to quickly clone and spin up sites using site templates defined by a brand manager or a digital design team. ACSF enables customers to effortlessly manage all their sites from a single intuitive dashboard. Developers can create groups of users as well as sites allowing certain users to manage their dedicated domain of sites without stepping over other sites. Non-technical content managers can quickly spin up new sites by cloning existing ones they have access to and updating their configuration, content, and look-and-feel. These features allow organizations to launch sites at unprecedented speed inherently improving their overall time to market.

Content sharing

Write once, publish anywhere. We learned from customers managing multiple sites that one thing they often need is the ability to easily share content between sites. For example, if an organization has a privacy policy that needs to be updated, it doesn't make sense to update all their 50 sites individually. There needs to be an easier way to discover existing content that can be repurposed across other sites as well as the ability to author new content once within a platform and deliver it to other sites as needed.


Finally, I should mention personalization. For a few years now we have been developing Acquia Lift. Acquia Lift builds unified customer profiles across all your websites, and uses that information to deliver real-time, contextual, and personalized experiences. For instance, if the organization in the above example had 50 websites for each of their 50 different products, Acquia Lift can present relevant content to its users as they browse across these different sites. This enables organizations to convert anonymous site visitors into known customers and establish a meaningful engagement between them.


I believe that the "multi-sites era" will continue to accelerate; not only will we see more sites, but every site will become increasingly complex. Organizations need to think about how to efficiently manage their website portfolio. If you're not thinking ahead, you're falling behind.

Categories: Drupal

InternetDevels: Symfony2 console: tutorial for beginners

15 September 2015 - 12:55am

This tutorial should be useful for those who are interested in Symfony web development. In Symfony, there are many console commands to help you in your work. We will consider the most frequently used Symfony commands. For example, the cache cleaning command:

Read more
Categories: Drupal

about seo