Planet Drupal

Subscribe to Planet Drupal feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 18 min 23 sec ago

Hook 42: DrupalCon New Orleans Multilingual Training - Laissez Les Bon Temps Rouler!

Thu, 07/04/2016 - 20:00
Thursday, April 7, 2016 Hook 42 is ready to let the good times roll at DrupalCon in New Orleans, et vous?

Are you an agency who has multilingual clients, or do you want them?

Are you a themer, site builder, or developer who already works on multilingual sites?

Do YOU want to expand your knowledge base and skills so you can start building multilingual sites?

Have you heard the rumors that multilingual in D8 is easier than D7 and want to experience that first hand?

If you answered yes to any of the above questions, join us on Monday May 9th, for our Hands-On Drupal Multilingual for D7 and D8 Training!

The training will be led by Kristen Pol & Aimee Degnan, who literally wrote the books on multilingual in D7 & D8.

Now that you’re ready to laissez les bon temps rouler for you, your clients, and/or your site - here’s a brief overview of what we will cover during the training.

What Good Times Will Roll - aka Learning Objectives

You'll be learning a lot in one day! Here are some highlights:

  • Understand what Drupal components might need translations
  • Configure interface translations to be pulled from localize.drupal.org automatically
  • Pros and cons between node/content translation and field/entity translation
  • Configure entities (nodes, comments, users, etc.) for translations
  • Update views, site variables, and other configuration to support different languages
  • Drupal 8 site building exercises WITH multilingual support!  A great way to get introduced to Drupal 8!

Reaching audiences from different countries and with different language preferences can boost site conversions, improve user engagement, and create happier customers. Drupal is a go-to CMS for both small and large websites. But, until Drupal 8, building a multilingual site in Drupal has been quite challenging. In Drupal 7, it can take up to 20 core and community modules (or more!), lots of configuration, and often many patches from the issue queues to get a site prepped for multiple languages and translations. But have no fear!

For the first part of the day, we'll be following the Drupal 7 Multilingual Sites book which covers adding languages, configuring language negotiation, installing interface translations, configuring entities for translation, and more. For the second part of the day, we'll work with multilingual in Drupal 8 using the Drupal 8 Multilingual Sites book.

You'll get to bring the books and guided exercises home with you for reference when building your next multilingual site.

Make sure you sign up early to get the discounted rate and ensure the training happens. Don’t miss out completely by waiting too long!

Details of the Good Times

When The Good Times Roll: May 9, 2016 - 9:00am - 5:00pm

How Much The Good Times Cost: $450 early bird rate (through April 15), $500 regular rate - includes light breakfast, lunch and coffee breaks

I'm still thinking about the good times - I want a few more details

I'm ready to roll! Just sign me up!

Hook 42 Topics: Services:
Categories: Elsewhere

Axelerant Blog: 12 Reasons To Use Drupal In Higher Education

Thu, 07/04/2016 - 20:00

Using Drupal in higher education has been a popular choice among leading schools. It’s become the preferred website platform for hundreds of institutions of higher learning around the world. Schools like Harvard UniversityStanford Law SchoolDuke UniversityBrown UniversityRutgers UniversityUniversity of OxfordUniversity of Prince Edward IslandKarlstad UniversityZaman UniversityBentley UniversityUncommon SchoolsUniversity of Waterloo, and Yale have chosen Drupal as their preferred content management framework because it best supports current and future needs of students, faculty, alumni, and their communities.

In short, Drupal has proven these top schools that it serves higher education website needs. Here are ten specific reasons it’s best for your school.

The Top 12 Reasons To Use Drupal In Higher Education: 1. Multi-Site Functionality

Most universities and colleges maintain multi-faceted websites, ones that serve a broad range of purposes. By leveraging Drupal’s built-in multi-site functionality, institutions provide their departments with a substantial toolbox and relevant media types for communicating with students, staff, and other users via a single system.

This multi-site capability helps institutions break out independent websites by giving control and ownership to individual departments. This control structure significantly reduces administrative overhead from the IT office. SomeDrupal in higher education distributions like Open Atrium allow you to build intranets for any educational institution.

2. Easy Responsive Design Implementation

According to an eMarketer study, an estimated 90 percent of US college students will own a smartphone by the time they graduate in 2016. Now with Drupal 8, academic centers can easily use Drupal in higher education to stay up-to-date and relevant to users by delivering smoother, responsive website experiences out of the box.

Experiences from each user’s device of choice. Drupal sites adapt to user evolutions, making it optimal for institutions with student demographics. It’ll also be easier for admins to manage content with a dashboard (one that’s responsive and mobile ready out of the box as well).

3. Workflow Modules

Drupal’s Workflow modules and features set allow universities and colleges to control and manage the publication process actually, without limiting its use as a mere content management tool. There’s granular control available for every content operation.

At each step, employees can be notified to complete their tasks (like editing). This control keeps team members from performing tasks out of order and keep projects moving forward.

Looking for a partner?

4. Content & User Access Control

With Content and User Access Control, site administrators can create privileges grouped together by access level, function, and role. These permission sets can be assigned to groups of users rather than manually granting privileges to each and every user. Permission sets help decentralize task responsibilities like creating, editing, and managing content, all without putting extra workload on your IT hub.

These Drupal in higher education access control features are exceptionally handy on university websites where professors, students, alumni, and site visitors require unique user experiences and different access rights. The domain access module enables sharing content across multiple sites quickly, allowing site owners to share configuration settings and users among various college or university portals.

5. Multilingual Awesomeness

With Drupal 8 now available in over 110 languages, you can have your site available in almost any language that your student demographic needs. This feature allows decision makers to take into account: international student associations, global event communications, foci of studies, and more.

6. Efficient Use Of Taxonomy System

Drupal’s taxonomy system is a robust method for classifying website content into groups. Taxonomy systems can be designed and deployed on a per-content basis.

This system ensures extremely efficient content categorization on the site, resulting in ease of access for site visitors or users. Through taxonomy usage, only relevant content is delivered to site visitors; this avoids distractions and simplifies navigation.

7. Collaboration Modules

Apart from forward-facing content—static pages, forums, course schedules, blogs, and articles—Drupal provides powerful collaboration features and document management for back-end users. These systems are not typically part of the public front-end but are critical for faculty and students who require access to manuals, handbooks, procedural guides, and research documents. Because of its tools for collaboration, Drupal is a prime system for supporting internal teams and research for university and college websites.

8. Single Sign-On

Most every higher education institution has existing authentication systems for email or other internal accounts. With Drupal using LDAP and CAS, single sign-on for academic websites are easily doable. These single point access integrations result in a secure environment for users who want multiple resources and services via a single login.

9. Community Support for Drupal in Higher Education

IT movers and doers can connect with Drupal community groups around the world, and can easily search the issue queue for questions and answers related to institutes of higher education. Some community group examples are:

10. Social Media & Email Campaigns

Drupal’s integrated capabilities make engagement easier. From email marketing services like MailChimp, Constant Contact, etc. to higher ed social media campaigns launched via Twitter, Youtube, Pinterest modules, and more.

11. Drupal’s Multisite Approach

Multisite management needs are common for institutions of higher ed. Different departments or student initiatives often require sister domains. Drupal’s flexibility means effective content storage for each website. Sharing different site content can be done with the Domain Access module, allowing configuration, user, and content settings to be managed between or across sites.

12. 400+ Vendors With Experience With Drupal In Higher Education

Colleges and universities have many vendors to choose from. We’re in the top 10.

Want to see how well Drupal works for Higher Education? Check this out. jQuery(document).ready(function() { var custom_cta_viewed = false; jQuery(document).scroll(function() { if ( typeof ga !== 'undefined' && typeof isScrolledIntoViewPort !== 'undefined' && jQuery.isFunction( isScrolledIntoViewPort) && isScrolledIntoViewPort('.custom-cta') && custom_cta_viewed == false ) { custom_cta_viewed = true; ga('send', 'event', 'cta', 'view', 'suny-maritime-college-drupal-migration'); } }); });

Article originally published December 3, 2015, and has been updated.

This article 12 Reasons To Use Drupal In Higher Education by Parth Gohil first appeared on Axelerant - Axelerant: Expert Drupal Development, Support, & Staffing.

Categories: Elsewhere

nielsdefeyter.nl: I am getting excited about Drupal 8

Thu, 07/04/2016 - 17:54
Drupal 8 review from an experienced Drupal developer Pre Build 1st high-profile Drupal 8 website early 2016 Worked on lots Drupal 7 and Drupal 6 sites Contributed to rules-8.x Configuration management works All configuration is in-code now. A total break with earlier Drupal versions, where...
Categories: Elsewhere

CiviCRM Blog: TexasCamp 2016

Thu, 07/04/2016 - 15:40

This weekend the Skvare team attended TexasCamp, the first state-wide DrupalCamp! The Dallas conference attracted users and developers from all over the state to learn and network. Skvare showed community support with a Gold-level sponsorship. Since CiviCRM and Drupal work so well together, we shared some presentations that touched on the intersection of both.

   

Mark Hanna shared information on a new open-source online learning system powered by CiviCRM and Drupal. This week's release of Skvare's Tin Can compliant Learning Record Store is a Drupal-native API that expands Drupal capabilities for flexible, open-source Learning Management Software. This open-source solution can significantly lower the barrier to entry for organizations seeking to implement an online learning program.

   

 

View the video that goes with the slides below.

 

   

Feel free to play around with the alpha release of Tin Can Learning Record Store code and let us know what you think.

Kate Shaw presented an intro to CiviCRM as software for nonprofits, discussing use cases for managing membership, special events, and crowdfunding.

Peter Petrik shared information on hosting and performance improvements and Personal URL's.

Thank you to LevelTen Interactive for organizing and hosting, and to our fellow sponsors, Pantheon, Amazee Labs and Acquia.

 

 

If you'd like to learn more about CiviCRM, now's your chance

Register to win a free ticket to CiviCon 2016 by April 15. Sessions for CiviCon 2016 are taking shape. Whether you're new to CiviCRM or a seasoned user there is something for you at CiviCon Colorado 2016! If you’re an active user of CiviCRM but lack the resources to attend, here’s one barrier that’s been removed to help get you to Fort Collins this June. Head on over to our registration page to enter the drawing!

Drupal
Categories: Elsewhere

Amazee Labs: Weshalb Security wichtig ist - #PanamaPapers

Thu, 07/04/2016 - 12:36
Weshalb Security wichtig ist - #PanamaPapers

Jeder, der irgendwann einmal für die Sicherheit einer Website zuständig war oder ist weiss, wie schwierig und aufwendig diese Aufgabe ist. Es erscheinen fast täglich Security Updates für alle Services, welche die Website nutzt: das beginnt beim Linux Kernel, geht weiter mit dem Web Server bis hin zum Content Management System selbst, in unserem Fall Drupal.

Michael Schmid Thu, 04/07/2016 - 12:36

Jedes Mal, wenn ein neues Security Update erscheint, stellt sich die unvermeidliche Frage: Muss ich nun wirklich die Zeit investieren, um das Update einzuspielen oder kann ich einfach darauf hoffen, dass ich ungeschoren davonkomme?

Bei Amazee Labs ist die Antwort absolut klar und es gibt keine Ausreden: Security Patches werden so schnell wie möglich eingespielt!

Was passieren kann, wenn jemand seinen Security-Job nicht macht sieht man sehr schön (...) am Beispiel der #PanamaPapers.

Die Wahrscheinlichkeit, dass der Leak auch technische Gründe hat, ist gross; es gibt klare Zeichen dafür, dass sich niemand um Security Patches und ähnliches gekümmert hat und dass die Site deswegen angreifbar wurde.

Bis jetzt sind keine Details bekannt, wie genau die 2.4 TB Daten geleaked sind, aber es sieht sehr danach aus, als ob eine der Websites von Mossack Fonseca, nämlich https://portal.mossfon.com, gehacked wurde.

Ein Blick auf den Source Code dieser Website zeigt, dass sie mit Drupal 7 erstellt wurde.

Wir sehen auch, dass die CSS und JavaScript Files nicht aggregiert wurden; das ist übrigens nicht die beste Idee in Bezug auf die Performance, aber das ist eine andere Geschichte.

Wenn wir uns noch etwas weiter umsehen entdecken wir noch einige Unschönheiten.

Der Change Log zeigt auf, dass die Site immer noch auf der Drupal-Version 7.23 läuft. Das heisst, dass die Website seit mehr als 2 Jahren nicht mehr aktualisiert wurde; damit hat sie eine massive Sicherheitslücke – „Drupalgeddon“. Das bedeutet, dass man irgendwelchen PHP Code problemlos in die Site einspeisen kann.

Theoretisch wäre es möglich, dass die Site für Drupalgeddon gepatched wurde und dass nur die Versionsnummer im Changelog nicht geändert wurde. Aufgrund des generell schlechten Zustands der Site gehen wir aber nicht davon aus, dass dies der Fall ist.

Eine weitere Möglichkeit für Hacker wäre, sich Login-Daten der Site mit einer DROWN Attacke zu beschaffen. Eine DROWN Testsite zeigt, dass die Website dafür nicht geschützt war, als DROWN im Februar 2016 released wurde.

Vielleicht werden wir nie wissen, wie die Site genau angegriffen wurde, aber eines steht fest; nämlich, dass es passiert ist. Deswegen ist die wichtigste technische Erkenntnis für uns die Bestätigung, dass die Sicherheit einer Website essentiell und nicht zu vernachlässigen ist.

Genau deswegen brauchen wir bei Amazee Labs automatisierte Update Tools wie Drop Guard for Drupal und machen wöchentliche Sicherheits- und Wartungsarbeiten.

Categories: Elsewhere

Amazee Labs: Keep your website up-to date, security is key! #PanamaPapers

Thu, 07/04/2016 - 12:35
Keep your website up-to date, security is key! #PanamaPapers

Everybody who ever had to keep a website secure knows how hard this is: Almost every day there are updates for all the different services that run your website; starting from the Linux Kernel, to the web server, and the content management system, in our case Drupal, itself.

Michael Schmid Thu, 04/07/2016 - 12:35

And every time there is a new security update you ask yourself:  Should I take the time and install it or can I just hope that it will not hit me, because who would hack me?

At Amazee there’s only one answer: update and fix as fast as possible!

There’s a good (well…) example of what can happen if you don’t take your security job serious these days. The #PanamaPapers are all over the media across the globe: There’s a high chance that this data leak might have a tech aspect too, as there are strong indicators that the site security wasn’t maintained and that there are several vulnerabilities.

Currently the details of how the 2.4 TB of data exactly leaked are not public yet, but it is likely that the data might have been hacked from one of the company’s websites: https://portal.mossfon.com.

Let’s take a quick look at the source code of this site; we can see that it was built with Drupal 7.

What we can also see is that CSS and JavaScript files are not aggregated (that’s not a good performance practice by the way).

A deeper look into other files unveils more dangerous things.

The changelog shows that the Drupal version is still 7.23; this means that it’s older than 2 years and has a very bad security hole “Drupalgeddon”. This allows anybody to inject PHP code on the website.

It’s possible that the site itself is patched for this security hole and still has the version Drupal 7.23 in the changelog.txt, but from the general (bad) state of the site we assume that this is not the case.

It’s also possible that hackers were able to steal website login data via the DROWN attack. A DROWN attack test site shows that the site was vulnerable when DROWN was released in February 2016.

We might never know exactly how the data leaked, but it’s sure that it happened! Our key learning on the tech side is that security is very important and laziness can have very bad consequences.

That’s why we at Amazee Labs are using automated update tools like Drop Guard for Drupal and have weekly maintenance windows for all our servers and services.

Stay safe!

Categories: Elsewhere

Lullabot: Why Paid Drupal Modules Fail: Drupal as Art

Thu, 07/04/2016 - 10:23

Recently the Drupal Association announced accepted sessions for DrupalCon New Orleans. While it looks like we can expect another great DrupalCon (this will be my 7th straight North American DrupalCon), one particular session on the program about the sale of Drupal modules caught my attention. Although I have tried to stay focused on preparing my own sessions, I have had conversations with other people in the Drupal community about “paid modules” that have led me to the conclusion that confusion about this topic persists. So here I would like to offer a perspective on why these kinds of plans consistently fail. Specifically, I hope to expand the scope of this frequently discussed issue and suggest why so many paid module initiatives fail: the Drupal community protects its free software with the same vigor that other communities protect artistic freedom.

The GPL Protects Software Freedoms

Before offering my analysis, I should start by acknowledging the obvious reason why paid Drupal modules fail: the General Public License (GPL). The Drupal Association clearly states that “Drupal modules and themes are a derivative work of Drupal. If you distribute them, you must do so under the terms of the GPL version 2 or later.” Consequently, anyone who wishes to sell a Drupal module must provide the source code.

Drupal community members are standing by with their credit cards ready to purchase those modules – and then post the code to Drupal.org so that everyone else can use it. These principled individuals believe that copyleft provides a powerful tool for ensuring software freedom and will exercise their right guaranteed by the GPL that allows the recipient (buyer) “to copy, distribute or modify” the module or theme purchased. The seller “may not impose any further restrictions on the recipients’ exercise of the rights.” The GPL greatly curtails most plans to sell Drupal modules, and these would-be capitalists might have more success selling popsicles during a blizzard.

Yet the GPL does not close the debate on this subject. I have heard many reasons provided to justify revisiting this conversation, and most frequently they come down to money. Let me share some direct quotes used to justify the pursuit of a “Drupal Marketplace,” “paid Drupal apps,” or “paid modules”:

I have read and listened to a great deal of arguments defending these commercial endeavors, and I remain unconvinced that the potential upsides outweigh the considerable drawbacks.

A History of Failure

The words of the American literary critic Fredric Jameson influence my thinking on this topic: “always historicize!” A look at attempts to sell Drupal modules reveals a distinct lack of success, and yet people continue to claim they have found a solution. Consider SubHub, who announced in 2011 to great fanfare the “World’s First Drupal-Powered App Store.” They hoped to offer some of their “apps” at no cost, while other “apps” would require a small recurring charge. This plan failed and SubHub abandoned their initiative in 2013, lamenting the fact that the Drupal community “simply didn’t share the same motivation to make Drupal a highly commercial, competitive alternative to WordPress.” My apologies to anyone who built a Drupal site with integral SubHub functionality.

Also in 2011 – a big year for “apps” in the Drupal community – Phase2 announced the Open App Standard initiative. The title contains the word “open” so surely this plan would find traction with Drupal people, right? While Phase2 found some success with OpenPublic, which uses apps, I don’t see evidence that “apps” ever found traction in the Drupal community, and certainly not adoption with alacrity.

Keep in mind that many people make money selling Drupal services and that the community generally supports such efforts. I work at a company filled with people who make money building Drupal websites. Rather, I think this evidence shows that paid module schemes tend to fail, that others have found Drupal to be “actually a horrible solution to build apps,” and that when people ask the question, “Is a Drupal App Store a good idea?” the community generally responds with a decisive “no” (unless it features ponies). We absolutely want people to succeed in the community, just not by selling modules.

Certainly exceptions exist. For instance, some companies have found success selling Drupal themes. A case could be made that Acquia, a company founded by Drupal’s creator, peddles its own variety of “paid apps.” The Acquia Connector module “enhances the Drupal experience by providing the support and network services to operate a trouble-free Drupal website.” However, the module does little without an Acquia Subscription, which requires regular payments.

Acquia, and other similar services, get around the restrictions of the GPL by taking advantage of something known as the “application service provider (ASP) loophole.” When the Free Software Foundation published GPL version 2 (all Drupal code must be GPL version 2 or later) in 1991 we did not use web services like we do today. Because providing a subscription service (such as Mollom or New Relic) does not involve distributing software, Acquia need not provide any additional code than that which connects the site to the service.

The Drupal community could adopt a stronger copyleft license that closes the ASP loophole, such as the Affero General Public License (AGPL). Just do not expect this to happen anytime soon. Dries Buytaert, the founder and project lead of Drupal, built a business that takes advantage of this loophole and he made his opinion clear a decade ago in a blog post titled, “Long Live the Web Services Loophole.”

Consequently, the focus of the discussion around paid modules often revolves more around the merits and problems of what Richard Stallman calls “Service as a Software Substitute (SaaSS)” than on actually selling Drupal modules that address common challenges. While some companies have found success with the SaaSS model, why do so many others fail? To answer this question, we must look beyond code and licenses to the Drupal community.

Products and Practices

I wrote at length about the Drupal community in previous articles such as “The Cultural Construction of Drupal” and “Better, then Bigger: Cultivating the Drupal Community,” and I do not intend to re-hash those same ideas here. Rather, I would like to examine why “paid module” schemes have flopped.

As I see it, one fundamental explanation for failure has to do with when business people misunderstand Drupal as a product rather than an organic accumulation of practices, or more broadly, when they ignore the differences between machines and humans. I deliberately add the qualifier “business” to describe these people because all efforts to create paid products are intended to generate revenue. Efforts to sell Drupal modules, in the Marxist sense, epitomize efforts to create capital, to accumulate money – a goal that comes off as at odds with a community that values participation.

All modules that come with a fee are intended to generate revenue, but we must not forget that “free” modules (that are also “Free”) have the potential to do the same. Many people, including me, enjoy getting paid to write Drupal code. For the paid module argument to work, its defendant must demonstrate that existing models are somehow lacking. Defending a new commercial approach necessitates, in my view, demonstrating the unsatisfactory nature of a free software project with more than 33,000+ shared modules that has existed for more than 15 years and has a vibrant marketplace of vendors offering Drupal services. Such an argument not only requires a high level of mental gymnastics, it, at least tacitly, represents an affront to years of successful collaboration.

Because some of those recommending that Drupal re-evaluate its commercial ecosystem are contributing members of the community, I open myself up to the critique of constructing inaccurate divisions, pitting Drupal and its community against business people who desire to convert Drupal into a revenue-generating product. But we know too well that many of us in the Drupal community could represent either side. We aim to balance our need to support our families with our desire to defend Drupal and fight for its freedom. Luckily, we can often choose both.

Drupal as Art

Moving away from discussions of licenses and capitalist motives, I would now like to venture beyond the typical boundaries of the “paid module” discussion to explore why people feel so connected to Drupal. I get the sense that many people in the Drupal community do not actually understand the intricacies of the GPL and how it differs from other free software licenses such as the AGPL. I believe that the community is protecting something more ephemeral. Consequently, this part of my argument ventures into much more abstract topics and requires thinking about Drupal differently, less as a “technology” and more as an artistic practice.

I am not the first person to notice Drupal’s artistic side. For example, a DrupalCon session had the title “Zen and the Art of Drupal.” Someone else even created a new word, “Drupl’Art,” to describe “Drupal code that is both beautiful and artistic.” The conception of “Drupal as art” is not new, but I am going to be using it here in order to offer new insights into how the Drupal community works.

More than just a thought experiment, the idea of Drupal as art becomes useful when we position it within another long-running debate, namely the effect of technology on art. For instance, when proponents position technological advances as something that improves the lives of many, critics will sometimes note that those advances also threaten the purity of art – for example, photographs (the “new technology”) were seen as a threat to portraiture (“pure art”). Ironically, Drupal, as I construct it here plays the role of art, even as we cannot deny that most people would label Drupal “technology” well before they would ever call it “art.” And yet when members of the Drupal community react negatively to the suggestion of paid modules, it is not simply because of the GPL, it is because the community is defending its perceived “purity.”

Drupal and art have both been understood as pure expressions, deeply tied to their predecessors, consisting of ever changing practices, and driven by community. Yet it would be idle to suggest that concerns about the threat of technology to art are exactly the same as concerns about the effect of paid modules on Drupal’s ecosystem. Nonetheless, I believe that we can better understand the Drupal community’s typical allergic reaction to “paid modules” by interrogating previous debates about technology and art.

This line of reasoning follows a long history of thinkers who have conflated art and technology that goes at least as far back as Ancient Greece. The Greeks did not enjoy art for aesthetic reasons. The word “technology” refers to a “treatise on a practical art or craft” and its Greek root is techne. For the Greeks, techne also referred to art. Aristotle described techne as both practical knowledge and practical art. And what Drupal enthusiast would not admit that most websites convey practical knowledge?

In his 1954 essay, “The Question Concerning Technology,” the German philosopher Martin Heidegger variously described both art and technology as a “mode of revealing,” a way of “bringing forth.” A painting reveals another person’s point-of-view and a website “reveals” information. As uncomfortable as it may seem to some among us to describe Drupal as art, it helps explain why people feel so connected to Drupal and vigorously defend its purity. The community wants to work together and reveal its solutions rather than hide them behind a web service. Developers treasure not just revealing websites, but revealing (sharing) the code in the modules that enables their functionality.

Another well-regarded German philosopher, Walter Benjamin, provided valuable insights that are useful for our purposes in his 1936 essay, “The Work of Art in the Age of Its Technological Reproducibility.” Therein Benjamin explores when inventions such as photography and film (both being kinds of “mechanical reproduction”) “separated art from its basis in cult, the semblance of its autonomy disappeared forever.” Not only did these products threaten the group, they also threatened the group’s output (its art). He believed that “the unique value of the ‘authentic’ work of art always has its basis in ritual.” Likewise in the Drupal community we value ritual: we discuss issues, post patches, review the work of others, attend camps and cons, celebrate the accomplishments of new members, and create code with unique value – code that lives with other Drupal code on Drupal.org. Hiding code threatens our rituals.

Paid modules or services revoke our access, our autonomy, and our beloved practices. Drupal is something people do, and we cannot learn by doing when we cannot see the code. Products are purchased, while practices are lived. Drupal, like other forms of techne, is communication, and we cannot communicate in the same manners with black boxes as we can in the issue queue.

In addition to affecting what we do, the existence of paid modules could negatively affect perceptions of the Drupal community. Benjamin writes of a “decay of the aura,” which sounds much like what the Drupal community works against. While some may argue, as one Slate writer did, simply that “Drupal hates change,” many in the Drupal community still believe that Drupal exudes a sort of magical aura. We hold the community close to our hearts and defend its name. We do not half-heartedly promote our community, we instead speak of our “unique, diverse Drupal community,” say that “Drupal has made a big difference in my life,” and that “I’m truly proud to be part of this community.” We protect our people, practices, and reputation by following the Drupal Code of Conduct, in the hope that “we preserve the things that got us here.”

Our current system for creating modules on Drupal.org values the work of humans. Benjamin observes, “What matters is the way the orientation and aims of that technology differ from those of ours. Whereas the former made the maximum possible use of human beings, the latter reduces their use to the minimum.” Drupal is not so much the thing that is built but the way it is built by people. In fact, one of Lullabot’s most frequently quoted core values is “be human.”

The Drupal software will never be complete, and we hope the sharing continues indefinitely. In the same spirit, Benjamin believes, “It has always been one of the primary tasks of art to create a demand whose hour of full satisfaction has not yet come.” The Drupal community wants to continue building, to keep moving forward, never content that we have finally arrived at an “end” where our interactions have been replaced by web services.

Fredric Jameson once warned that “machines are indeed machines of reproduction rather than of production.” The Drupal community has produced a great deal of code that powers much of the web. Few among us would want to shift from production to reproduction, from working together to solve problems to purchasing solutions to problems. Repeatedly and continuously solving the sames problems – building the same websites – breeds boredom. We like to create new and shiny things, producing not reproducing. Our rituals, our process, and our freedom to tinker allows us to continuously move forward.

The Contrasting Case of WordPress

Even if these theories accurately describe the Drupal community, they do not fully account for the success of paid WordPress plugins. Do paid plugins make WordPress unpure, inhabited by a community of dispassionate contributors? Absolutely not. Does the availability of paid plugins somehow cheapen the WordPress community or imply that WordPress lacks meaningful rituals? Certainly no. WordPress powers a huge chunk of the web with GPL-licensed code. It would be fruitless to deny the overwhelming success of a project with a vibrant community. Rather, I hope to convey how the WordPress community’s embrace of paid plugins informs my argument that the Drupal community understands its practices as a kind of artistic expression.

Simply suggesting that WordPress and Drupal are different helps about as much as arguing that Drupal and WordPress are words that contain an incommensurable number of letters. We could go a step further, as Dries Buytaert often does and argue not only are they different, but that WordPress and Drupal target different markets, with “WordPress dominating the small business segment” and Drupal geared toward the “larger organizations with more complex requirements” (an idea I dispute). If that were true, one would think the community that caters to “large organizations” would have the customers with the funds to purchase modules rather than get them at no cost. Then again, the reverse argument seems equally defensible, and that small businesses would rather pay for plugins than for those reportedly expensive Drupal developers. None of these avenues feel satisfactory.

One might expect that WordPress and Drupal espouse contrasting ideas about paid add-ons and the GPL. Quite the contrary, the Wordpress.org licensing page provides clear guidance about how plugins should be licensed: “derivatives of WordPress,” including plugins and themes, “inherit the GPL license.” While they admit to “some legal grey area regarding what is considered a derivative work,” they “feel strongly that plugins and themes are derivative work and thus inherit the GPL license.” The community leaders back up their assertions with thoughtful discussion as well as expert analysis from the Software Freedom Law Center. The WordPress licensing page even provides a link to Drupal’s “excellent page on licensing as it applies to themes and modules (their word for plugins).” Thus, WordPress and Drupal provide almost exactly the same guidelines.

Remarkably, certain members of the WordPress community completely ignore the advice on the licensing page. They claim “the GPL FAQ has no legal validity.” Some sellers proudly declare, “got my own licensing terms” and others offer code with terms and conditions that make no mention of the GPL. Some explain the norm thusly: “Premium WordPress plugin and theme developers usually sell you a license key, which allows you access to support and automatic upgrades.” One store believes it takes advantage of GPL loopholes and sells plugins under a default split license ostensibly to “protect authors.” In other words, the WordPress.org plugin directory that lists over 40,000 plugins is not a comprehensive directory of WordPress plugins. If this sounds a bit like the Wild West, then you may be a Drupal developer.

If Drupal modules are about process, then WordPress plugins – at least a portion of them – are products. Members of the WordPress community write at length about the benefits of "premium products." Some stores offer plugins that are “guaranteed to work, always updated, top quality plugins. Beautifully coded, packed with features, and easy to use.” They offer “free trials.” Another store proudly trumpets its “professionally developed and supported options not found on WordPress.org.” Ventures of this nature are justified with such syllogisms as “‘free’ doesn’t make me rich.” Plugins like these are products, plain and simple, and clearly the WordPress community (“happy customers,” as one site put it) willingly pays.

In comparison, Drupal developers get modules from Drupal.org. More than just a “best practice,” this is the norm in the Drupal community. It keeps things simple, and has a practical benefit: acquiring a new module requires typing drush dl module-name.

Incidentally, another kind of software facilitates an analogous workflow: GNU/Linux. For example, to install software on my operating system, Debian, I type apt install package_name. I would never consider downloading software to my computer from some random website, let alone software that I could not inspect. For me, at least, these two processes (drush dl and apt get) feel nearly identical, and I could make a good argument that the Drupal community is more like the Debian community (i.e., that many of the commitments outlined the Debian Social Contract are lived in the Drupal community) than the WordPress community.

Once again, the words of Benjamin feel relevant: “It might be stated as a general formula that the technology of reproduction detaches the reproduced object from the sphere of tradition. By replicating the work many times over, it substitutes a mass existence for a unique existence.” App stores for paid plugins fragment traditions established on WordPress.org. The Drupal community, on the other hand, has decided not to purchase paid Drupal modules, not to depart from its tradition of keeping Drupal as close to 100% free as possible. Whenever this issue arises, the Drupal community votes with its voices and its wallets to favor practices over products, to reveal the modules it creates rather than conceal them behind paywalls, to work with – rather than sell to – each other. The fact that WordPress customers have chosen a different path reveals contrasting, not misplaced, priorities.

While it is difficult to generalize a community with more than a million users (or at least user accounts), Holly Ross, Executive Director of the Drupal Association, believes “the one thing we all have in common is that we care about the fate of Drupal.” It might be fate that someday paid modules will find success in the Drupal community, and that would not necessarily be wrong. It would mean, however that the essence of Drupal has changed. That may even signal the end of Drupal. But history suggests that day will not soon come. Until then, the Drupal community will continue to defend its practices. It will band together to resist paid module schemes, treat its software with a reverence that others reserve for works of art, share code, and encourage others to do the same.

Works Cited

Benjamin, Walter. The Work of Art in the Age of Its Technological Reproducibility, and Other Writings on Media. Edited by Michael W. Jennings, Brigid Doherty, and Thomas Y. Levin. Cambridge, Mass: Belknap Press, 2008.

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

Jameson, Fredric. The Political Unconscious: Narrative as a Socially Symbolic Act. Cornell University Press, 1982.

Jameson, Fredric. Postmodernism, or, The Cultural Logic of Late Capitalism. Duke University Press, 1992.

Categories: Elsewhere

Drupalize.Me: In the Community: Migrate, Documentation and Events

Thu, 07/04/2016 - 09:53

So far, 2016 has been a great year for Drupal and Drupalize.Me. We started off as our own company, and we’ve been heads-down on lots of new Drupal 8 tutorials. We have a deep love for Drupal and the community around here—so in addition to working hard at our business, we encourage each other to roll up our sleeves in the wider community as well. Here’s a little rundown of what’s been on our team’s radar recently.

Categories: Elsewhere

PreviousNext: Handling Errors in Complex Drupal Form Validation

Thu, 07/04/2016 - 07:25

Recently, I have been working on a site which has a big mutli-step form which is using a lot of custom form elements, custom auto-completes, custom form api states and ajax based sub-forms. It is all built using Drupal form api. The best thing about this form is that all the fields and sub-forms map to a data model. This gives us the benefit of validating the form fields using the Symfony validation component. This is good because we can write all the validation separately and test it using phpunit without bootstrapping Drupal. To convert this data model into form fields we wrote a form factory and connected it all together using the service container module.

Whenever you are working with complex multistep forms and updating a sub-form based on user input then you can't exactly show the form errors in the order in which the fields appeared on the form. In this post I'll explain a process in which we can achieve just that - keeping the form error messages in the same order as the form fields.

Categories: Elsewhere

Chapter Three: Drupal to Drupal 8 via Migrate API

Thu, 07/04/2016 - 00:12

Most of us already familiar with the Migrate module in previous versions of Drupal and I personally have been using it for several years to perform content migrations from different CMS's into Drupal. Migrate module is now part of Drupal 8 core which supposed to make it much easier to use. Unfortunatley this is not 100% true and in order to perform content migration you have to install several additional contrib modules. As of today there is no way to run migrations through interface as it was possible in Drupal 6 or 7 (and personally I don't think you really need the UI).



In order to be able to run migrations in command line you will need to install the following modules:

Categories: Elsewhere

Drupal @ Penn State: The Care and Feeding of Your Website

Thu, 07/04/2016 - 00:06

A question on the PSU DUG Slack channel got me thinking. How is it that websites are still being constructed at Penn State without any thought being put in as to how its is going to be maintained? Or by whom?  

To be clear, I am not talking about content creation or maintenance, but maintaining the code/server/DB/etc. that supports or runs the site? Or to develop new features and functionality, going beyond just updating code or applying security patches. Of course, this is not restricted to Drupal development - there are many other examples.

Categories: Elsewhere

Drupal @ Penn State: Pulling Git repo content into Drupal

Thu, 07/04/2016 - 00:06

The ELMS Learning Network team is seeking to not only transform education, but also the concept of content and how you can interact with a CMS. By taking our network based approach to educational delivery to Drupal, and viewing Drupal as more of an engine connecting people rather then a product out of the box, we can craft innovative solutions (like this one).

Categories: Elsewhere

Drupal.org frontpage posts for the Drupal planet: Drupal 8.1.0 RC1 is available for testing

Wed, 06/04/2016 - 23:46

The first release candidate for the upcoming Drupal 8.1.0 release is now available for testing. With Drupal 8, we made major changes in our release process, adopting semantic versioning and scheduled releases. This allows us to make significant improvements to Drupal 8 in a timely fashion while still providing backwards compatibility. Drupal 8.1.0 will be the first such update, expected to be released April 20.

Download Drupal-8.1.0-rc1

8.1.x includes an experimental user interface for migrating from Drupal 6 and 7, the BigPipe module for increasing perceived site performance, and more. You can read a detailed list of improvements in the announcements of beta1 and beta2.

What does this mean to me?
For Drupal 8 site owners

The final bugfix release of 8.0.x has been released. 8.0.x will receive no further releases following 8.1.0, and sites should prepare to update from 8.0.x to 8.1.x in order to continue getting bug and security fixes. Use update.php to update your 8.0.x sites to the 8.1.x series, just as you would to update from (e.g.) 8.0.4 to 8.0.5. You can use this release candidate to test the update. (Always back up your data before updating sites, and do not test updates in production.)

For module and theme authors

Drupal 8.1.x is backwards-compatible with 8.0.x. However, it does include internal API changes and API changes to experimental modules, so some minor updates may be required. Review the change records for 8.1.x, and test modules and themes with the release candidate now.

For translators

Some text changes were made since Drupal 8.0.0. Localize.drupal.org automatically offers these new and modified strings for translation. Strings are frozen with the release candidate, so translators can now update translations.

For core developers

All outstanding issues filed against 8.0.x are automatically migrated to 8.1.x after the final 8.0.x patch release. Future bug reports should be targeted against the 8.1.x branch. 8.2.x will remain open for new development during the 8.1.x release candidate phase. For more information, see the release candidate phase announcement.

Your bug reports help make Drupal better!

Release candidates are a chance to identify bugs for the upcoming release, so help us by searching the issue queue for any bugs you find, and filing a new issue if your bug has not been reported yet.

Note that there are known issues with the experimental Migrate module suite, especially the incomplete Drupal 7 to Drupal 8 migration path. If the bug you find is not covered by one of these issues, your detailed bug report with steps to reproduce is a big help!

Front page news: Planet DrupalDrupal version: Drupal 8.x
Categories: Elsewhere

Acquia Developer Center Blog: Use Drush to Sync Your Drupal Installations Between Multiple Environments

Wed, 06/04/2016 - 22:39

Note: This is an updated version of a blog post originally published by Promet Source. Moshe Weitzman contributed to this post.

One of main draws to Drush is the library's ability to make developer's lives easier. There are two simple commands that work using Drush aliases that can help sync database and files between multiple Drupal instances. First, we'll go over setting up an alias file for Drush. After that, we'll document the usage of Drush's sql-sync and rsync commands.

Tags: acquia drupal planet
Categories: Elsewhere

Promet Source: How to Download and Install the AMP Module on Drupal 7 Sites

Wed, 06/04/2016 - 21:41
Accelerated Mobile Pages (AMP) in Drupal 

 

Google’s search ranking algorithm was updated in 2015 to reflect a critical factor in user experience: mobile accessibility. More than half of all searches in major markets such as the U.S. and Japan happen on mobile devices, so Google began ranking webpage results with mobile layout and design higher than non-mobile pages to give their users the best possible experience. 

Now there’s a way to enhance the user experience for mobile devices without having to completely redesign a site. This method is convenient for publishers and it’s built on existing HTML standards. Site owners who want to provide users a good experience on mobile devices can now serve pages in the accelerated mobile page, or AMP, standard. Google designed the AMP standard and open-sourced the project in 2015. Drupal siteowners can download and install the AMP module for Drupal 7 and Drupal 8.  

This post covers the process of downloading, installing and configuring the AMP module for a Drupal 7 site. 

 

Categories: Elsewhere

Jeff Geerling's Blog: Drupal VM - DrupalEasy Podcast and DrupalCon NOLA BoF

Wed, 06/04/2016 - 21:19

As Drupal VM has passed 500 stars on GitHub, and is becoming a fairly mature environment for local development environment—especially for teams of Drupal developers who want to maintain consistency and flexibility when developing many sites, I've been working to get more stable releases, better documentation, and a more focused feature set.

Also, in the past few months, as interest has surged, I've even had the opportunity to talk about all things Drupal VM on the DrupalEasy podcast! Check out DrupalEasy Podcast 172 - The Coup (Jeff Geerling - Drupal VM), which was just posted a few days ago.

And to keep the conversation flowing, I'm going to be moderating a BoF on Drupal VM at DrupalCon New Orleans, Drupal VM and local Drupal development for teams.

Categories: Elsewhere

LevelTen Interactive: TexasCamp 2016: A DrupalCamp Hangover

Wed, 06/04/2016 - 20:44

If you were at the first-ever statewide DrupalCamp in Texas this weekend, that's awesome! As part of the team that helped organize this camp, I loved what we were able to accomplish. We organized TexasCamp to bring together the Drupal community from all over the state of Texas to teach, learn, connect, and collaborate.

It was all Drupal everything, especially in the week leading up to the event! As part of the team, we spent months of planning and finding the right venue (only to have to change it a month before the camp). The logistics that went into planning an event this large...Read more

Categories: Elsewhere

Drop Guard: Drupalgeddon strikes back: outdated Drupal allegedly linked to "Panama Papers"

Wed, 06/04/2016 - 20:35
Drupalgeddon strikes back: outdated Drupal allegedly linked to "Panama Papers" Igor Kandyba Wed, 06.04.2016 - 20:35

Drupalgeddon vulnerability, also known as SA-CORE-2014-005 affected millions of websites back in 2014 and we believe it started a new era for the Drupal community. It became apparent that if you don't want to put your website or business to a huge risk it's not enough to check for its status once a month, or even once a day - you should be continuously and tirelessly be scanning all available sources of information for potential security vulnerabilities in your code, being prepared to take immediate action.

Security Drupal Planet
Categories: Elsewhere

Four Kitchens: Trip Report: Stanford DrupalCamp 2016

Wed, 06/04/2016 - 18:35

I always enjoy going to Stanford for the annual DrupalCamp, and this year was no exception. Here are some takeaways from a few of the sessions I enjoyed this past Saturday. …

Categories: Elsewhere

Pages