Uncertainty is an uncomfortable position. But certainty is an absurd one.
Allows a language to specify an alternative language so if a node translation for a specific language does not exist, Drupal will try to load the translation for the alternative language before throwing a 404.
This module is useful if you have multiple languages and only one language is typically translated. Rather than create all of the other translations and maintain those, the non-translated languages can load the node from the alternative language.
The Drupal community has developed several excellent modules to get fine-grained access control over a node (e.g. Content Access, Domain Access, Workflow, Organic Groups, Taxonomy Access Control, ...)
This exposed filter does not filter anything. It just shows and hides other exposed filters when you click either of two radio buttons which can be labeled as "mini search" and "extended search".
Provides 'Masonry' style layouts as an option for rendering the contents of panel panes.
Masonry rendering will re-pack panes in your panel to minimize vertical space and provide column-like appearance while the items are still in natural (horizontal) order on the page.
The next beta for Drupal 8 will be beta 4! Here is the schedule for the beta release.Tuesday, December 16, 2014 Only critical and major patches committed Wednesday, December 17, 2014 Drupal 8.0.0-beta4 released. Emergency commits only.
Configuration Packager for Drupal 8 enables the packaging of site configuration into modules, like Features for Drupal 7. Rather than producing manually authored individual features, Configuration Packager analyzes the site configuration and automatically divides it up into configuration modules based on configured preferences.
Will be a module to allow quick edit to be turned off on a per field basis.
Supported by examiner.com.
The Panels and Panelizer modules have opened up a whole world of options for layouts in Drupal, but too often the usage and features of these powerful tools get confused. My goal with this post is to explore some of the capabilities the Panels module has to offer before ever getting into the realm of using Panelizer.
At a high level, the goals of each of these modules break down into the following:
- Panels: Create custom pages with configurable layouts and components.
- Panelizer: Configure Panels layouts and content on a per instance basis for various entities.
Often, I see both modules added and used when Panelizer isn’t needed at all. What’s the problem with that? Introducing Panelizer when it isn’t needed complicates the final solution and can lead to unnecessary headaches later in configuration management, content maintenance, and system complexity.Panels and Panel Variants
Before the introduction of Panelizer, site-builders got by just fine with Panels alone. This original solution is still valid and just as flexible as it ever was. The secret in doing this lies in understanding how variants work and knowing how to configure them.Default Layout for All Nodes
Once Drupal finds a Panels page in charge of rendering the page request, Panels proceeds through the page’s variants checking the defined selection rules on each. Starting from the first variant, Panels evaluates each set of selection rules until one passes. As soon as a variant’s selection rules pass successfully, that variant is used and the rest below it are ignored. This is why it’s important to pay attention to the order in which you define your variants to ensure you place less strict selection rules later in the sequence.
Using this to your advantage, a good common practice is to define a default variant for your Panels page to ensure there is a baseline that all requests can use. To do this, you’ll need to define a new variant with no selection rules, so the tests always pass, and place it last in the series of variants. Since the selection rules on this variant will always pass, be aware that any variants placed below it will never be evaluated or used.Custom Layouts per Content Type
Once you have a generic default in place to handle the majority of content items for your Panels page, you can start to tackle the pages that might have more specific or unique requirements. You can do this by creating a new variant above your default and define selection rules to limit its use to only the scenarios you’re targeting.
A common use case for this is the changing layout for content based on content types. To build this out, you need to edit the default node_view Panels page and add a new variant. If this page variant is intended to handle all nodes of this type, I’ll typically name it with the name of the content type so it’s clear. The next step is to configure the selection rules by adding the “Node: Bundle” rule and select the content type we’re building for. Once you save the new variant, any detail pages for that content type should render using the new configuration.
Building on this, a single page can be expanded to handle any number of variants using any combination of selection rules necessary. It’s common to see a variant added for each content type in this way. Examples of further customizations that are possible include:
• A specific layout for a section of the site matching a specific URL pattern
• Separate layouts based on the value of a field on the entity
• Alternate views of a page if the user doesn’t have access to it
• Separate views of a page based on the user’s role
Thanks to CTools, these selection rules are also pluggable. This means if you can’t find the right combination of selection rules to enforce the limitation you need, it’s easy to write a new plug-in to add your specific rule.Avoiding Too Many Variants
Using the existing selection rules allows for a great deal of flexibility. Adding in custom plugins further improves your options to define any number of increasingly specific variants.
It is possible to take this too far, however. The cost of creating a new variant is that your layouts and content configurations are now forked further. Any common changes across them now have to be maintained in independent variants to maintain continuity.Visibility Rules
It’s important to also remember the other features Panels offers, including visibility rules. Visibility rules are configured on a per-pane basis inside a specific variant’s layouts. These rules offer the same conditions available in variant-level selection rules. Since they’re configured on individual panes, however, you can focus on the component-level differences between pages. A common use case for this is to use the same node variant for multiple content types with similar layouts and configure the unique panes with visibility rules to limit which pages they show on.
To elaborate on this, here’s an example. Assuming a default node variant with a two-column layout, we can define the common elements that all nodes will have, such as the page title, rendered content, and maybe a sidebar menu. If we then add the requirement that all article nodes include a list of similar articles in the sidebar, we can accomodate this by placing the correct pane in the sidebar and adding the visibility rule “Node: Bundle”. We’ll then configure it to use the current node being viewed and limit it to show only when that node is in the “Article” bundle. Now, whenever a node is displayed, it will show the common panes, but the block for similar articles will only show in the sidebar if we’re viewing a article node.Choosing the Right Approach
Once you get to the level of creating panel variants or visibility rules just for single pages, it’s usually time to ask if you’re using the right tool. When you’ve gotten to the point where individual page instances need to be different, you’ve come to the impasse of determining the best approach.
If it’s only a handful of pages that are each unique, then the most straightforward solution may be to create independent Panels pages for each of these.
If instead, individual instances of the same type need different layouts or configurations, then it may be time to install Panelizer to allow instance-specific overrides.
If you're interested in code quality and providing a means by which to bring Drupal beginners up-to-speed on the coding standards, I recommend reviewing code from all developers. I say "all" developers because everyone needs an editor.
The best way to force code reviews is to bake it into your development process. Use a tool like Gitlab (free hosted version) to prevent developers from committing code to authoritative branches. Instead, have them fork the project repository, and submit merge requests. Someone else can then review them. The reviewer can add in-line comments, wait for the developer to make changes, and then accept the request.
Here are some things to look for when reviewing Drupal code submissions. For some of these, we're assuming Git is being used for version control.
- Read, understand and follow the Coding standards.
- Install, enable, and use the Coder module on your development sites.
- For the purists out there, use the Coder Tough Love module as well.
- If you're running a continuous integration (CI) system like Jenkins, check the logs for new errors or warnings on new commits. Either way, make sure your development sandboxes have errors being reported to the screen so that developers can see any new errors that they generate. You'll find a lot of errors in your Drupal log if you're not doing this. (Make them refresh their DBs from your Dev site which already has this enabled.)
- Speaking of CI, add one or more code quality inspection tools to the mix such as SonarQube. There's actually a pre-configured Vagrant profile to build a VM with everything already set up. See CI: Deployments and Static Code Analysis with Drupal/PHP for details.
- Look for unrelated code reversions in merge requests. That is, if you see code changes that aren't related to what the developer is trying to do, there's something wrong. In most cases, this means the developer's branch is out-of-date with the main development branch. He or she should fetch and merge that branch from from the origin repository, fix any conflicts, and then add it to the merge request.
- Look for debugging code that wasn't removed such as dd(), drupal_debug() and other output functions.
- Look for Git conflict symbols such as "<<<", ">>>" and "===". These usually indicate a botched conflict resolution.
- Notice any lack of comments. Stanzas (small blocks of code that do little things) should be separated by blank lines, each with a comment explaining what it does. It may be clear to the original developer, but that doesn't help anybody else.
- Make sure that modules are installed in the right place. This is usually sites/all/modules/contrib (for upstream modules coming from drupal.org) or sites/all/modules/custom (for modules written specifically for the project).
- Ensure consistency in module package names. For custom modules, it's advisable to give the package name the name of the project so that it's clear that these are site-specific. For contributed modules, use what others are using; don't arbitrarily make one up. This helps keep your list of modules organized.
These are the most common issues I've discovered while reviewing code. If you have any others, feel free to add them as comments. I can add them to the list here.
On december 12 the Dutch Drupal Foundation will organise the first edition of the "SplashAwards". This award is to put outstanding projects in the spotlight, the best Drupal projects and community contributions from Belgium and The Netherlands.
Both Drupal agencies and individuals who have achieved extraordinary results get special recognition from inside and outside the Drupal community. The international jury selects winners out of hundreds of contestants in several categories including best government project and best Drupal theme.
The jury includes well known people in the broader PHP and Drupal community from all around the world: Joost de Valk (SEO WP fame) , Moshe Weitzman (contributor since 2001), Jeffrey "jam" McGuire (evangelist with a mo), Holly Ross (Executive Director DA) , Morten Birch Heide-Jorgensen (enfant terrible and good friend :-)), Stefan Koopmanschap (PHP / Symfony guru from the Netherlands) , Guido Jansen (magento fame) and Robert Douglass (SOLR fame and most of all around friendly chap) will select the ten winners who will walk home along the canals with a great award and a smiling face.
There are 10 awards to be given, from architecture and commerce to best governmental site and theme. The award self will be held for some 100 people, in an old cinema in the centre of Amsterdam. We are really looking forward to this event. And in fact, it will be the last event of the year for the Dutch and a great year it has been.
From a record breaking DrupalJam, via the social events around DrupalCon to 100's of students getting a free training on the Drupal Training Day and now the bowtie SplashAwards, showing of the Dutch Drupal community never was better.
If you need to create dynamic output on an entity when it is displayed on your Drupal site you have multiple options. One method that is easy to implement is using hook_entity_view().
You can insert this hook function into your custom module (see creating a custom module for more info).