Planet Drupal

Subscribe to flux Planet Drupal
Drupal.org - aggregated feeds in category Planet Drupal
Mis à jour : il y a 49 min 59 sec

KnackForge: Add placeholder, Alter or hide image captcha title

mer, 19/08/2015 - 06:17

To add placeholder or alter the title, description and hide of the image captcha, do as follows

Use hook_form_FORM_ID_alter() and Form API pre_render function.

E.g:

/** * Implements hook_form_FORM_ID_alter() */ function MY_MODULE_OR_THEME_form_contact_site_form_alter(&$form, &$form_state, $form_id) { $form['#pre_render'][] = 'yourform_pre_render'; } function yourform_pre_render($element) {   if (isset($element['captcha']['captcha_widgets']['captcha_response']['#title'])) {     // change title $element['captcha']['captcha_widgets']['captcha_response']['#title'] = t('Change title name');  // placeholder add $element['captcha']['captcha_widgets']['captcha_response']['#attributes']['placeholder'] = $element['captcha']['captcha_widgets']['captcha_response']['#title'];  // empty title $element['captcha']['captcha_widgets']['captcha_response']['#title'] = ''; $element['my_captcha_element']['captcha_widgets']['captcha_response']['#description'] = "New Description"; } return $element; }

You can also use hook_form_alter() function:

Catégories: Elsewhere

Colan Schwartz: Get search results for compound words not in content with Drupal, Search API and Solr

mer, 19/08/2015 - 01:01
Topics: 

It is possible to expand compound search terms to multi-term synonyms. That is, if your Drupal site content contains text such as "dark room" or "key note", and you don't want your users to get No results pages on searches for "darkroom" or "keynote" (respectively), you'll need to do a bit of extra work to make this happen.

Let's assume we've got a Drupal 7 site working alongside Solr to provide the advanced back-end search functionality, and the Search API plus Search API Solr Search modules to integrate the two systems. At the time of this writing, this is a widely used best-practice approach. However, it doesn't natively support the above use case.

Some potential options for setting this up include spellchecking and fuzzy searching. But Solr itself already supports the use of synonyms even though the Search API does not. So let's tweak Search API's set-up to work with it.

There are several steps required to make this happen.
  1. If you're got the tokenizer enabled on your search index, disable it by unchecking the box over at Administration » Configuration » Search and metadata » Search API » Your index name » Filters » Processors » Tokenizer, and then save the configuration. If the Tokenizer option is enabled, it will prevent the synonym functionality from kicking in.
  2. Modify the Solr configuration in your search collection over at /path/to/solr/collection-name/conf/schema.xml around line 162.
    • Before:         <!-- in this example, we will only use synonyms at query time
              <filter class="solr.SynonymFilterFactory" synonyms="index_synonyms.txt" ignoreCase="true" expand="false"/>
              -->
    • After:         <filter class="solr.SynonymFilterFactory" synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
  3. Define multi-term synonyms in the synonyms.txt file that's in the same folder as the above schema.xml file. Follow the form here.
    • darkroom => dark room
    • keynote => key note
  4. Restart the search engine. This is system dependent, but if you're using the GlassFish application server for example, you may be able to restart Solr with a command like sudo service GlassFish_solr restart.
  5. Clear the search index and rebuild it.
    1. Surf to Administration » Configuration » Search and metadata » Search API » Your index name.
    2. Hit the "Queue all items for reindexing" button.
    3. Hit the "Index now" button.

That should do it. You're all set!

Background reading For more information on how all of this really works, here are some useful articles on the subject.

This article, Get search results for compound words not in content with Drupal, Search API and Solr, appeared first on the Colan Schwartz Consulting Services blog.

Catégories: Elsewhere

Shitiz Gag's Blog: [GSoC 2015: Hawk Authentication] Week 13: Final weeks

mar, 18/08/2015 - 20:21

GSoC is coming to a close, so these few weeks have been mostly about wrapping things up. This is good for me as well because college has taken a toll so I have less and less time to spend, but I believe I have enough to have the module at a good position before GSoC closes.

WWW-Authenticate

WWW-Authenticate is a HTTP header which is used to identify which protocols the server supports. If a server supports multiple WWW-Authenticate headers, it can send it multiple times to identify different protocols. For example: Drupal can send WWW-Authenticate: Hawk and WWW-Authenticate: Basic for identifying that it supports Hawk and Basic Auth. However, Drupal at the moment doesn’t have support for gathering and sending multiple header values from different modules due to the way it handles 401 Authentication Required exception. I will be working on allowing multiple protocols to send WWW-Authenticate so that multiple auth protocols can be identified at the same time.

Testing Hawk and Basic Auth together

I also spent a considerable amount testing these two protocols together, here is a summary of my findings but in summary: Both protocols work well individually but if a client sends requests containing both protocol’s headers at the same time it would cause either to fail due to the way HTTP protocol dictates concatenation of header values. HTTP recommends allowing only a single protocol in one request in order to have fewer points of failure so for the moment I believe this behaviour is fine, however if it is deemed beneficial to allow multiple protocols within same request it is always a possibility.

For now that is all, I’ll be dealing with WWW-Authenticate issue and documentation during my last week of GSoC.

Thank you for reading!

Catégories: Elsewhere

Drupal for Government: Virginia Physician API and Data Mining

mar, 18/08/2015 - 18:54

So recently we discovered http://data.virginia.gov/hhr and since we're looking to help people in Charlottesville I've added the data (thanks to feeds) and we added a couple of data mining points  https://www.cvillecouncil.us/va-physicians (using open layers)for the maps and h

Catégories: Elsewhere

benamer: Check out the Chartbeat Most Popular module

mar, 18/08/2015 - 18:30

You know those lists on a web site that you see from time to time listing the currently Most Popular articles on the site? I have to admit that I click on them from time to time to understand what is popular and why. It's a clear case of herd reading. Well, Drupal has a new module to create a Most Popular list on your site based on the Chartbeat Analytics API and it's written by myself and Darryl Norris. It's available on Drupal.org. 

Catégories: Elsewhere

Acquia Developer Center Blog: Avoiding Fuzzy Math When Load Testing

mar, 18/08/2015 - 17:42

No one likes fuzzy math. It’s especially problematic when you’re conducting a load test and can’t accurately gauge concurrency.

In this last blog of a series on load testing, here are some tips on how to avoid the fuzzy math that can distort your expectations of how a website will perform.

Shaky math can happen when using Apache JMeter, which is the most commonly used application to load test the performance of an open source site.

JMeter breaks it down into three categories: the number of threads that are happening at once, the ramp-up period from zero requests at a time to the max number, and the number of iterations. This typically is the way to determine expected concurrency: the total number of requests divided by average response times over how long you test.

There’s a problem with this method, though. When a site becomes overwhelmed, the response time actually increases, which means concurrency drops. So with such a test, you’re actually simulating the exact opposite of a normal site and not even close to seeing probable concurrency.

But there is a proper way to solve this, a way to get a true glimpse of possible concurrency – it’s something called throughput shaping. You can find it on jmeter-plugins.org. With this tool, you only have to simply say, “I want a thousand requests at once,” and it’s not only accurate but will save time that’s ordinarily lost on JMeter as you first try to figure out things like how many requests will hit your site at once.

Another speed bump to consider is how difficult it’s becoming to properly determine how many requests hit your site. That’s because not every every bot and not all of the “noise” on the Web crosses the path of Google Analytics and Omniture. Likewise, looking at the number of requests to your Web servers on Acquia Cloud, for example, doesn’t take into account if you’re using a CDM. (But if you are using a CDM, that’s the most likely source where you’ll have an accurate number.)

So here’s the last lesson of this series: Don’t extrapolate results. If you’re testing with 150 connections, don’t assume 300 will be exactly twice the number of resources required. Your test will tell you what 150 did. Load testing should be conducted in an environment that’s exactly the same size as what your production environment will be. Sure, it will cost a bit, but it will tell you how things will actually behave.

If your site faces contention – when many visitors simultaneously compete for your application’s attention – it will perform the exact same way if you have 150, 300 or even 600 connections. But the point is, you don’t actually know that; extrapolating results won’t provide an accurate number. Most often people look at the numbers, testing exactly to the numbers they have today. They’re missing more than just surges.

Consider must-visit websites for special events like sporting events and live award shows. They have one or two huge days of traffic a year, but the rest of the year, they’ll have a totally different number of visitors. So, when load testing, it’s not just a matter of looking at numbers. It’s understanding what those numbers actually mean and recognizing your end goal.

I recommend that once you have numbers, always test about 50% above that. Not necessarily because you’ll see that kind of traffic at launch, but if the site’s successful and growing over time, it’s rare that you’ll take the time to go back and run more load tests. By initially testing well above what you’re expecting, you’ll have a buffer and won’t have to worry about how the site is going to behave six months from now.

Hopefully this series has prompted you to think carefully about the nuances of load testing and will help as you prepare to launch a site. Load testing done right can help achieve optimal site performance. And, as I mentioned earlier in the series, your users define where load testing should take place, so you can’t go wrong. If you have any questions or suggestions, please drop a note in the comment box. Thanks for reading.

Blog series: Load Testing Your Drupal WebsiteWorkflow: PendingFeatured: NoTags: acquia drupal planetDrupal 8 related: NoAuthor: Erik Webb
Catégories: Elsewhere

Mediacurrent: Accessible Names - Label All the Things! (Part 1)

mar, 18/08/2015 - 17:24

The more we label things when building a website, the easier it is for a person who is blind and uses a screen reader to use our sites. These labels are known as the “accessible name properties” and they are baked into HTML.  

Catégories: Elsewhere

Imagine Creativity: <a href="/blog/what-drupal-intro-drupal-workshops-global-training-day">What is Drupal &amp; Intro to Drupal workshops - Global Training Day</a>

mar, 18/08/2015 - 17:16

We are happy to announce that we are running Drupal training sessions this month as part of the Global Training Days. The initiative is run by the Drupal Association to introduce new and beginner users to Drupal.

Come and join us on Friday 21st August to learn about what Drupal does and how it can help you. We will discuss the software and show you examples of it in action.

What is a Drupal Global Training Day?

Drupal Global Training Days is a worldwide initiative to increase the adoption of Drupal. All across the world, people are teaching and learning Drupal, and sharing that open source love.

Catégories: Elsewhere

Imagine Creativity: <a href="/blog/drupalaton-2015-our-perspective">Drupalaton 2015 : our perspective</a>

mar, 18/08/2015 - 17:16

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.

Catégories: Elsewhere

Imagine Creativity: <a href="/blog/drupal-camp-north-why-we-loved-it">Drupal Camp North : Why we loved it</a>

mar, 18/08/2015 - 17:16

This weekend we were very pleased to be able to attend the first Drupal Camp North in Sunderland. The great event took place at Sunderland Software Centre and was made possible thanks to them and Make It Sunderland.

Catégories: Elsewhere

Imagine Creativity: <a href="/blog/come-join-us-drupal-camp-london-2015">Come join us at Drupal Camp London 2015</a>

mar, 18/08/2015 - 17:16

There are only 3 weeks left until Drupal Camp London​ takes place (Fri 27 February - Sun 1 March). It will be hosted by City University London​ in Angel as it has for the past 2 years.

Whether you're a Drupal​ pro or just want to learn more, follow the link for weekend, business day and volunteer tickets.

Session submissions have now closed and are being selected for the schedule. In the meantime feel free to look at last year's site for an idea of what is on offer Drupal Camp London 2014

Drupal Camp London 2015

 

Catégories: Elsewhere

Imagine Creativity: <a href="/blog/drupalaton-2014-hungary-largest-lake-central-europe">Drupalaton 2014 in Hungary, at the largest lake in Central Europe</a>

mar, 18/08/2015 - 17:16

Wow my Hungarian friends - you have done it again! Two weeks ago, I spent a long weekend at Drupalaton, a Drupal camp in Hungary with the difference that it also served as a short relaxing break. It was the perfect combination of a holiday and work with the beautiful surroundings of Central Europe’s largest lake Balaton.

I was very excited to return to the country after the amazing Drupal Developer Days in Szeged event that I went to in March. It was also filled with meeting amazing people from all around the world, learning and sharing knowledge and connecting with so many inspiring people.

Catégories: Elsewhere

Imagine Creativity: <a href="/blog/drupal-west-london-monthly-meetup">Drupal West London monthly meetup</a>

mar, 18/08/2015 - 17:16

Come along to our group if you are interested in learning more about Drupal, are already using it and want to develop your skills, or would like to exchange experiences. I am particularly keen to train local young people, support charities and work on positive projects.

I have worked on the Open Drupal curriculum and mentored Drupal apprentices with it, as well as working with charities, social enterprises and small businesses to implement and support its use. In London we are lucky to have one of the most active physical communities in the UK, but I feel that some of the smaller groups I have visited (in Oxford, Leeds & Hungary) can have a much more of a supportive community feel and I aim to bring what I have learnt from them to this group.

Catégories: Elsewhere

Imagine Creativity: <a href="/blog/drupal-developer-days-2014-szeged-my-perspective">Drupal Developer Days 2014, Szeged - my perspective</a>

mar, 18/08/2015 - 17:16
Background

I had a great time at the Drupal Developer Days in Szeged (Hungary's third largest city) meeting other Drupal developers, core maintainers and people involved in the community. This event has been taking place yearly and brings together Drupal developers and enthusiasts from all over the world. Recent years have seen the event being held in Dublin, Barcelona & Brussels.

Catégories: Elsewhere

Imagine Creativity: <a href="/blog/upcoming-drupal-camps-uk-europe-2014">Upcoming Drupal Camps in UK &amp; Europe 2014</a>

mar, 18/08/2015 - 17:16

After the great time I've recently had at Drupal Camp London and at Drupal Dev Days in Szeged, Hungary I am looking at attending more community events. While looking I found it difficult to see all relevant camps listed in one place with all the information I wanted to see, so I created it. I hope it helps you too!

Catégories: Elsewhere

Chromatic: How To Write A Great Commit Message

mar, 18/08/2015 - 16:02
So annoying. Fixed a bug! Hope I never see this again.

These are not great commit messages; in fact, they are nearly worthless. A great commit message should tell the reader all they need to know about the what of the commit. They should only have to look at the actual diff of the commit to see how it was accomplished.

Anatomy of a Great Commit Message

Think of a commit message like an email:

  • It contains your contact information. You don't even have to do anything; you get this for free!
  • It should have a subject: the shorter, one-line summary.
  • A body: the detailed description.

All commit messages should abide by the following criteria:

  • Begin with a one line summary. It should be capitalized and succinct (50 chars or less).
  • This should be followed by a longer description, if necessary.
  • The first two items should be separated by an empty line.
  • All lines should be wrapped at approximately 72 characters.
  • Reference an issue in your commits whenever possible. If using Github issues, you can reference them by using 'gh-80' for issue '#80'. If your commit completes the issue, you can use a number of terms to close the issue, such as: .Closes gh-80'.
  • If you forget to reference the issue in your commit, and the commit has already been pushed, reference the commit's hash in a comment on the ticket.

Here is a model Git commit message:

Capitalized, short (50 chars or less) summary. More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together. Further paragraphs come after blank lines. * Bullet points are okay, too. * Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here. * Use a hanging indent. Closes gh-80.

The majority of your commit messages may be much simpler than the example above, but pick and choose the appropriate elements. Here is an example more common to the real world:

Fix for editor dashboard showing incorrect date. * Fixed date calculation logic. * Added function docblock to comply with coding standards. * Refactored foreach loop, improving clarity. Closes gh-80.

With just a few small improvements to your commit messages, your fellow developers, and your future self will surely thank you!

Catégories: Elsewhere

Drupal.org Featured Case Studies: AL DÍA News

mar, 18/08/2015 - 15:21
Completed Drupal site or project URL: http://aldianews.com

ALDÍANews.com is a national news outlet offering fully bilingual content, equally accessible in both English and Spanish at the click of a toggle. The new site - which publishes news related to politics, business, culture, opinion, media, and technology - allows readers to quickly and easily choose the language in which they want to view a comprehensive array of content and features optimized for various devices through responsive design.

After evaluating AL DÍA’s content and traffic, we uncovered the untapped potential for a larger audience and advertising stream by repositioning this local news site as a national news platform. The new site implements a number of innovative elements that benefit viewers and advertisers alike, including lightning-fast browsing using AngularJS, a fully bilingual interface, and advertising that can be served to specific sections, topics, or geographies.

Key modules/theme/distribution used: ServicesSimpleAdsTaxonomy menuViewsRadioactivityOrganizations involved: Eastern Standard
Catégories: Elsewhere

Imagine Creativity: What is Drupal & Intro to Drupal workshops - Global Training Day

mar, 18/08/2015 - 13:46
11822447_10153102896299716_3404987443558823562_n.png18 Aug 2015

We are happy to announce that we are running Drupal training sessions this month as part of the Global Training Days. The initiative is run by the Drupal Association to introduce new and beginner users to Drupal.

Come and join us on Friday 21st August to learn about what Drupal does and how it can help you. We will discuss the software and show you examples of it in action.

What is a Drupal Global Training Day?

Drupal Global Training Days is a worldwide initiative to increase the adoption of Drupal. All across the world, people are teaching and learning Drupal, and sharing that open source love.

During the last session run on May, 25 training companies from 15 countries participated in hosting Introduction to Drupal sessions. We are happy to be a part of this for the first time.

The two types of sessions are :-

  • What is Drupal - is a half-day workshop to address the basics of Drupal. It is designed for those interested in evaluating or implementing it.
  • Intro to Drupal - is a full day introductory training workshop. Attendees will leave having successfully built a Drupal site. It is designed for those interested in Drupal as a career path.
Who should attend
  • Web developers/designers willing to get started with Drupal.
  • Project managers managing or considering Drupal projects.
  • Decision makers evaluating Drupal. 
What is Drupal - Course outline
  1. Introduction to CMS
  2. Why Drupal; Comparative analysis of Drupal with other CMS.
  3. Case studies / Sites using Drupal
  4. When to and not to use Drupal?
  5. Where to find Drupal and Drupal installation
  6. Inside of DrupalGetting a functional site set up in 30-45 mins. Using contrib modules/themes/distributions, and getting community-based support
    1. Overview of each item of admin menu (e.g. Content, Appearance)
    2. Create and edit content
    3. Work with menus from admin
    4. Content type and its usage
    5. Block and where to find them
    6. Working with roles and users
  7. Getting a functional site set up in 30-45 mins.
  8. Using contrib modules/themes/distributions, and getting community-based support
  9. Support Drupal.org and Drupal Association
We are holding this event in partnership with CVS Brent, who will be hosting us. They work with many charity & voluntary sector organisations to better deliver their services.

Tags: DrupalTrainingDrupal Planet
Catégories: Elsewhere

Zivtech: Permissions and roles for happier users and admins

mar, 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:
Catégories: Elsewhere

Red Crackle: Object Oriented PHP

mar, 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.
Catégories: Elsewhere

Pages