Planet Drupal

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

Zivtech: Permissions and roles for happier users and admins

Tue, 18/08/2015 - 13:30

When you first install Drupal, you are given a lot of power. With all of the contributed modules available, you can do pretty much anything. You can also horribly mangle your site security, make your users hate having to use your site, and end up having to redo work from inexperienced users trying to (ahem) "help." So let's talk about users, permissions, and roles, and how you can use them to keep your Drupal installation merrily un-borked. If you've already been through adding roles and permissions once or twice, you should feel free to skip over the how-to's, and focus on the best practice sections.

 

One special user: the superadministrator who bypasses normal permissions checks

There is one extra-special user that everyone who has installed Drupal is familiar with: The Superadministrator. Drupal comes with exactly one superadministrator out of the box with a user id of 1. This user is usually named something like admin or root, and bypasses normal permissions checks. When you install Drupal, you are automatically logged in as the superadministrator.

Best practice

You should not be using this user for your day-to-day site maintenance unless you can guarantee that you will never make a mistake (in other words, you really shouldn’t be using this account for day-to-day tasks). Instead, make yourself another login that you use for mundane tasks like creating content, and then use the admin account for the rarer tasks, such as changing the site name. However, you SHOULD be using this user to start administrating roles and permissions as no other role will have that ability until the superuser grants it. 

Best practice

If you work in a team, don't use your personal email for the superadministrator. Use an email that all developers have access to, such as sysadmin@example.com or dev@example.com.

 

The principle of least privilege

For everyone else, we will rely on the User->Role->Permissions model. The principle of least privilege states that you want your users to be able to do their jobs on the site, but not anything more (definitely check out that page if you are unfamiliar with the finer points of this idea). First off, this prevents anyone who steals an account from being able to do too much damage ("Muhuwahaha, I will now commence commenting - UNMODERATED!"). Secondly, your site is guaranteed to have at least a few careless or inexperienced users, and minimizing access can prevent accidental data loss too (“oops! I thought it was ok to delete that /node view!”). You can easily use Drupal's roles and permissions system to implement this concept. 

Think of the relationships between users, roles, and permissions as the relationship between people, jobs, and tools. The user/people analogy should be pretty obvious and trivial, but I should mention that each person should have their own account and login or the model will begin to break down as you figure out how your users specialize. A role/job is a title given to a user/person that allows them to perform certain tasks. And a permission/tool is granted to a role/job so that a user/person can complete those tasks.

Best practice

Each user should have their own account, so that you can add permissions to each user individually instead of granting privileges to a single account that may not always apply to everyone who has access to it.

Best practice

Map out the people, jobs, and tasks that need to be done before applying any roles or permissions. Once you become familiar with the process, you will be capable of doing this quickly in your head, but in the meantime, map it out on paper. Add it to your site documentation too so that everyone on your team knows what each role is about, such as the following:

  • Commenter: A trusted user who is allowed to post comments without moderation.
  • Blogger: A user who can create blog posts.
  • Content manager: An editor who can create basic pages around the site, edit other people’s blog posts, and moderate comments.
  • Site builder: A user who can perform light site maintenance such as adding items to the menu, editing views, and administering blocks.

 

Permissions

Permissions are the tools that your users will use on a day-to-day basis. Generally, most permissions are positive: they grant users the ability to do a task but rarely take away the ability to do anything (we'll ignore those rare cases for the purposes of this blog post). Some common permissions: 

  • Administer blocks
  • Administer comments and comment settings
  • Post comments
  • Use the filtered text format
  • Use the full HTML text format
  • Administer menus and menu items
  • View published content
  • Article: Create new content
  • Article: Edit any content
  • Create and edit URL aliases
  • Administer modules
  • Use the site in maintenance mode

You can edit permissions for your site at example.com/admin/people/permissions. Notice that you only have two roles when you first create your installation: authenticated users and anonymous users. We'll get into adding roles shortly, but until then, think of these roles as two different types of users: authenticated users are people who are logged into your site, while anonymous users are not. Let's say you want both roles to be able to view comments, but only authenticated users will be able to post comments (which is a reasonable industry standard). You would edit the permissions to look like this (note that two different roles can share the same permission): 


When an authenticated user visits your site, they will see the form to add a comment, but the anonymous user will not. Both users will be able to see all comments.

You can go through the rest of the options in the permissions list on your own, but soon you will need some permissions that only apply to SOME of your logged-in users. 

 

Roles

To give certain logged-in users different permissions, you will need to create some new roles. Going back to the people, jobs, and tools analogy, you will be creating new jobs and then assigning different tools to each one.

For example, imagine that you want bloggers to be able to create blog posts, edit their own blog posts, and delete their own blog posts. You would create a new role at example.com/admin/people/permissions/roles and then edit the permission for that role. You don't want every blogger to be able to edit other people's blog posts, create views, or change the site name, so if I want to give those permissions to a user, I will need to grant them the appropriate role (moderater, site builder, administrator). The number of roles any site can use is unlimited, but here are some typical roles:

Any user can have more than one role. There's no reason that a user who is a site moderator should not also be able to comment, so it's perfectly normal to give a user two roles: moderator and commenter. 

With all this freedom, you may be wondering whether to create a role or add permissions to an existing role. Use the following guidelines to figure it out: 

Create a new role Add the permission to an existing role
  • This is a new permission for a new role ("we've hired a blogger!")
  • This is a new permission that will be shared among many different roles ("we've created a blog and all sales reps and developers can post to it!")
  • This is a new permission that will apply to only some members of a role ("we want some bloggers to be able to post without going through moderation!")
  • This is a new permission that expands one specific role ("we want all of our content moderators to be able to edit all these new blog posts!")
  • This is a new permission that applies to either anonymous or authenticated users ("we want everyone to be able to see our blog!")
Best practice

Unless you won't be available to do so in the near future, only grant users a role that they need right now. If a user thinks that MAYBE they would like to become a blogger SOMEDAY, then you can grant that role at a more appropriate time according to the principle of least privilege.

Best practice

To go back to the above analogy, you don't want to be giving all your chefs access to a dog-leash. Nothing good could come from that; save the leashes for the dog-walkers, and if a chef has also been trained as a dog walker, you can hire that person for two jobs instead of giving a leash to every chef. Similarly, make sure that your roles only have permission for the tasks they need to do. Instead of granting all bloggers moderation privileges, give the blogger than needs them the moderator role.

 

Adding roles to users

Now that the roles and permissions are set up, it's time to grant roles to users. If you only have a few users on your site, you can do this on a case-by-case basis by going to their user page and hitting the edit button.

If you have many users you want to grant roles to at the same time, you can use the people tab at example.com/admin/people. Select the users to grant the roles to, select "Change user roles" from the operations drop-down, and then click "Execute."

Revoking rules is the same process; unchecking a role from a user's edit page with withdraw those permissions from their account, or you can bulk remove roles in the same manner as above.

Depending on your version of Drupal (and how up-to-date it is), you may have to log a user out and then back in again to see role and permission changes. If you're on Drupal 7 (and if you're just starting a site today, you really should be), then you're good to go.

 

Testing permissions

This is the step that always gets me. I "know" how permissions work, I "know" that I set them up properly, and yet... I forgot to tick off a box somewhere and now someone can't do something that they need to do. So to finalize this walk through of best practices, the big one is to test all your hard (ok, pretty easy) work. Create a dummy user with the role you're testing (and ONLY the role you're testing), and then log in and try to do what you need to do. I like to use an incognito window so I don't have to log out of my administrator window to test.

If you can do the functions of the role that you have set up, then YOU ARE DONE. You now have a reasonably secure site, although there are always ways to get more secure. Happy Drupalin'!

Terms:
Categories: Elsewhere

Red Crackle: Object Oriented PHP

Tue, 18/08/2015 - 13:23
I am sure that by now you must have heard that Drupal 8 is using Symfony components and is based on object-oriented programming in PHP. If you are a Drupal 7 developer, then you may not know what is object-oriented programming or fail to understand the benefits it offers. In this series of posts, you will learn the basics of object-oriented PHP programming so that you can start developing for Drupal 8.
Categories: Elsewhere

Zyxware Technologies: [Drupal] How to draw shapes using Raphel JS in Drupal 7

Tue, 18/08/2015 - 12:20

While working on a Drupal project, I had to draw three concentric circles. Each circle was supposed to display the currently entered data in three text areas, called a golden circle. Using Raphael's JavaScript vector graphics library in Drupal 7 makes your work really simple. Please go through the following steps:

DrupalDrupal Planet
Categories: Elsewhere

DrupalCon News: Training Spotlight: Frontend Performance Training

Mon, 17/08/2015 - 23:20

Mobile device usage is surging as people use them to read content, shop online, and find information on the go. Users are proven to be happier and more willing to spend time and money on your site when it loads fast and responds quickly to their actions. Adding performance to the ever-growing list of project responsibilities can seem daunting, but it doesn't have to be.

In this full-day training, we will address every step in the process of improving frontend performance: auditing a site for problems, creating an effective solution, testing sites to ensure that the work was successful, and implementing automation tools that prevent regressions from creeping back into the codebase. Additionally, we will offer tools and suggestions to help your organization adopt a culture of performance, boosting its visibility in discussions and allowing your team to expose performance problems earlier in the development cycle, long before launch.

Categories: Elsewhere

Drupal Watchdog: Wait, $langcode? What the Heck?

Mon, 17/08/2015 - 23:00
Feature

Wait, $langcode? What the Heck?

If that was the most polite thought that crossed your mind when dealing with the Drupal 7 Field API, please read on.

No matter whether you build complex multilingual sites, or whether just hearing the words “Drupal” and “language” in the same sentence makes you want to hide in the darkest corner of your office, there are a few language-related notions that you really need to know to write Drupal 8 code that works properly. After all, language is an intrinsic property of textual content, and since Drupal is supposed to manage content, having to deal with language does not seem such a peregrine idea, does it?

Speaking of Content

Historically, content in Drupal is a user-friendly way to refer to nodes. However, in Drupal 8, content has a broader meaning: it refers to any entity type which stores information usually meant to be experienced in some form by a certain set of site users.

Content entities, such as nodes, comments, terms, custom blocks, custom menu links, and users, are all examples of this kind of entity type. The other main category is Configuration entities: node types, views, fields, menus, and roles, are meant to store information mainly related to determining the site behavior. Note that this distinction may not always be so clear-cut, as in some cases the choice of picking one category or the other may be determined mainly by implementation details, as in the case of module-provided menu links.

To sum up, when in Drupal 8 we speak of content, most of the time we are referring to content entity types.

Multilingual Content: A Bit of History

In Drupal 7, a new way of translating content was introduced by adding native multilingual support to the Field API. That allowed the ability to store multilingual values for any field attached to any entity type. But code that implements business logic needs to explicitly deal with field language, which implies a very poor developer experience (DX); i.e., this infamous field data structure:

Categories: Elsewhere

Red Crackle: Configure PHPStorm to debug Drupal 8

Mon, 17/08/2015 - 21:30
Devel module provides dsm() and dpm() functions to output variables on the page for debugging Drupal. But if the problem is more complicated, then that's not sufficient. You can simplify debugging tremendously if you stop code execution using breakpoints and then execute the application one step at a time. All IDEs that support PHP debugging, such as Eclipse, Netbeans, PHPStorm, etc., provide the functionality to put breakpoints in the code. But it requires quite a bit of configuration to make it work. In this post, you will learn how to configure PHPStorm 9 to debug Drupal 8. By the end of this article, you will be able to stop code execution in PHPStorm by putting a breakpoint.
Categories: Elsewhere

Four Kitchens: Rest Easy Part 3: Now Filter This

Mon, 17/08/2015 - 18:45

In the third installment of REST Easy, our RESTful module tutorial series, we’ll take a look at how to filter your API endpoints for results, a great feature that brings in the power of Entity Field Query for your APIs.

Categories: Elsewhere

SitePoint PHP Drupal: From Request to Response: A Journey into Drupal 8 Internals

Mon, 17/08/2015 - 18:00

In the first article on Drupal 8 module development we looked a bit at the routing aspect of this process. We’ve seen that creating pages with paths is now a matter of declaring routes that match up with controllers. The latter, as we’ve seen, can return a render array that gets interpreted into markup and displayed in the main content area of that page. However, did you know that under the hood, Drupal actually transforms that array into a Response object according to the dictates of Symfony’s HTTPKernelInterface?

In this article, I would like us to go deeper into the internals of Drupal 8 (and Symfony2) and look at what actually happens (and can happen) from the moment a request is made by a user to the one in which they see something returned in response. The example I mentioned above is just one direction this process can go in, and today we are also going to see other possibilities. The goal is to understand the flexibility of the system which in turn can help us build awesome applications.

Before going into it, I strongly recommend you check out this diagram which does an amazing job at synthesizing what is often referred to as the render pipeline. Though in my opinion it represents more than the name implies because the render system is only part of what’s depicted, albeit a big one.

Continue reading %From Request to Response: A Journey into Drupal 8 Internals%

Categories: Elsewhere

Annertech: 6 Reasons Why We Suggest Drupal to Our Clients

Mon, 17/08/2015 - 12:36
6 Reasons Why We Suggest Drupal to Our Clients

We recommend using Drupal as a content management system platform for our client projects for many reasons, not least of which is that it is a widely adopted, free, open source solution. Here are some of the strengths that we see our clients benefiting from when they use the Drupal content management system.

Categories: Elsewhere

Jim Birch: Using Fences and Page Manager to optimize HTML markup in Drupal 7

Mon, 17/08/2015 - 11:20

I have been searching for a way to make Drupal output cleaner, lighter, more semantic HTML since I started theming.  We all know Drupal core, and it's many contrib modules have a tendency to inject a couple-two-tree divs in 'dere.  I have tried many different ways, much to the chagrin of the developers I have worked with, most of them probably not worth the effort I put in.  That is until now!

The goal of my approach here is to minimize the markup that Drupal puts out, and gain complete control over the what and the where of the markup.  I can gain control of the fields using the Fences module; control over the templates in my theme; and gain even more control over the placement and what gets loaded using ctools Page Manager and Panels.  I will step through each of this in detail below.

Read more

Categories: Elsewhere

Imagine Creativity: Drupalaton 2015 : our perspective

Mon, 17/08/2015 - 09:49
17 Aug 2015

Last week we attended Drupalaton for the second year in a row. It was so valuable to us last year we couldn’t resist returning, especially after attending the great events Drupalaton & Drupal Dev Days Szeged last year. See our blog post from last year Drupalaton 2014.

What is Drupalaton?

It is a 4 day Drupal Camp which takes place on the edge of Lake Balaton, the largest lake in Central Europe. It started off as a group of 50 Hungarian Drupalers that knew each other quite well, as a Drupal Camp in the city of Pécs. After it grew the local community decided to move it to Balaton and change the name. After 1 year they decided to open it up to a much wider community, so in 2013 lots of attendees came from neighbouring countries.

Last year in 2014 there were 79 attendees from 13 countries including Belgium, France, Finland, Germany, Netherlands, Spain, Sweden, Switzerland, the UK. This year it was great to see us reach 115 attendees from a more diverse group of countries, many of which re-attending for years (including Pieter Frenssen).

What makes Drupalaton unique to other DrupalCamps?
  • Sessions - Longer, friendlier & more interactive.
  • Weather - At 35C during the trip it was great to make sure relaxation was had. Having the lake a few steps outside the hotel was very much welcomed.
  • Social activities - Morning jogs, group meals, evening drinks, boat party, grill party, swimming together on the lake, Go Karting.
  • People - The great weather and opportunities for socialising make it an amazing environment to make new and strengthen existing friendships. Some attendees brought their children who also made new friends!
The amazing organisers

We can’t say how much we appreciated all of the organisation effort that went into the event. The team was led by Tamás ‘York’ Pintér, with support from Zsófi Major, Gábor Reisinger, István Csáki. They are the real heroes of the event, and in addition to the months of organisation, they put in lots of additional time from early in the morning until the late night socials. They deserve a huge round of applause.

Extended sessions/talks

These were longer than usual 1 hour given at other Drupal Camps & Drupal Cons, but also in a workshop format. These were upto 3 hours in length, people had their laptops out on tables and were encouraged to ask the speakers questions as they went.

Boat party

This was a lot of fun and also a very good opportunity for attendees to exchange experiences and knowledge with eachother. There was tasty food, beer thanks to the fantastic sponsors. The boat journey was perfectly timed to give a view of an amazing sunset.

Grill party & the Drupalaton song

More tasty food followed, truly a feast which was much appreciated. Here some played poker with Druid's scrum cards and others played with the children, all before we were treated to a perfomance of the Drupalaton song. There were guitars and singing provided by Ruben Teijeiro, Gergely Csonka, Ernő Zsemlye & Tamás Hajas who gave us 'Drupal Get Commit' and the catchy chorus "We’re up all night to get a commit". YouTube video.

Fun games

5Net from Hungary gave puzzle pieces in everyone’s goodie bags which were used to create a giant jigsaw puzzle with the Drupalaton logo. REEA from Romania brought a unique game Crokinole, in which you slide pieces into circles and knock your opponents’ ones out, during which I won a t-shirt & mug after beating my opponent.

Family friendly

Lake Balaton is a popular holiday destination for the whole family which is one of the reasons many Drupal attendees brought their partners and children. It is very pleasing to see how happy everyone is and how much they interacted with the rest of us during the social time. It is good fun for the whole family and encourages them to all become friends with each other too. Perhaps in future events we could even have sessions for children, what do you think?

Drupal in Hungary

With famous Hungarian Drupalers including Gábor Hojtsy & chx , it was a different environment than you would normally see them in. I was very pleased to find out about how the Drupal community started to grow adoption in the country, especially in the early days.

Drupal in Central & Eastern Europe

Drupal companies in the area are keen to get away from the outside world seeing them as a cheap place to outsource to. They prefer to work on a partnership basis where you gain a relationship with team members, instead of ‘resources’. It is interesting to see that they are increasingly working on local client projects too. I was glad to see many friends again from the nearby countries of Serbia, Romania, Slovakia again from last year as well as other camps. For some local attendees Drupalaton has become an affordable alternative to DrupalCons as wages are generally a lot lower than in Western Europe. It will be exciting to see what happens with Drupal Iron Camp next year in Budapest, an event that aims to showcase the talent of the area and provide accessible Drupal training with low cost tickets.

Photos

Tamás ‘TeeCee’ Szügyi has perfected his art of photographing Drupal events with precision and was everywhere capturing it all. He has added photos to this Flickr group. If you have any photos please share them there too.

Next year

For 2016’s event the dates have been announced for 11-14th August. Hope to see you all at Drupalaton again next year!

Image - Top: Tags: DrupalDrupal CampDrupal Planet
Categories: Elsewhere

Chen Hui Jing: Drupal 101: Theming Drupal 7 with gulp

Sun, 16/08/2015 - 02:00

I still remember the first Drupal 7 theme I built. It was for the Singapore Gastric Cancer Consortium website, and at the time I barely knew my way around HTML and CSS. I used the Zen theme as my starter theme, and unknowingly wrote my CSS in .scss files without realising the distinction. I was a little bit confused to why I needed to install a software called Codekit to make everything work but was too busy trying to get the theme up and running to worry about it at the time.

Let’s talk about that thing called Sass

After I finished up with that project, I took the time to understand exactly what was going on....

Categories: Elsewhere

Steve Purkiss: Drupalaton Day Zero: Drupal 8 shipped - you didn’t miss the boat already?

Sat, 15/08/2015 - 23:49
Saturday, 15th August 2015Drupalaton Day Zero: Drupal 8 shipped - you didn’t miss the boat already? Shit.

“Shit, shit, shit!” exclaimed the guy sitting next to me, bashing his fingers away on his laptop in the reception area of Hotel Helikon, an ageing family summer fun destination perched on the southern shores of lovely lukewarm shallow Lake Balaton in Hungary where I had arrived a day early for the yearly Drupal event Drupalaton

You wouldn’t have noticed the extra sweat on my forehead in the sweltering 36 degrees heat, but these words made me nervous, for these weren't the words I was expecting to hear come from Daniel Wehner, the person who has the most commit mentions in Drupal 8. Had Drupal 8 broken horribly? Had some big problem just been found? No - well, not exactly. It was to do with supporting a beta-to-beta update path - more on that in a moment, for the moment let’s bring everyone up to speed.

Patch me in!

“But Steve, wait a code-damn minute there - what’s a ‘Commit mention in Drupal 8’ when it’s at home?" I hear some of you say! It means you were involved in some way in something that ended up being part of the core package of the next version of Drupal, version 8. What is Drupal? It’s a piece of software which currently powers over a million websites around the world. Everyone from those who accidentally became a Drupal developer whilst looking for a solution to help their tennis club to those in charge of running the United States use Drupal to communicate with their community via the web - see more examples over at this showcase of Drupal sites.

Drupal is a Free Software project (you may have heard it incorrectly referred to as 'Open Source'). This means anyone in the world is free to participate in the project - you can use it, study how it works, make changes, and share those changes if you want. A commit mention means you might have fixed a bug, reviewed some code, or been involved in some way with helping an issue move along the process until it has been deemed reviewed and tested by the community (“R.T.B.C.”) and thus ready to be committed to the codebase of the Drupal project. OK, now let’s get back to Hotel Helikon!

Getting on the Island

Later that evening after I’d unpacked and had a little wander around, I chatted with Daniel out on the island which, by daylight every inch of the hotel's small private enclave surrounded by the lukewarm shallow water of the lake is covered with holidaying families. Once a year, by night, the island becomes a hotbed of Drupal chat, especially this time as we are so tantilisingly close to release which has been worked on for four years now since the release of Drupal 7 in 2011.

“BDFL!” Daniel suddenly exclaimed. I thought for a moment - I didn’t recognise the acronym at first, thinking it may have been some internal subsystem only a few people knew as seemed the way with previous versions of Drupal to 8 which is now far more easier to approach using standard industry practices. This BDFL meant “Benevolent Dictator For Life”. It’s how the Drupal works currently, with that BDFL being founder of the project Dries Buytaert, whose own company Acquia recently announced that even though 8 wasn’t released and would be “ready when it’s ready”, they were ready to support customers who wanted to use Drupal 8. I guess this means they would value some kind of beta-to-beta upgrade path.

Grow the island communities

From the perspective of being one of the people who supports that upgrade path whilst also being asked every five milliseconds “When is Drupal 8 going to be ready?” I can imagine it’s probably quite stressful. Acquia aren’t the only ones of course, from a value perspective it means more adoption, certainly an easier life for me as I now partake in Brighton’s Homebrew Website Club to help keep the ball rolling on my migration of my own purkiss.com site to Drupal 8, although now I’ve thought of a few more pet projects I’d like to get up and running now I can actually base my efforts on the solid, well-thought-out foundation Drupal 8 provides me with.

Whatever the case, I leave my peers up to discuss and my readers to join in appropriately if they want. All I know is these decisions could be influenced by me if I wanted as it’s a Free Software project and if I cared enough about a certain topic I could get involved however I fit best and change it, not enough people understand or make use of those freedoms. Whilst Drupal is the largest community of contributors and over 3,000 people have commit mentions in Drupal 8, that’s a tiny proportion of those who use it, many whom make and create a lot of value and some of whom make a shed-ton of money out of it. Of course many more than just commit mentions make the community what it is, however the adoption rate at which Drupal has been taking that percentage is getting smaller every day.

An enormous amount of money comes back into the community in one way or another, but we are quite a way away from being able to simply visualise a piece of software in our minds and it suddenly spring up into existence in front of us without any human expense of effort. We may be able to one day do that - especially if we continue to freely innovate - but for the moment we have what we have, and every little piece takes human resources; at least until we replace them with running code.

As the Drupal project and community grows we need more people to be involved in building and supporting the very foundations which support us as a whole, and if that means rambling on in a lengthy, potentially edgy blog post in order to perhaps gain just one more person as a contributor then, until I am able to express myself in a better way, I’ll be doing that. I gained Daniel’s permission to blog about our discussions, I think it’s important to open up our processes deeply so people can see where they can potentially help out and become part of the thing we commonly refer to as Drupal.

As for the BDFL topic, I think it has obviously shown to work out well so far for Drupal, as for whether it’s a long-term solution well that’s also obvious to humans ;) Seriously though, I have no issues with the current situation until something proves me otherwise, I still believe we have a way to go before we are able to dissolve the fine leadership Dries provides to the community he has successfully fostered for the last fifteen-or-so years now.

Dries always seems open to discussion and is the most patient person I’ve ever met, certainly holds a role I would stress out in five minutes doing. I don’t see it working any differently for the moment at least - perhaps it would take a fork to even prove something like that. Forks are a Good Thing as they show in the long run what works and what doesn’t, providing the ultimate freedom of expression in an interdependent community such as Drupal.

Community ahoy!

As Daniel and I furthered discussion, he said something which resonated so much with me my virtual self almost shocked itself to spring into eternal existence. Sadly it didn’t, but it now has this quote emblazoned in its tiny, tiny virtual mind: “We should sell the community not the CMS.”

As an independent consultant who sometimes still writes code for certain things (only 8 commits in Drupal 8 so far though!) but works with people far better than himself in the community to deliver world-class software it’s something I’ve been doing but had not heard it in this simple, switch around way before. I invest in visiting the community and see what wonderful things they are building and his words to me, meant when you sell the CMS, you sell a product. There’s expectations put on that product often now knowing how those expectations will pan out. When you sell a community, you focus on promoting the people in that community, and as a Free Software community, provided you join in in some way, you too can benefit from the output.

Selling Freedom

Let’s just get the issues with the notion of selling Free Software - and people - out of the way. I’m not saying ‘Selling out’, just ‘selling’. Making a sale is an exchange of value between two or more parties, for example “you’ve sold it to me, I’ll use Drupal for my voluntary community project web enabled systems, thank you kindly!”.

It’s been working for me ever since I made the decision last year to not work through agencies after having to deal with yet another bad implementation of a CMS. Drupal is far greater than this, and so is my life. Since then I’ve had nothing but win/win/win results and although my cashflow has taken a dive as longer projects take time to bear fruit, it’s temporary one I'm almost out of and I’m kinda enjoying hacking on some bad code to pay the rent but even there I believe I’ve managed to turn the situation around and have an interesting offline mobile project in the pipeline. Along with the great work we’re doing with CRM (topic for another post!), it’s all about working together and supporting each other, and you don’t get that from talking about Drupal as a CMS.

As Simon Sinek says, start with the “Why?”.

As for did you miss the boat with Drupal 8? Not if you start now. Don’t wait for Drupal 8, in fact don’t use Drupal. Be part of it. Trust the community of peers and do what you can to help the project move along, and if you don’t know what that is then that is most likely a good place to start looking.

Is it that time already?

I didn’t imagine for a minute it would take this long to just describe day zero but I believe it’s of value, please do leave your thoughts in the comments below. In the next part I will move onto the workshops of the week, i.e. the ones I went to ;) This will cover why Drupal 8 Rules Configuration Management and Data Storage, manages client expectations with Behat, and why sometimes hospitals may seem a good prospect, but only if there’s air conditioning!

Oh, and a boat party and an outside grill with live music. It's not all serious talk on the shores of Lake Balaton you know ;)

tags: DrupalatonDrupal 8Planet DrupalDrupal Planet
Categories: Elsewhere

VM(doh): Building a Drupal 8 Website with Composer

Sat, 15/08/2015 - 15:00

One of the many Drupal-specific tools we've had in the past has been Drush Make. While Drush Make is still a valid tool for building Drupal 8 websites, I believe Drupal's adoption of Composer is one of the biggest wins in the Drupal 8 release cycle.

Composer is widely used across the PHP community for dependency management. In Drupal 7, it's been becoming more common for Drupal modules to rely on the Composer Manager module instead of the Libraries module to install and manage libraries that can be installed via Composer. Managing third-party dependencies with Libraries was often a pain point in the development workflow, and Composer Manager improved on that by letting us leverage Composer. However, that still created an extra step in building and deploying code in that you had to tell Drupal to rebuild Composer Manager's composer.json file when dependencies changed or were updated.

Only recently has Drupal's core composer.json been separated to only manage core and allow developers to manage the composer.json file in the root directory. There are two packages related to Drupal core - drupal/core and drupal/drupal. The former only installs Drupal core and it's dependencies, while the latter also provides the necessary framework (including index.php) for building a Drupal app.

To get started, we'll first need to create our project. Since the normal Drupal index.php and structure is fine in our case, we'll just create a drupal/drupal project.

composer create-project drupal/drupal my-drupal-8-app 8.0.0-beta12

Depending on your connection and your machine, creating the project may take a while.

After the project is created, you will want to update the composer.json file in the project root to use the Drupal Packagist repository so that you can use packages from Drupal.org. The Drupal Packagist project parses Drupal.org projects and provides a resource for Composer to download them. Of course, this is not necessary if none of the modules that you are using are not at the normal Packagist site, but odds are you will be wanting packages from Drupal.org. You'll also see that we added a couple of modules: OPcache (8.x version not being package on Drupal.org at the time of this post) and Panels.

{ "name": "drupal/drupal", "description": "Drupal is an open source content management platform powering millions of websites and applications.", "type": "project", "license": "GPL-2.0+", "require": { "composer/installers": "^1.0.20", "drupal/core": "~8.0", "drupal/opcache": "dev-8.x-1.x", "drupal/panels": "8.3.0-alpha12" }, "minimum-stability": "dev", "prefer-stable": true, "config": { "preferred-install": "dist", "autoloader-suffix": "Drupal8" }, "extra": { "_readme": [ "By default Drupal loads the autoloader from ./core/vendor/autoload.php.", "To change the autoloader you can edit ./autoload.php." ] }, "repositories": [ { "type": "composer", "url": "http://packagist.drupal-composer.org" } ] }

Next run "composer install". As you watch the installation, you'll notice that a library that was not specified (crunch/fastcgi) was also downloaded. This is a library required by the OPcache module to make direct connections to FastCGI servers for managing OPcache. This shows the real power of Drupal 8 leveraging Composer. You don't need Composer Manager to manage the third party code that your modules depend on. You don't need to go through the hassle of manually updating libraries managed by the Libraries module. All you need to do is run composer update in your project root.

You'll also notice that only the Panels module was specified, but it's dependencies (Page Manager and Layout plugin) were also downloaded. This is because Drupal Packagist parses the .info.yml files and provides those dependencies for you in a way that is compatible with Composer.

This is a huge win for DX in Drupal 8. All Drupal module developers whose modules rely on third party libraries that are installable via Composer should (must, in my opinion) include a composer.json file in their project.

Keep in mind that there are still a few issues with this process. Though Drupal currently maintains all of it's core dependencies in /core/vendor, Composer still goes out and downloads them to /vendor. That's not a huge deal because the autoloader loads the right files, but it can cause confusion in an IDE.

Relying on Drupal Packagist also creates yet another #DrupalWTF in my opinion. There is already a perfectly good service out there for managing Composer packages (Packagist). The only thing really holding the Drupal community back from using that is the lack of adoption of semantic versioning in contrib. Hopefully, that will change soon.

Categories: Elsewhere

DataSmith: [Fixed] Get valid RSS by adding CDATA wrappers to RSS description elements

Sat, 15/08/2015 - 12:19
[Fixed] Get valid RSS by adding CDATA wrappers to RSS description elements

A couple weeks ago, I posted about a problem I was having getting RSS to validate because the description element contained HTML markup.

The solution turned out to be as easy as I expected, once I found the right place to look. The first place I went was the Views module, where I found views-view-row-rss.html.twig in the templates directory. "Perfect", I thought, "that's my boy." A quick edit later, followed by a couple cache clears and some head-scratching, I still wasn't seeing my change.

Barrett Sat, 08/15/2015 - 10:19
Categories: Elsewhere

Drupal core announcements: This Month in Drupal Documentation - August 2015

Sat, 15/08/2015 - 06:51

It's been a busy month in Drupal documentation land. Here's an update from the Documentation Working Group (DocWG) on what has been happening in Drupal Documentation in the last month or so. Sorry... because this is posted in the Core group as well as Documentation, comments are disabled.

If you have comments or suggestions, please see the DocWG home page for how to contact us. Thanks!

Notable Documentation Updates

(pages or sections that have been worked on recently, see notes below)

See the DocWG home page for how to contact us, if you'd like to be listed here in our next post!

Thanks for contributing!

(list of how many people have made updates in the last month, and the top few contributors, see notes below)

Since July 15th (our previous TMIDD post), 234 contributors have made 705 total Drupal.org documentation page revisions, including 4 people that made more than 30 edits -- thanks everyone!

Extra big shout-out to these contributors.

  • lolandese (111 revisions)
  • Wim Leers (49 revisions)
  • jhodgdon (41 revisions)
  • Francewhoa (30 revisions)

In the core issue queue there's been a lot of movement to improve in-line documentation as we continue to get closer to a release of Drupal 8. This patch to improved the TypedData documentation is a great example of the kind of work that's being done. https://www.drupal.org/node/2548279

In addition, there were many many commits to Drupal Core and contributed projects that improved documentation -- these are hard to count, because many commits combine code and documentation -- but they are greatly appreciated too!

Documentation Priorities

The Current documentation priorities page is always a good place to look to figure out what to work on, and has been updated recently.

Work on the Drpual 8 User Guide is moving along splendidly. We had two IRC meetings in the last month and the level of involvement has been great. Helping with this documentation is a great way to get started with documentation and to learn a bit about Drupal 8 while you're at it. The focus right now is on writing a first draft of each of the topics in the guide, and work is also underway to figure out a final home for the new guide in https://www.drupal.org/node/2522024. Follow https://groups.drupal.org/documentation for announcements and join us for our next IRC meeting.

If you're new to contributing to documentation, these projects may seem a bit overwhelming -- so why not try out a New contributor task to get started?

The Drupal Association staff have recently updated their 2015 roadmap and it currently includes a couple of big wins for documentation. Including work to convert sections of the community documentation into a more maintainable format. The issue here https://www.drupal.org/node/2533684 doesn't have a lot of information soon, but keep on eye on it. And/or watch this recording of the presentation from DrupalCon LA about the work being done on content strategy for Drupal.org to get an idea of what's coming. https://events.drupal.org/losangeles2015/sessions/content-strategy-drupa...

Upcoming Events
  • DrupalCon Barcelona, Spain, 21-25 September, with a session Let's talk about documentation and a documentation sprint on Drupal 8 documentation and the D8 User Guide. Please sign up for the sprint! Members of the DocsWG will be in attendence at DrupalCon and would love to chat with you about your ideas for improving Drupal's documentation or to help you find ways to get involved so come say hello anytime during the week.

If you're attending or helping to organize a Drupal event that will feature a documentation related sprint, or sessions let us know and we'll get it added to the list.

Report from the Working Group

We just recently had our regular monthly meeting, though it had actually been over a month since the last time we met. We didn't have a whole lot to discuss in that period, and had been putting a lot of time and effort into getting the Drupal 8 User Guide project underway. At our last meeting the big thing that came up was the need to develop a clear set of guidelines for when it is appropriate to delete a comment from either the community documentation or the api.drupal.org documentation. https://www.drupal.org/node/2515002. We've jotted down some ideas and plan to discuss this further at our next meeting in September. Afer which we'll post the ideas we've come up with for consideration before making anything official. Let us know in the issue if you've got any thoughts about what this should look like.

Categories: Elsewhere

ActiveLAMP: Drupal 8 - First Experiences

Sat, 15/08/2015 - 01:00

I recently had time to install and take a look at Drupal 8. I am going to share my first take on Drupal 8 and some of the hang-ups that I came across. I read a few other blog posts that mentioned not to rely too heavily on one source for D8 documentation with the rapid changing pace of D8 the information has become outdated rather quickly.

Categories: Elsewhere

Sooper Drupal Themes: Module Spotlight #2: Environment Indicator

Fri, 14/08/2015 - 16:56
Configuration > System > Backup and Migrate > Restore database..... Did I just load my database export on the live website? oops

If the stress of pressing the wrong button on a live website is familiar to you, you need the Environment Indicator module! On large Drupal projects you will ...

Categories: Elsewhere

Drupal core announcements: Drupal core security release window on Wednesday, August 19

Fri, 14/08/2015 - 16:14
Start:  2015-08-19 (All day) America/New_York Online meeting (eg. IRC meeting) Organizers:  David_Rothstein

The monthly security release window for Drupal 6 and Drupal 7 core will take place on Wednesday, August 19.

This does not mean that a Drupal core security release will necessarily take place on that date for either the Drupal 6 or Drupal 7 branches, only that you should prepare to look out for one (and be ready to update your Drupal sites in the event that the Drupal security team decides to make a release).

There will be no bug fix/feature release on this date; the next window for a Drupal core bug fix/feature release is Wednesday, September 2.

For more information on Drupal core release windows, see the documentation on release timing and security releases, and the discussion that led to this policy being implemented.

Categories: Elsewhere

Pages