Feed aggregator

Code Karate: Drupal 7 Mobile Friendly Navigation Toolbar module

Planet Drupal - Fri, 11/07/2014 - 13:12

The Mobile Friendly Navigation Toolbar is a replacement for the standard administration toolbar that comes with Drupal 7.

Categories: Elsewhere

DrupalCon Amsterdam: Inside Drupalcon Amsterdam Frontend Session Selection

Planet Drupal - Fri, 11/07/2014 - 08:21

After attending and helping to organize several Drupal events in Europe I have met a lot people and also had the chance to listen to many good speakers. I am also an usual speaker in DrupalCamps. That brought me enough experience to know when a session was interesting for the audience and feedback from attendees and organizers helps improve my sessions in the future.

It’s important for the speaker to know how to engage and entertain attendees. People will learn more and will be more satisfied if the session is dynamic and, why not, funny.

A few weeks ago I had the opportunity to collaborate, together with Lewis Nyman, in the Frontend track session selection for DrupalCon Amsterdam. I have never spoken in a DrupalCon so it was a good chance to learn from the best.

Our role was to help guide those who proposed a session by better aligning proposals with the suggested topics. That was a really good experience because I had to contact speakers I met in previous conferences and others I wanted to meet but we didn’t coincide in any event. Also we tried to invite speakers from other communities to spread the word of Drupal in other horizons and also to have opportunity to learn from professionals that are working in different projects and environments than those we use to know.

The response was impressive: we had more than 50 proposed sessions only in our track, for a total of more than 500 submissions overall. That’s a really big number taking into account that the topics were related to theming and design and because we have other tracks that cover development and site-building topics. Sometimes we had to move sessions from one track to another because it was difficult to decide which track the session fit best in.

Session topics were diverse but fit well with our needs, what made it really hard to decide between them. We had a limited amount of sessions to accept so Lewis and I tried to estimate different factors in the valuation process. We took into account previous speaking experience, using speaker profiles and videos or slides from previous sessions in other events.

A session's description was one of the most important factors to evaluate. Tip for prospective speakers: you should be really careful with your session description if you decide someday to speak in any conference. We contacted a few speakers prior to and during session selection to suggest slight variations on their session content so they can fit better with track topics or differ from other proposed sessions.

We tried to have a diverse Frontend track with interesting sessions, not only for front-end developers but also for UX designers, site builders, graphic designers… and not only Drupal people will be interested in them. I think anyone dedicated to web will enjoy and learn new techniques and tools used by well-known professionals in high-end projects.

You can imagine all the amount of time invested to prepare and coach speakers and also to plan and organize. We meet weekly as a team to comment, discuss and make decisions (also have a good time with Drupal fellows). It was a really enjoyable opportunity for me to gain more experience organizing Drupal events.

--
Ruben Teijeiro (rteijeiro)
DrupalCon Amsterdam Frontend Co-Chair

Categories: Elsewhere

godel.com.au: Ideas to help keep your Drupal project secure against the OWASP Top 10

Planet Drupal - Fri, 11/07/2014 - 07:24
Fri July 11, 2014 Ideas to help keep your Drupal project secure against the OWASP Top 10

I'm sure you've heard the phrase "Security is a process, not a product" before, or something along those lines. Drupal has a pretty good track record as far as Web-based CMS security goes, and there's a dedicated team of experts looking after Core and Contrib, but it's no secret that the most common vulnerabilities are those we accidentally introduce ourselves during our day-to-day tweaking (Drupal.org claims over 90%). The Drupal Security White Paper shows pretty clearly that the further we get away from the heavily peer-reviewed Core codebase, the more likely we are to unwittingly introduce something that's dangerous to our data.

In the case of what processes we can implement as individuals, self education and reflection is always important, so I figured that the present is as good a time as any to run through the OWASP Top 10 and present a few practical ideas and Drupal "Best Practices" to help mitigate the risks we inevitably expose ourselves to. I've added some quotes from the white paper to each section to put things into perspective.

#1 - Injection

Drupal contains a robust object-oriented database API that makes it difficult for developers to unknowingly create injection holes by automatically sanitizing query parameters and enforcing an interface. Drupal's file system interaction layer limits where files can be written and alters dangerous file extensions that the server could potentially execute.

In Drupal, injection attacks are generally going to be enabled by allowing unsafe data to sneak into SQL queries. In Drupal 7 we have two syntaxes for working with the database API, the classic Drupal 6 style db_query("SELECT * FROM foo f WHERE bar = 'baz'"); and the dynamic DBTNG style db_select('foo', 'f')->condition('bar', 'baz' , '=');.

For both syntaxes, there are two things I think are worth mentioning:

Make use of PHP's PDO and Prepared Statements

Drupal's database API wraps PHP's own PDO, which supports something called Prepared Statements that magically guarantee you won't suffer from an injection attack provided you actually use the API correctly.

So, if you're wondering how to use the API correctly, let's split all SQL queries we might want to use into two categories, those that could be considered hardcoded strings, and those that have one or more variable components. The examples above would be "hard coded", an example of something with variable components might look like this:

// Get the type of the node with the ID of the second URL component.
// WARNING: Don't actually do this! it is NOT secure.
$id = arg(1);
$query = db_query("SELECT type FROM node n WHERE n.nid = " . $id);

The issue here is that, unlike our hardcoded query, the value of $id can be set to anything at all by the end-user, most notably including strings that resemble fragments of SQL queries. We really don't want the end-user to discover one day that they can start executing their own queries against our database by carefully crafting URL components to exploit our PHP logic.

Here the fix is to either use PDO placeholders using Drupal's classic syntax, or leverage Drupal's internal query builder with the dynamic syntax. The following two examples (one for each syntax) are secure versions of the previous insecure example:

Drupal 6 syntax:

// Get the type of the node with the ID of the second URL component. // The important part here is that the second argument passed to db_query() // is an array of substitutions that will be sanitized internally. $id = arg(1); $query = db_query("SELECT type FROM node n WHERE n.nid = :nid", array(':nid' => $id));

Drupal 7 syntax:

// Get the type of the node with the ID of the second URL component. // The important part here is that we use the dynamic query builder to handle // the unsafe $id variable. $id = arg(1); $select = db_select('node', 'n') ->condition('n.nid', $id, '=') ->fields('n', array('type'));

The question now is, how do we know when a variable is "unsafe"?

The answer should really be, treat all variables as though they are unsafe by default and stop guessing. Be in the habit of using the more secure syntax by default, even when it is not strictly neccessary. This both reduces the risk of some edge-case creeping up on you that you hadn't considered, and makes your code more portable/standardised at the same time.

Make use of whitelists for tables/fields/operators

I think maybe this one is less obvious to many people than making use of PDO, but it is also important to consider.

As mentioned in a bunch of core issues, and elsewhere (read the comments) Drupal doesn't actually escape/sanitize everything that you pass the database API. The reason that those issues are still open and not flagged as "critical fix me NOW ZOMG" (In part), is because certain parts of our SQL queries are fundamentally unsafe to use user data for, even if they were being escaped by the system.

Imagine a query (presumably hooked up to a radio button or select element) like the following:

// Return the current user's username or email address to be displayed. // WARNING: Don't actually do this! it is NOT secure. global $user; $field_name = $form_state['values']['field']; $select = db_select('users', 'u') ->condition('u.uid', $user->uid, '=') ->fields('u', array($field_name));

In this case, the end-user can hack up the form you presented them however they like and submit something for the field form value like "password" to get a dump of what is stored in the password field for the current user account. It's not hard to imagine other, even more damaging scenarios.

Since Drupal knows that it is fundamentally insecure to be directly using user data for some things (e.g. table names, fields, operators in condition() and orderBy()) and assumes that you'll definitely be using whitelisted values only in these cases. There may well be a de-prioritised, outstanding Core bug that means your variables are not being sanitised/escaped at all, despite the fact that you're using the query builder. This means that, as well as the end-user getting at your user's passwords when you thought they could only see email addresses, they may also have a way to directly attempt an injection attack on your database.

The fix here is, make use of whitelists wherever you're dealing with variables for finite, pre-determined lists of valid options (like field names). For example, the above could be rewritten to be more secure like this:

// Return the current user's username or email address to be displayed. global $user; // Return the username by default. $field_name = 'username'; // Ony allow field names in our whitelist. $allowed_fields = array('username', 'mail'); if (in_array($allowed_fields, $form_state['values']['field'])) { $field_name = $form_state['values']['field']; } $select = db_select('users', 'u') ->condition('u.uid', $user->uid, '=') ->fields('u', array($field_name)); #2 - Broken authentication and session management

User accounts and authentication are managed by Drupal core. Authentication cookies and a user's name, ID, and password are managed on the server to prevent a user from easily escalating authorization. User passwords are salted and hashed using an algorithm based on the Portable PHP Password Hashing Framework and existing sessions are destroyed upon login and logout.

Drupal handles this well "out of the box" and most developers will be rarely doing anything that would break it. According to the white paper, there are very few Security Advisories being issued in this category, so I won't dwell on this.

#3 - Cross site scripting (XSS)

Drupal has a strong system for filtering user-generated content on display. Untrusted user's content is filtered to remove dangerous elements by default. For developers, Drupal has at least eight API functions for filtering output to prevent XSS attacks. When identified, common developer errors that lead to XSS vulnerabilities are mitigated by building safer defaults. For example, a page title function in Drupal 6 is the source of many XSS holes due to a lack of proper escaping. In Drupal 7 this function escapes output by default.

Hmmm, I think the words "by default" mean something different to the authors of the white paper than they do to me. If you do anything in the Drupal theme layer, and you don't explicitly, manually sanitise every single one of your variables as you render them, you have XSS holes in your theme.

In Drupal 8, there's a critical issue to try and get automatic escaping of markup into core by using the Twig rendering system which should dramatically increase security (in line with my intuitive definition of "by default") and improve performance as a nice bonus. That issue attempts to summarise the situation:

No-one can write XSS safe code. Nor core contributors, nor contrib developers, no-one.

and from a duplicate issue:

100% of all custom themes are insecure (the rest is rounding error). The reason is often that developers forget to escape their data in the templates.

By the white paper's own reported statistics, over 50% of reported security vulnerabilities in Drupal core and contributed community code are XSS issues.

In light of all this, between now and when Drupal 8 auto-escaping is released, even if you learn nothing else about Drupal security, you'll want to become familiar with a few of the API functions provided for string sanitisation.

For reference, the full list on api.drupal.org is:

Read up on all of the sanitisation functions, but the most commonly used (for general theming) are probably:

check_plain()

Use this when you have a string that is NOT supposed to be HTML, but you want to display it in an HTML context. It's really just a wrapper around htmlspecialchars(). Any characters in your non-HTML string that might be interpreted as HTML by the browser are converted into HTML entities so that they render as you would expect them to in a non-HTML context.

This means that your string that looks like X < Y & Y > Z becomes X &lt; Y &amp; Y &gt; Z.

A couple of things to keep in mind with this function:

  1. It's possible to accidentally double encode characters so that &amp; becomes &amp;amp;, which looks really bad when rendered. It is NOT a good idea to run check_plain() over everything without thinking, in case you run it on a string that has already had check_plain() run on it earlier.
  2. While check_plain() is an important function for security, "defusing" characters that could be interpreted as HTML, it's primary usage is for encoding/decoding characters, NOT guaranteeing that strings are "HTML safe" by stripping dangerous markup. For example, it's possible that a substring of a string that was previously run through check_plain() will have its encoding corrupted if an HTML entity is truncated before the closing ;.
check_markup()

Use this to apply input filters to a string that is intended to be used as HTML. In this case, we DO want HTML to be interpreted by the browser, but we also want to be careful not to open ourselves up to <script> elements or similar being executed maliciously. In the simplest usage, this function takes two arguments - the string and the machine name of the filter format to apply.

Filter formats themselves are an important part of core and too detailed a subject for me to go into here. Suffice to say that the "out of the box" formats set the tone for most custom filters created by developers:

  1. plain_text - Behaves as check_plain() does.
  2. filtered_html - Will strip any (customisable) HTML tags considered dangerous and leave the rest intact
  3. full_html - Will render any and all HTML tags in the string, even if they might be dangerous. (ab)Using this causes developers to grumble.

Avoid using the PHP input filter completely if you care at all about mitigating security risks.

t() and/or format_string()

Use this in situations where you want to perform simple string substitutions with variables (that might come from end-users data) and, in the case of t() also allow for the string to be translatable into other languages.

Since t() wraps format_string(), I encourage you to use the former as they behave the same way and you get the translatability "for free".

The advantage of using placeholders in strings, rather than concatenating variables, is twofold, format_string() will automatically apply check_plain() to substitutions that do NOT begin with ! and it makes the strings easier to contextualise for translaters.

// Here the translators can see a whole sentence and use the placeholders as clues. // We don't have to call check_plain() repeatedly because we're using @placeholder syntax. t('Yesterday I went to @place and brought home a @thing', array( '@place` => 'the park', '@thing' => 'frisbee', )); // Here translators only see two disjointed strings separately: // 'Yesterday I went to' and 'and brought home a'. t('Yesterday I went to ' . check_plain($place) . 'and brought home a ' . check_plain($thing)); #4 - Insecure direct object references

Drupal often provides direct object reference, such as unique numeric identifiers of user accounts or content available in the URL or form fields. While these identifiers disclose direct system information, Drupal's rich permissions and access control system prevent unauthorized requests. Methods for obfuscation are available through configuration and community-contributed code. Further, validation and protection against semantic forgery attacks is implemented in Drupal core via the Form API.

For Drupal, this largely comes down to making sure you have your server environment and Drupal site configured in a way that makes sense for your project, in the context of Drupal, I'm going to tie this into...

#5 - Security misconfiguration

Many critical risks, such as access to administrative site controls, text formats, and private information are restricted to a single admin account by default. Identified design inefficiencies that lead to misconfiguration are corrected often through usability testing and fixes are recommended for inclusion to core. Documentation of best practices for secure configuration and site building are provided for free on drupal.org and there are several contributed projects that conduct automated security review or implement further secure configurations.

In my experience, the two fastest ways to end up with hundreds of spambot accounts (or worse) on your account are:

  1. Servers configured in a way that is not Drupal friendly, lazily or by someone who isn't an experienced sysadmin.
  2. Developers building functionality as Drupal user 1 and never logging out or logging in as a user with a different role to test it.

For the first point. If you are not a sysadmin, you don't directly employ a sysadmin, or you don't have a friend who is a sysadmin who owes you a series of large favours, it is going to be much, much cheaper and less headache inducing to sign up with Acquia or Pantheon than to mess around with a shared hosting provider or to try and configure and maintain your own VM.

For the second point, the Drupal permissions grid is huge and tedious to manage as it involves a lot of user switching but there are a few things you can do for yourself to make maintaining complex permission sets easier.

Implement a simple, repeatable testing plan

In the Drupal community, SimpleTest and Behat are very popular testing tools. Both support simple assertions for the HTTP response code and the existence/absences of HTML elements on a rendered page. In fact, automated tests to check that a given user has permission to do something or visit certain pages are some of the easiest to write and can help you avoid those awkward conversations where we have to explain to someone that there was a regression in the site's fundamental security configuration.

Even if you don't have the time or resources to set up automated tests for a project, make step-by-step notes of critical functionality and user roles that can be tested as part of QA each release.

If you're using drush, you can generate a one time login for any user in the system with uli and their username:

$ drush @mysite.alias uli 'John Smith'

Have a deployment plan

People who don't know how to use the Drupal permissions grid just love to make changes to it, then immediately forget what changes they made, or tell anyone that they made the changes. That is, if you let them.

At the very minimum, you should be exporting your permissions into Features so that, should anything go wrong, you have some kind of "oh shit" button to get things back to working order, fast (without rolling back your database).

The Features approach is a little limiting for Permissions management though:

  • The permissions aren't actually locked. It's relatively easy for a permission to be changed on production and it won't be restored to the correct value until the Feature is next reverted.
  • It's not easy to toggle permissions on/off for different development environments. For most permissions you aren't going to want to do this anyway, but for those that you do, you really don't want the wrong permissions in the wrong environment.
  • There are a very large number of Permissions, and exporting them all to a Feature quickly bloats the Feature code and UI.
  • Adding a permission to a Feature artificially introduces a dependency of the Feature on that module.
  • Exporting permissions to Features is a tedious and error-prone manual process.
  • Permissions exported in Features are not very portable between projects.
  • The generated code in Features is difficult to read over quickly.
  • It's relatively difficult to manage permissions across multiple domains if you have a multisite setup.

There are various contrib modules that aim to make permissions management more secure and development friendly, to name a few:

Additionally, you might want to consider making permissions management part of your deploy/build scripts if you use such things to manage your environments.

#6 - Sensitive data exposure

Account passwords are salted and repeatedly hashed based on the Portable PHP Password Hashing Framework. Available Drupal community-contributed code offer solutions to encrypt sensitive data at rest or in transit.

This depends a lot on what your employer/client/government considers "sensitive" data. Where I live, in Australia, the government has published a convenient set of guidelides around sensitive and private data that can be used to gauge the level of risk if data were to be exposed. If you don't have any in your site, well that's great - although I still recommend implementing hook_menu() to unset the default node menu path if you haven't already, as it shows every node in the site by default, which can be awkward.

If you're working with Ubercart or Commerce, please, please triple check whether your payment gateway integration module sends user's credit card data through the Drupal Form API, to your server, before sending it to the payment gateway provider. This goes double (so sextuple check) for anything that claims to store credit card data for later use, even if it is "tokenized". If sensitive credit card (or similar) data touches your server even for a moment, you might be exposing yourself to fines if you haven't taken appropriate steps (PCI-DSS) to ensure encryption and security.

If you work with Drush, and multiple environments, you might want to consider implementing hook_drush_sql_sync_sanitize() for your project. This allows you to scrub out sensitive data from your production database as you pull it down, so that you don't accidently lose it to someone shady along with your laptop or not-so-trustworthy contractor. You don't need to use drush for this, there are lots of ways, including a simple shell script with SQL queries, to setup a decent database scrubbing script. Acquia have some documented examples of how to achieve this too, if you're interested.

#7 - Missing function level access control

Function level access in Drupal is protected by a powerful permissions-based system which checks for proper authorization before the action is taken. For the case of URL access, access checking is tightly integrated into the entire menu-rendering and routing system which means that visibility of navigation links and pages are protected by the same system that handles incoming requests.

Yes, menu-rendering uses access checking to ensure that navigation links are protected, but links generated by l() or #type => 'link' render arrays do not automatically run access checks. Function (and URL) level access control is very easy to implement in Drupal using hook_permission(), hook_menu() and user_access(). Creating new, custom permissions is very straightforward but it's also very easy to get wrong in subtle ways (especially if you're writing some new function that wraps another function with existing access checks) - as I mentioned above, make sure you have a solid testing plan in place for your new permissions scheme before you deploy it!

#8 - Cross-Site request forgery

Drupal validates user intention in actions using industry standard techniques. Typical actions with side- effects (such as actions that delete database objects) are generally conducted with the HTTP POST method. Drupal's Form API implements unique form tokens to protect against CSRF in POST requests. Less important actions can leverage the one-time token generation and validation functions of the Form API while still using an HTTP GET request.

Reviewing the security white paper, we can see that there's a relatively large incidence of contributed, non-core code that is not correctly implementing the Drupal Form API, leading to CSRF exploits.

Avoiding CSRF exploits in Drupal is relatively easy if you follow three simple rules:

  1. Whenever you expose an action to an end-user that modifies data in your site, implement it using a form (POST) rather than a link + menu callback (GET).
  2. Never try to build an HTML form manually, always use renderable form arrays and the Form API.
  3. Always use form validate/submit handlers and $form_state to access user submitted values rather than trying to extract information from $_POST directly.

If you need to quickly convert some GET based code you suspect might be at-risk to POST requests, the Drupal documentation suggests converting the page callback to a simple confirmation form using the confirm_form() core function as a base.

Another option, is to put a token in the URL that is unique for each page load and can't be easily forged, much like the Flag module does. Keep in mind though that this approach might not behave well in conjunction with cached markup containing links to URLs that rely on tokens like this.

#9 - Using components with known vulnerabilities

Included libraries and frameworks (of which there are few) in Drupal core are system-level, unsophisticated, and of low risk to full server or application compromise.

Unfortunately, this happens very, very frequently in Drupal as soon as you start counting contributed modules as "components". Ironically, the frequency of known security vulnerabilities showing up in installed modules is due in a large part to the security team doing a good job of reviewing and flagging community code. The difficult part here is being proactive about regularly deploying new module versions as security fixes are released.

It's a shame that the Droptor service was discontinued, as it provided a central dashboard for reviewing available security updates across multiple sites. Acquia and Pantheon both provide similar dashboards for sites hosted on their servers.

It's also a shame that the core Update module that "dials out" to Drupal.org to get the status of installed module versions is somewhat poorly optimised. It's very easy to configure a site (such as when using "poor man's cron") so that 20+ second page loads are experienced intermittently when using Update. If performance is important, I recommend enforcing the Update module to be enabled in a review environment, but not production or local development where slow page load times could become an issue.

There's little else to say here. Keeping your modules up-to-date is simply a matter of organisation/process and diligence and has little to do with development skills or further learning.

#10 - Unwanted redirects and forwards

Internal page redirects cannot be used to circumvent Drupal's integrated menu and access control system. Drupal protects against automatic redirection to off-site URLs which could be used in a phishing attack.

Drupal provides the drupal_goto() function for handling redirections correctly. This function will ignore absolute URLs in GET requests, but otherwise will always respect the destination parameter in the URL. This allows us to safely redirect/forward users by constructing our URLs correctly (with drupal_get_destination()), without opening ourselves up to phishing attacks.

The contrib External Links module also provides visual feedback for users, protecting them against unexpected offsite redirections, showing an icon on any link that will take the user to a new domain. The External Links Extra module takes this one step further and allows for a popup warning box, or even a dedicated intermediate page, to make it as clear as possible to users that they are about to be redirected offsite.

David Meister Director & Lead developer Using style-linking for sane @font-face declarations in a post-IE8 world Mon June 30, 2014 Say no to fake browser bold and fake browser italic, messy @font-face syntax and super-legacy browser bug support with the neat, logical style-linking @font-face syntax. Tags planet drupal
Categories: Elsewhere

Russell Coker: Improving Computer Reliability

Planet Debian - Fri, 11/07/2014 - 06:51

In a comment on my post about Taxing Inferior Products [1] Ben pointed out that most crashes are due to software bugs. Both Ben and I work on the Debian project and have had significant experience of software causing system crashes for Debian users.

But I still think that the widespread adoption of ECC RAM is a good first step towards improving the reliability of the computing infrastructure.

Currently when software developers receive bug reports they always wonder whether the bug was caused by defective hardware. So when bugs can’t be reproduced (or can’t be reproduced in a way that matches the bug report) they often get put in a list of random crash reports and no further attention is paid to them.

When a system has ECC RAM and a filesystem that uses checksums for all data and metadata we can have greater confidence that random bugs aren’t due to hardware problems. For example if a user reports a file corruption bug they can’t repeat that occurred when using the Ext3 filesystem on a typical desktop PC I’ll wonder about the reliability of storage and RAM in their system. If however the same bug report came from someone who had ECC RAM and used the ZFS filesystem then I would be more likely to consider it a software bug.

The current situation is that every part of a typical PC is unreliable. When a bug can be attributed to one of several pieces of hardware, the OS kernel and even malware (in the case of MS Windows) it’s hard to know where to start in tracking down a bug. Most users have given up and accepted that crashing periodically is just what computers do. Even experienced Linux users sometimes give up on trying to track down bugs properly because it’s sometimes very difficult to file a good bug report. For the typical computer user (who doesn’t have the power that a skilled Linux user has) it’s much worse, filing a bug report seems about as useful as praying.

One of the features of ECC RAM is that the motherboard can inform the user (either at boot time, after a NMI reboot, or through system diagnostics) of the problem so it can be fixed. A feature of filesystems such as ZFS and BTRFS is that they can inform the user of drive corruption problems, sometimes before any data is lost.

My recommendation of BTRFS in regard to system integrity does have a significant caveat, currently the system reliability decrease due to crashes outweighs the reliability increase due to checksums at this time. This isn’t all bad because at least when BTRFS crashes you know what the problem is, and BTRFS is rapidly improving in this regard. When I discuss BTRFS in posts like this one I’m considering the theoretical issues related to the design not the practical issues of software bugs. That said I’ve twice had a BTRFS filesystem seriously corrupted by a faulty DIMM on a system without ECC RAM.

Related posts:

  1. Reliability of RAID ZDNet has an insightful article by Robin Harris predicting the...
  2. Improving Blog Latency to Benefit Readers I just read an interesting post about latency and how...
  3. Banking with an Infected Computer Bruce Schneier summarised a series of articles about banking security...
Categories: Elsewhere

Drupal core announcements: Drupal core updates for July 10, 2014

Planet Drupal - Fri, 11/07/2014 - 00:53
What's new with Drupal 8?

The past two weeks have seen steady progress on Drupal 8, with the release of drupal 8.0-alpha13, the Clearing of the RTBC Queue, the expected deployment of Semantic Versioning support on Drupal.org, the launch of the #D8CX initiative, and the announcement about the roadmap for Drupal Commerce for Drupal 8!

Updates to api.drupal.org

If you go to https://api.drupal.org/api/drupal/8 you'll notice a few updates:

  • A few months ago, we updated the landing page with a list of topics, which were mostly just stubs. Documentation has now been written for most of the topics that are linked from the landing page.
  • There's a list of Services on the right sidebar, which you can filter by tag and name keywords — and each service has its own page, with appropriate cross-linking (list of code that uses the service on the service page, and if a service name is used in code, it should link to the service page)
  • The Classes page now lists Traits as well as classes and interfaces
  • For hooks like hook_form_FORM_ID_alter(), you can now see a list of functions that implement it (previously this only worked for hooks like hook_form_alter() where the function name was modulename_hookname(), but now it works for ALL_CAPS replacements as well).
Where's Drupal 8 at in terms of release?

Last week, we fixed 1 critical issue and 5 major issues, and opened 2 criticals and 10 majors. That puts us overall at 97 release-blocking critical issues and 614 major issues.

Where can I help? Top criticals to hit this week

Each week, we check with core maintainers and contributors for the "extra critical" criticals that are blocking other work. These issues are often tough problems with a long history. If you're familiar with the problem-space of one of these issues, and have the time to dig in, help drive it forward by reviewing, improving, and testing its patch, and by making sure the issue's summary is up to date and any API changes are documented with a draft change record, we could use your help!

More ways to help

Issue #1679344: Race condition in node_save() when not using DB for cache_field recently caused a Drupal.org outage. The issue already has a proposed resolution recommended in comment #24 — help out by creating a patch for either D7 or D8.

Additionally, there are a bunch of easy documentation issues which need some help moving forward. For each of these, there is a "Child Issues" sidebar. Look there for issues that are "active", "needs work", or "needs review":

If you want to get started with the core development process, this is a great way to get your first commit in core!

You can also search the Drupal Core issue queue for issues tagged "Novice": the ones in the "documentation" component are especially good for new contributors.

As always, if you're new to contributing to core, check out Core contribution mentoring hours. Twice per week, you can log into IRC and helpful Drupal core mentors will get you set up with answers to any of your questions, plus provide some useful issues to work on.

You can also help by sponsoring Drupal core development.

Notable Commits

The best of git log --since "2014-06-25" --pretty=oneline (201 commits in total):

You can also always check the Change records for Drupal core for the full list of Drupal 8 API changes from Drupal 7.

Drupal 8 Around the Interwebs

Excited to learn more about the changes coming up in Drupal 8, but don't like reading patch files? Here are some of the best articles from the past two weeks:

Drupal 8 in "Real Life"

Want to meet up with other Drupal folks excited about moving Drupal 8 forward? Code sprints are an ideal way to meet new friends, contribute to Drupal core and/or contrib, learn, share tips/tricks and discover new talent.

Two big events, Twin Cities DrupalCamp (in Minnesota, USA) and Drupalaton (in Lake Balaton, Hungary), will be holding massive, 4-day Drupal 8 sprints on Aug 7-10. Help us make sure there is space for everyone by signing up ahead of time!

Here are some other upcoming events:

  • July 10: Forum One is hosting a Code Sprint at their offices in Washington DC.
  • July 12-13: Drupal 8 at the Jersey Shore in New Jersey, USA, has room for 40 Drupal 8 sprinters. @drupalcampnj
  • July 16: DesignHammer is hosting a Drupal Coder Lounge event in Durham, North Carolina, USA to help work on Drupal 8 core and update documentation and contribtued modules for Drupal 8.
  • July 17-20: DrupalCorn in Iowa, USA will have a Drupal 8 contributed module sprint. @drupalcorn
Whew! That's a wrap!

Do you follow Drupal Planet with devotion, or keep a close eye on the Drupal event calendar, or git pull origin 8.x every morning without fail before your coffee? We're looking for more contributors to help compile these posts. You could either take a few hours once every six weeks or so to put together a whole post, or help with one section more regularly. Contact xjm if you'd like to help communicate all the interesting happenings in Drupal 8!

Categories: Elsewhere

Drupal core announcements: Drupal core updates for July 10, 2014

Planet Drupal - Thu, 10/07/2014 - 22:13
What's new with Drupal 8?

The past two weeks have seen steady progress on Drupal 8, with the release of drupal 8.0-alpha13, the Clearing of the RTBC Queue, the expected deployment of Semanitc Versioning support on Drupal.org, the launch of the #D8CX initiative, and the announcement about the roadmap for Drupal Commerce for Drupal 8!

Updates to api.drupal.org

If you go to https://api.drupal.org/api/drupal/8 you'll notice a few updates:

  • A few months ago, we updated the landing page with a list of topics, which were mostly just stubs. Documentation has now been written for most of the topics that are linked from the landing page.
  • There's a list of Services on the right sidebar, which you can filter by tag and name keywords — and each service has its own page, with appropriate cross-linking (list of code that uses the service on the service page, and if a service name is used in code, it should link to the service page)
  • The Classes page now lists Traits as well as classes and interfaces
  • For hooks like hook_form_FORM_ID_alter(), you can now see a list of functions that implement it (previously this only worked for hooks like hook_form_alter() where the function name was modulename_hookname(), but now it works for ALL_CAPS replacements as well).
Where's Drupal 8 at in terms of release?

Last week, we fixed 1 critical issue and 5 major issues, and opened 2 criticals and 10 majors. That puts us overall at 97 release-blocking critical issues and 614 major issues.

Where can I help? Top criticals to hit this week

Each week, we check with core maintainers and contributors for the "extra critical" criticals that are blocking other work. These issues are often tough problems with a long history. If you're familiar with the problem-space of one of these issues, and have the time to dig in, help drive it forward by reviewing, improving, and testing its patch, and by making sure the issue's summary is up to date and any API changes are documented with a draft change record, we could use your help!

More ways to help

Issue #1679344: Race condition in node_save() when not using DB for cache_field recently caused a Drupal.org outage. The issue already has a proposed resolution recommended in comment #24 — help out by creating a patch for either D7 or D8.

Additionally, there are a bunch of easy documentation issues which need some help moving forward. For each of these, there is a "Child Issues" sidebar. Look there for issues that are "active", "needs work", or "needs review":

If you want to get started with the core development process, this is a great way to get your first commit in core!

You can also search the Drupal Core issue queue for issues tagged "Novice": the ones in the "documentation" component are especially good for new contributors.

As always, if you're new to contributing to core, check out Core contribution mentoring hours. Twice per week, you can log into IRC and helpful Drupal core mentors will get you set up with answers to any of your questions, plus provide some useful issues to work on.

You can also help by sponsoring Drupal core development.

Notable Commits

The best of git log --since "2014-06-25" --pretty=oneline (201 commits in total):

You can also always check the Change records for Drupal core for the full list of Drupal 8 API changes from Drupal 7.

Drupal 8 Around the Interwebs

Excited to learn more about the changes coming up in Drupal 8, but don't like reading patch files? Here are some of the best articles from the past two weeks:

Drupal 8 in "Real Life"

Want to meet up with other Drupal folks excited about moving Drupal 8 forward? Code sprints are an ideal way to meet new friends, contribute to Drupal core and/or contrib, learn, share tips/tricks and discover new talent.

Two big events, Twin Cities DrupalCamp (in Minnesota, USA) and Drupalaton (in Lake Balaton, Hungary), will be holding massive, 4-day Drupal 8 sprints on Aug 7-10. Help us make sure there is space for everyone by signing up ahead of time!

Here are some other upcoming events:

  • July 10: Forum One is hosting a Code Sprint at their offices in Washington DC.
  • July 12-13: Drupal 8 at the Jersey Shore in New Jersey, USA, has room for 40 Drupal 8 sprinters. @drupalcampnj
  • July 16: DesignHammer is hosting a Drupal Coder Lounge event in Durham, North Carolina, USA to help work on Drupal 8 core and update documentation and contribtued modules for Drupal 8.
  • July 17-20: DrupalCorn in Iowa, USA will have a Drupal 8 contributed module sprint. @drupalcorn
Whew! That's a wrap!

Do you follow Drupal Planet with devotion, or keep a close eye on the Drupal event calendar, or git pull origin 8.x every morning without fail before your coffee? We're looking for more contributors to help compile these posts. You could either take a few hours once every six weeks or so to put together a whole post, or help with one section more regularly. Contact xjm if you'd like to help communicate all the interesting happenings in Drupal 8!

Categories: Elsewhere

LightSky: 14 Modules for Improving the Administrative Usability of your Drupal Site

Planet Drupal - Thu, 10/07/2014 - 21:57

Often times, Drupal gets a bad rap for usability. That’s because out of the box Drupal isn’t very user friendly. As with everything Drupal, it requires a few contributed modules in order to really make it shine. Below are a list of fourteen modules that you can add to your Drupal site to increase its usability. Let’s begin!

Views Bulk Operations - VBO is a module that allows you to execute bulk actions on views rows. The actions it comes with are pretty standard, but you can extend it using the Rules module or even roll your own if that’s your thing. This module allows for your site admins to be able to do things like mass delete nodes, mass publish/unpublish nodes, or even mass change the nodes author.

Admin Views - Admin Views is a module that replaces the stock administration screens with views. Why is this neat? You can add additional exposed filters to your users administration screens, or change which columns appear in order to help your site admins easily find the information they are looking for.

Draggable Views - Draggable Views is a module that allows your rows in a view to be reordered using the same javascript implementation that you find scattered about the Drupal admin (blocks, menu, etc).

Module Filter - Module Filter is a module that seeks to garner control over the unwieldy module listing page. It does this by adding a tab on the left hand side for each package, as well as one for showing the modules alphabetically. It also adds a textbox that you can search to quickly filter the module listing.

Autocomplete Deluxe - The Autocomplete Deluxe module replaces the default autocomplete element with the jQuery UI version making it much more user friendly than the default implementation.

Pathologic - The Pathologic module is an input filter which fixes image and link paths that would otherwise cause them to break. This is useful in situations where your site admins have content on both staging and live sites. Gone are the days of the live site pointing to the test site by accident or vice versa.

Custom Contextual Links - Contextual links was one of the features that our D6 -> D7 clients really seemed to love. One great usability improvement that you can make is to add a contextual link to a view (for example) that would allow them to quickly add the piece of content that corresponds to that view. Normally you’d add these custom contextual links through a set of hooks, but this module provides a nice UI to make it simple. 

Conditional Fields - The Conditional Fields module allows you to create fields that are dependent upon one another in order to be shown. One example of this would be to show a textarea of an admin (or user) selected “Other”. I added this module because it can be go a long way towards cleaning up administration screens when adding content types with lots of information.

Linkit - The Linkit module replaces the default CKEditor link icon with an autocomplete field that allows admins to easily drill down to the content they are looking to link to. We have a great write up on this module that you can find here.

Edit - Drupal 8 will ship with inline editing, and if you are too excited to wait, check out the Edit module. Edit module allows you to do just that, edit content in place. Note that you’ll need to use the CKEditor WYSIWYG if you want this to work on WYSIWYG fields.

Select2 - Like the autocomplete deluxe module above, the Select2 module replaces the standard select box with one that supports searching, remote data sets and infinite scrolling of results.

References Dialog - The References Dialog replaces all the standard reference fields with a dialog that allows them to add, edit and search for references. This can go a long way towards simplifying the administration workflow.

Content Menu - The Content Menu module adds the ability for administrators to be able to create pieces of content straight from the menu administration pages. When creating a piece of content, you have the ability to add a menu item, so it only makes sense that you can add a piece a content when adding a menu item.

Navbar - The Navbar module adds a mobile friendly navigation bar to the administration section of your website replacing the default toolbar which is non-responsive.

There you go. Fourteen modules to improve the authoring experience of your Drupal site. What do you think of the list? Are there any modules you would like to see added? Feel free to discuss in the comments below.

For more tips like these, follow us on social media or subscribe for free to our RSS feed and newsletter. You can also contact us directly or request a consultation
Categories: Elsewhere

Pages

Subscribe to jfhovinne aggregator