Planet Drupal

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

Drupal Blog: Drupal 8.2.3 and 7.52 released

Wed, 16/11/2016 - 19:11

Drupal 8.2.3 and Drupal 7.52, maintenance releases which contain fixes for security vulnerabilities, are now available for download.

See the Drupal 8.2.3 and Drupal 7.52 release notes for further information.

Download Drupal 8.2.3
Download Drupal 7.52

Upgrading your existing Drupal 8 and 7 sites is strongly recommended. There are no new features nor non-security-related bug fixes in these releases. For more information about the Drupal 8.2.x release series, consult the Drupal 8 overview. More information on the Drupal 7.x release series can be found in the Drupal 7.0 release announcement.

Security information

We have a security announcement mailing list and a history of all security advisories, as well as an RSS feed with the most recent security advisories. We strongly advise Drupal administrators to sign up for the list.

Drupal 8 and 7 include the built-in Update Manager module, which informs you about important updates to your modules and themes.

Bug reports

Both Drupal 8.2.x and 7.x are being maintained, so given enough bug fixes (not just bug reports) more maintenance releases will be made available, according to our monthly release cycle.

Change log

Drupal 8.2.3 is a security release only. For more details, see the 8.2.3 release notes. A complete list of all changes in the stable 8.2.x branch can be found in the git commit log.

Drupal 7.52 is a security release only. For more details, see the 7.52 release notes. A complete list of all changes in the stable 7.x branch can be found in the git commit log.

Security vulnerabilities

Drupal 8.2.3 and 7.52 were released in response to the discovery of security vulnerabilities. Details can be found in the official security advisories:

To fix the security problem, please upgrade to either Drupal 8.2.3 or Drupal 7.52.

Update notes

See the 8.2.3 and 7.52 release notes for details on important changes in this release.

Known issues

See the 8.2.3 release notes or 7.52 release notes for a list of known issues affecting each release.

Categories: Elsewhere

Valuebound: Create Custom content type programmatically using Configuration API in Drupal 8

Wed, 16/11/2016 - 18:08

Drupal 8 has quality of utility tool could help anyone to develop custom module box. One of the tool is Drupal Console, where any developer can follow the Terminal Command and generate the boilerplate for source code. Which help us to reduce time to write chuck line of code. And also help us to overcome with error rate to produce zero marginal error. Kind of typo & syntax error ;) . if you haven’t aware of Drupal Console then just go through it by installing on your local Drupal 8 instance. For fresh code like creating block or user or view or node I will suggest you boilerplate code. But as a New learner my suggestion would be always to write line by line code.

Here is the command that you need to generate Custom Content type using Drupal Console  generate:…

Categories: Elsewhere

Redfin Solutions: Redfin's Front-End Shell: Bundler, Susy, Compass, Breakpoint, and more!

Wed, 16/11/2016 - 16:51
Chris November 16, 2016 Redfin's Front-End Shell: Bundler, Susy, Compass, Breakpoint, and more!

While we at Redfin don't really yet have a full on base theme for every project, one thing we do use is our "bundler shell." This forms the basis of any Drupal 7 or 8 theme we build, and in fact, is really just the framework for the front-end (that is, this shell is useful outside of the realm of Drupal, actually).

First things first - here's the code.

Let's go ahead and begin the dissection...

Categories: Elsewhere

OSTraining: Beginners Guide to Contributing to Drupal : Prerequisites

Wed, 16/11/2016 - 15:23

Welcome to the first part of our series on contributing to Drupal for beginners.

Categories: Elsewhere

Drupalize.Me: Drupal 8 is 1 Year Old

Wed, 16/11/2016 - 14:31

It’s hard to believe, but it has been 1 year since Drupal 8.0 was released to the world. We’re celebrating Drupal 8’s first birthday on November 19th by giving FREE access to our full [Drupal 8 Migration Guide](https://drupalize.me/series/drupal-8-migration-guide) over the celebration weekend! This Saturday, November 19th through Monday, November 21st you can learn how to use the new core migration system to upgrade your Drupal site or import content from external sources. It’s time to get using Drupal 8!

Categories: Elsewhere

Unimity Solutions Drupal Blog: Dwell in Drupal 8 - Launching Webinar Series to Celebrate Drupal 8's First Birthday

Wed, 16/11/2016 - 13:25

At Unimity, we are celebrating Drupal 8’s first birthday by launching a new webinar series “Dwell in Drupal 8”!!

Categories: Elsewhere

Valuebound: Why big government websites are switching over to Drupal

Wed, 16/11/2016 - 13:14

The open source Drupal CMS powers some of the biggest government websites. Now what do government websites and media & entertainment websites have in common? A lot of functionalities and end goals are similar. Media websites have subscription forms, personalized data delivery, large data warehouses, events and related forms, publishing tools, marketing tools, transactions etc.

The Georgia Technology Authority was running 65 state government websites on two different versions of proprietary software - Vignette 6 and Vignette 7, one of which is no longer supported. It had become cumbersome and expensive. Apart from that, moving all the 65 sites to Vignette 8 was too much of a hassle. CTO Steve Nichols says, “As we dug in, all the obvious best choices were open source,”. The…

Categories: Elsewhere

Drupal.org Featured Case Studies: YHA Groups

Tue, 15/11/2016 - 18:35
Completed Drupal site or project URL: https://groups.yha.org.uk

YHA (Youth Hostels Association) is a charity which has provided Hostel accommodation to people of all ages and backgrounds for over 85 years. The majority of YHA's business is split between two sites; YHA which allows families and individuals to book accommodation, and YHA Groups which is aimed at groups and schools who are looking to book accommodation for groups of 16 or more people.

This project covered YHA Groups, a brand new Drupal 8 design and build to replace the existing site.

Key modules/theme/distribution used: BootstrapIMCEColorboxDraggableViewsgeolocationImage Widget CropSlickAdmin ToolbarContact BlockContact StorageContact Storage ExportStage File ProxyShieldPathologicOrganizations involved: MicroserveTeam members: rickdonohoemangy.foxAshley Georgetim.cliffordmarkpavlitskiSophie.SK
Categories: Elsewhere

J-P Stacey: A quick rundown of what using Drupal 6-to-8's migration UI feels like

Tue, 15/11/2016 - 17:00

Recently, I was asked to migrate a fairly straightforward website from Drupal 6 to 8: a blog; some feature articles; some static pages; a fair amount of uploaded images. I thought it would be a great candidate for reviewing what the Migrate UI bundled with core looks like, since its introduction in Drupal 8.1.0.

Although the Migrate framework more generally permits arbitrarily complex migrations, many people's first port of call will be the UI, so I thought it would be interesting to chart a user journey through its use: highlighting what went well, what went badly, and (most importantly) what looked problematic but turned out to be straightforward.

Read more of "A quick rundown of what using Drupal 6-to-8's migration UI feels like "

Categories: Elsewhere

Web Wash: Using Display Suite in Drupal 8: How to Use Switch View Mode Sub-module

Tue, 15/11/2016 - 17:00
In this tutorial series on using Display Suite, we've cover the two fundamental use-cases of the module: how to modify layouts and use Display Suite fields. Now we'll take a closer look at one of its sub-modules: "Display Suite Switch View Mode". The "Display Suite Switch View Mode" module allows an editor to switch which view mode is used on a content page. By default, Drupal will use the "Full content" view mode (if enabled) on content page, i.e., "node/1". But what if you want to choose between two different "Full content" view modes? Well this module has you covered. So instead of being stuck with a single view mode, you could have one for a layout with a sidebar and another for pages with go full width. In this tutorial, you'll learn how to configure and use the"Display Suite Switch View Mode sub-module.
Categories: Elsewhere

Zivtech: Use Gulp for Drupal 8 with Teams, Part 2: Creating tasks

Tue, 15/11/2016 - 16:09

This post is the second in a series covering Zivtech's usage of Gulp for front-end development in Drupal 8.

In the last post, I covered how to setup Gulp for teamwork on Drupal 8 projects. In this post, I'll go over how to get started with writing Gulp tasks. I'll also break down a specific task for Sass linting to ensure good code quality.

Maintainable and Readable Gulp tasks

With any mid-to-large sized Drupal 8 theme, it's really easy for the main Gulp file (gulpfile.js) become unwieldy and complex. With dozens of tasks doing all kinds of automated work, before too long, gulpfile.js becomes a soup of illegible code.

Additionally, members of your team might have different ways of naming Gulp tasks. One person might write a Sass building task called "buildSass" and another might create an identical task called "css."

It'd be nice to strip down gulpfile.js, make it readable, and somehow compartmentalize each task separately. Also, we want to cut down on task naming variations and create a unified system for structuring our tasks.

My current favorite way to handle these wishes is gulp-require-tasks. Basically, each task is written as an individual, CommonJS style module. Then, the tasks are arranged in directories, and that directory structure defines the task name. It is a very simple and predictable way to setup Gulp tasks.

Structuring Gulp tasks

Start off by creating the file tree structure below:

├── project/ │ ├── .gitignore (ignore node_modules, gulpfile.yml) │ ├── package.json │ ├── gulpfile.js │ ├── default.gulpfile.yml │ ├── sass │ │ ├── styles.scss │ ├── js │ │ ├── scripts.js │ ├── gulp-tasks │ │ ├── styles │ │ │ ├── lint.js │ │ │ ├── build.js │ │ ├── scripts │ │ │ ├── lint.js │ │ │ ├── build.js

The YAML settings file, default.gulpfile.yml, was discussed in the last post of this series, if you need a refresher.

gulp-require-tasks lets these tasks be accessible according to their structure. For example, to build the styles, you'll run "gulp styles:build" and to lint the JavaScript, you'll run "gulp scripts:lint." If you don't like the colon delimiter, you can change that too.

Update Gulp settings

In the last post we started the default.gulpfile.yml, and now we'll edit that same file to add in settings for the Gulp tasks we'll create in this project.

Open the file: it should look like this:

themeName: "myTheme" themeDescription: "myTheme description"

Expand on that by adding settings for source and destination paths of Sass and JS:

themeName: "myTheme" themeDescription: "myTheme description" styles: src: "sass//*.scss", dest: "css" lint: enabled: true failOnError: false scripts: src: "js//*.js", lint: enabled: true failOnError: false

Under the "styles" and "scripts" sections of the YAML, you can see I added some linting options too. From within the YAML settings, people can enable or disable linting, and also decide if they want the Gulp process to stop when linting errors are detected.

Pulling these settings out of the Gulp tasks themselves and into this YAML file means that developers don't have to search through the tasks looking for settings to change. Instead, they have every setting exposed to them in this one, concise file.

Importing tasks for Gulp

We haven't written any Gulp tasks yet, but we can go ahead and setup importing them so they can be used.

Open up the gulpfile.js we started in the last post. It should look like this:

(function () { 'use strict'; var gulp = require('gulp'); var yaml = require('js-yaml'); var fs = require('fs'); var assign = require('lodash.assign'); // read default config settings var config = yaml.safeLoad(fs.readFileSync('default.gulpfile.yml', 'utf8'), {json: true}); try { // override default config settings var customConfig = yaml.safeLoad(fs.readFileSync('gulpfile.yml', 'utf8'), {json: true}); config = assign(config, customConfig); } catch (e) { console.log('No custom config found! Proceeding with default config only.'); } })();

If you recall, we loaded the default.gulpfile.yml and overrode that with any settings from gulpfile.yml if it exists. The gulpfile.yml file has the exact same structure has default.gulpfile.yml, but settings can have different values. This lets other developers on the team override some settings if needed.

At this point in gulpfile.js, the config is loaded and ready to be used. Next, we integrate gulp-require-tasks.

(function () { 'use strict'; var gulp = require('gulp'); var yaml = require('js-yaml'); var fs = require('fs'); var assign = require('lodash.assign'); var gulpRequireTasks = require('gulp-require-tasks'); // read default config settings var config = yaml.safeLoad(fs.readFileSync('default.gulpfile.yml', 'utf8'), {json: true}); try { // override default config settings var customConfig = yaml.safeLoad(fs.readFileSync('gulpfile.yml', 'utf8'), {json: true}); config = assign(config, customConfig); } catch (e) { console.log('No custom config found! Proceeding with default config only.'); } gulpRequireTasks({ path: process.cwd() + '/gulp-tasks', arguments: [config] }); })();

Setting up gulp-require-tasks is super easy. We tell it where our gulp tasks are located, in the "gulp-tasks" directory.

Then, to each module (i.e. 1 module will be 1 Gulp task) in the directory, gulp-require-tasks passes arguments to each task. The first argument is always gulp itself. The "arguments" setting for gulp-require-tasks is an array of other things you want to pass to each module. I've opted to pass in "config," which is the object representing the settings merge in the YAML files.

This is essentially all you need in gulpfile.yml. However, I also like to add shortcut tasks too, that combine other tasks for quicker use. For example, general "build" and "lint" tasks might be like this:

gulp.task('build', ['styles:build', 'scripts:build']); gulp.task('lint', ['styles:lint', 'scripts:lint']);

Modular Gulp tasks

Let's start off creating the Sass linting task. To help with this, I recommend using gulp-sass-lint. You'll want to read over how to setup sass-lint, which I won't cover in detail here. Essentially, you create a .sass-lint.yml file in the root of the project. That file contains all the rules you want to validate; for example, should developers avoid styling with IDs or should they use RGB rather than HEX values for colors.

After sass-lint rules are in place, open up the styles linting file. Here you'll see the guts of the linting task:

'use strict'; var cached = require('gulp-cached'); var sassLint = require('gulp-sass-lint'); var gulpif = require('gulp-if'); module.exports = function (gulp, options) { if (options.styles.lint.enabled) { return gulp.src(options.styles.src) .pipe(cached('styles:lint')) .pipe(sassLint()) .pipe(sassLint.format()) .pipe(gulpif(options.styles.lint.failOnError, sassLint.failOnError())); } else { return console.log('css linting not enabled'); } };

For the three required packages, you'll want to "npm install" them of course. Don't forget the "--save-dev" flag to get those packages stored in package.json!

The bulk of the code exists within the standard, CommonJS "module.exports" directive. A Gulp process is passed into the task as well as the set of options from default.gulpfile.yml.

We start off by running a quick if/else check so that we short-circuit out of this task if the user disabled Sass linting. Then, we pipe in the files that we selected in the Gulp settings' "styles.src" section. Files are then piped through gulp-cached, which keeps a list of the source files (and contents!) in memory. This makes the task faster.

Next, the styles are linted and the results are formatted and reported out to the console. Finally, we use gulp-if to determine if the Gulp process gets terminated now should there be linting errors.

The sky's the limit

I leave it as an exercise for the reader to go about developing the other Gulp tasks. In the next post, I'll go over some other, more complicated Gulp tasks to show more advanced usage. Until then, you're more than welcome to look over and reference our own Gulp tasks we publish for Bear Skin.

Posts in this series

  1. Use Gulp for Drupal 8 with Teams, Part 1: Gulp Setup
  2. Use Gulp for Drupal 8 with Teams, Part 2: Creating tasks
Categories: Elsewhere

Savas Labs: Using MailChimp API v3.0 to subscribe users to email lists in Drupal custom modules

Tue, 15/11/2016 - 01:00

A tutorial that shows you how to use Composer and ThinkShout's new PHP library for MailChimp API v3.0 to easily subscribe users to mailing lists in Drupal custom modules without using the MailChimp contributed module. This is a follow-up to a previous post that used the old API, and also includes some new Drupal 8 specifics. Continue reading…

Categories: Elsewhere

Mediacurrent: Good Form: 5 Tips for a Smooth Sign-up Process

Mon, 14/11/2016 - 20:10

A lot of effort goes into engaging your visitors to ‘Sign-up’ or ‘Contact’ you. You send them a warm and fuzzy invitation to complete the form, tell them all the great reasons why they should complete the form… but who likes to complete a form? You can help guarantee a smooth sign-up process and increase the completion rate of your web forms with these five tips.

#1 Make it Flow

Before you begin designing that web form, it is always good to create a User Flowchart. Working to establish the form completion process from start to finish, a flowchart will help you:

Categories: Elsewhere

Chromatic: Introducing "ShouldIUpgradetoDrupal8.com"

Mon, 14/11/2016 - 19:06

We find that there's still uncertainty out there around upgrading to Drupal 8. The natural answer in the Drupal community is, "Yes, of course go with Drupal 8!", but in the world of tight deadlines and tighter budgets, the answer isn't so clear. Enter ShouldIUpgradetoDrupal8.com, an interactive tool we built to help the community answer that very question.

Categories: Elsewhere

Acquia Developer Center Blog: Contribution Stories: Preston So, Decoupled Drupal with Ember

Mon, 14/11/2016 - 18:49

Drupal gets better when companies, organizations, and individuals build or fix something they need and then share it with the rest of us. Our community becomes better, stronger, and smarter when others take it upon themselves to make a positive difference contributing their knowledge, time, and energy to Drupal. Acquia is proud to play a part, alongside thousands of others, in some of the stories making tomorrow’s Drupal better than today’s. One of them Preston So’s.

Tags: acquia drupal planetemberjavascriptfront enddrupalconDublin
Categories: Elsewhere

Palantir: Palantir.net's Guide to Digital Governance: URL Naming Conventions

Mon, 14/11/2016 - 17:50
Palantir.net's Guide to Digital Governance: URL Naming Conventions Palantir.net's Guide to Digital Governance brandt Mon, 11/14/2016 - 10:50 Scott DiPerna Nov 14, 2016

This is the eighth installment of Palantir.net’s Guide to Digital Governance, a comprehensive guide intended to help get you started when developing a governance plan for your institution’s digital communications.

In this post we will cover...
  • A recommended naming convention for URL paths
  • Some tips for choosing section names
  • Questions to consider when defining rules for redirects and aliases

We want to make your project a success.

Let's Chat.

A logical progression from Website organization is defining a naming convention for URL paths. URL paths should follow a consistent naming convention throughout all of your websites. Only under exceptional circumstances should a URL path name deviate from an established naming convention for a Website.

Best practices for URL path naming conventions recommend consistency in how sections, sub-sections, pages, and sub-pages are written. For most websites, I recommend URL paths follow the general naming convention below. 

     http://domain.com/SECTION/SUB-SECTION/PAGE/SUB-PAGE

This basic structure gives users an idea of where they are in the site’s hierarchy of pages. This can be especially important considering the volume of traffic that enters the site from web searches that will bypass the homepage and take visitors directly into deeper pages in the site. It’s also a good practice for improving the SEO value of your site’s pages, as it provides more specific context for the content of the page.

Section

Under this convention, SECTION is the top-level “directory,” and generally refers to the category under which subsequent content resides. For example, in the URL path http://domain.com/about, “About” is a primary category that often appears in a main menu, and thus receives a top-level URL path.

I generally like SECTION names to be one continuous string of letters without hyphens or underscores (e.g. about, services, people, etc.) because that makes for shorter top-level URL paths, however two word hyphens may also be acceptable if they aren’t too long. Given that top-level SECTION names are usually the label-names of your main navigation, it’s additionally wise to keep them clear, simple and concise.

Acronyms and abbreviations should be avoided because they often don’t make sense to visitors unfamiliar with the abbreviations. That being said, some abbreviations, such as http://domain.com/faq, may work so long as they make logical sense to most visitors.

If your Website has multiple users who are able to write URL path names, I recommended defining in the governance plan some limitation for who may write top-level directory names. These are typically the most highly sought-after URLs in a Website, and you will want to have a well-defined process for how those are distributed and assigned. A free-for-all is probably not a good process.

Sub-Section

SUB-SECTION is the second-level directory, if one exists. Using About as an example, “Meet Our Team” is the second-level “directory” in the URL path:

     http://domain.com/about/team

since “Meet Our Team” is just one of the sub-sections under “About” in this example.

SUB-SECTION names also may be one continuous string of letters without hyphens or underscores, such as:

     http://domain.com/about/team

or a string of words separated by hyphens:

     http://domain.com/about/meet-our-team.

The choice between the two really depends on whether the additional words add value to the user’s understanding of location, and/or if the string of words adds SEO value because it captures important descriptive words for the content of the page.

In the example above, the words “meet our” really don’t add much information, and the shorter URL path name is simpler. Simplicity may become more important as you add pages to sub-sections and the URL path names become very long.

Some URL path names may appear to deviate from this rule if a sub-section does not actually exist, in which case the sub-section location would be occupied by the page name.

Page

Pages on the “Meet Our Team” site would then have a URL path structure of:

     http://domain.com/about/team/PAGE-NAME

where PAGE-NAME could be any number of different page names. PAGE-NAMEs should generally describe the content of the page based on the page’s title. This can be expressed either as a single word (if a single word sufficiently describes the page), such as:

     http://domain.com/about/team/consultants

where “consultants” is a page for information about consultants on the team titled “Consultants”; or by a string of hyphenated words, such as:

     http://domain.com/about/team/website-consultants

where “website-consultants” is a page about Website consultants on the team titled “Web Consultants.”

For the purposes of SEO, at the page level, I generally prefer to include all of the keywords in a page’s title (separated by hyphens) in the URL path, especially when it adds descriptive value.

Sub-Page

As follows, sub-pages for any of the pages in the “Meet Our Team” site would have a URL path structure:

     http://domain.com/about/team/PAGE-NAME/SUB-PAGE-NAME SUB-PAGE-NAMEs

should follow the same rules as PAGE-NAMEs, however sub-page names may require longer strings of hyphenated names as pages become more detailed and specific:

     http://domain.com/about/team/consultants/drupal-content-management-system

Conversely, if sub-pages are breaking out content into simpler categories, they may benefit from shorter names:

     http://domain.com/about/services/web-platforms/drupal

rather than:

     http://domain.com/about/services/web-platforms/drupal-content-management-system

All of that being said, you should determine the system that works best for your needs and stick to it. Just keep it simple, logical, and as memorable as possible so that it is easy for all users to implement.

Multiple-Word Names

When writing URL paths with multiple-word names, I recommend using hyphens, such as:

     http://domain.com/about/services/web-platforms/drupal-content-management-system

rather than underscores:

     http://domain.com/about/services/web_platforms/drupal_content_management_system

or concatenation:

     http://domain.com/about/services/webplatforms/drupalcontentmanagementsystem

Use of underscores makes it far too easy for a user to misread an underscore as a space, especially when the URL path is hyperlinked:

     http://domain.com/about/services/web_platforms/drupal_content_management_system

Most hyperlinks are underlined to indicate to users that a section of text is a hyperlink.

Concatenation is more obviously problematic because it simply creates confusing URL paths.

Aliases & Redirects

How URL path aliases and redirected URL paths are handled will depend on the policies of your organization and the platform you use for your Website. I highly recommend you define the rules and processes surrounding URL aliases and redirects in your governance plan, and here are some questions to consider along those lines.

  • How are URL aliases and redirects managed in your Web environment?
  • Who manages URL aliases and redirects?
  • Is there a process or procedure for requesting an alias or a redirect?
  • May anyone request a URL alias or redirect?
  • Are redirects to Websites outside of your domain or server environment permitted?
  • Who determines whether a URL alias or redirected URL path is appropriate or not?
  • Are there any special rules for using top-level directories as URL path aliases or redirected URL paths?

 

This post is part of a larger series of posts, which make up a Guide to Digital Governance Planning. The sections follow a specific order intended to help you start at a high-level of thinking and then focus on greater and greater levels of detail. The sections of the guide are as follows:

  1. Starting at the 10,000ft View – Define the digital ecosystem your governance planning will encompass.
  2. Properties and Platforms – Define all the sites, applications and tools that live in your digital ecosystem.
  3. Ownership – Consider who ultimately owns and is responsible for each site, application and tool.
  4. Intended Use – Establish the fundamental purpose for the use of each site, application and tool.
  5. Roles and Permissions – Define who should be able to do what in each system.
  6. Content – Understand how ownership and permissions should apply to content.
  7. Organization – Establish how the content in your digital properties should be organized and structured.
  8. URL Naming Conventions – Define how URL patterns should be structured in your websites.
  9. Design – Determine who owns and is responsible for the many aspects design plays in digital communications and properties.
  10. Personal Websites – Consider the relationship your organization should have with personal websites of members of your organization.
  11. Private Websites, Intranets and Portals – Determine the policies that should govern site which are not available to the public.
  12. Web-Based Applications – Consider use and ownership of web-based tools and applications.
  13. E-Commerce – Determine the role of e-commerce in your website.
  14. Broadcast Email – Establish guidelines for the use of broadcast email to constituents and customers.
  15. Social Media – Set standards for the establishment and use of social media tools within the organization.
  16. Digital Communications Governance – Keep the guidelines you create updated and relevant.

Stay connected with the latest news on web strategy, design, and development.

Sign up for our newsletter.
Categories: Elsewhere

Drupal Console: Drupal Console RC-9 is out

Mon, 14/11/2016 - 15:34

Latest DrupalConsole rc-9 is out including several changes and fixes.

Support for command aliases

Aliases for commands added making easy to memorize by typing less. You can find aliases definition at https://github.com/hechoendrupal/drupal-console-core/blob/master/config/dist/aliases.yml

Support to execute the DrupalConsole Launcher on Windows platform

This PR https://github.com/hechoendrupal/drupal-console-launcher/pull/51 fixes the `\vendor\bin\drupal.php` file not found error.

Execute DrupalConsole from any directory within your Drupal site

No need to stay at site root directory. You can now switch to any directory as modules, themes, web/modules/custom or any other directory within your Drupal site. This was possible using the DrupalFinder project https://github.com/webflo/drupal-finder/

NOTE: Having a configuration file containing `root: web` on the site is no longer required. You can keep the file but is required to remove that value from your `path/to/drupal8/console/config.yml`

Improvements on the `init` command 

The interactive mode for the init command now ask you and show a list of directories where to copy the configuration files.

    Update instructions:

    Categories: Elsewhere

    Drupal Blog: Drupal 8 will no longer include dev dependencies in release packages

    Sat, 12/11/2016 - 02:19

    As a best practice, development tools should not be deployed on production sites. Accordingly, packaged Drupal 8 stable releases will no longer contain development PHP libraries, because development code is not guaranteed to be secure or stable for production.

    This only applies to a few optional libraries that are provided with Drupal 8 for development purposes. The many stable required libraries for Drupal 8, like Symfony and Twig, will still be included automatically in packaged releases. Drupal 7 is not affected.

    Updating your site

    To adopt this best practice for your site, do one of the following (depending on how you install Drupal):

    • If you install Drupal using the stable release packages provided by Drupal.org (for example, with an archive like drupal-8.2.2.tar.gz or via Drush), update to the next release (8.2.3) as soon as it is available. (Read about core release windows.) Be sure to follow the core update instructions, including removing old vendor files. Once updated, your site will no longer include development libraries and no further action will be needed.
    • If you use a development snapshot on your production site (like 8.2.x-dev), you should either update to a stable release (preferred) or manually remove the dependencies. Remember that development snapshots are not supported for production sites.
    • If you install your site via Composer, you should update your workflows to ensure you specify --no-dev for your production sites.
    Development and continuous integration workflows

    If you have a continuous integration workflow or development site that uses these development dependencies, your workflow might be impacted by this change. If you installed from a stable Drupal.org package and need the development dependencies, you have three options:

    1. Install Composer and run composer install --dev,
    2. Use a development snapshot (for example, 8.2.x-dev) instead of a tagged release for your development site, or
    3. Install the development dependencies you need manually into Drupal's vendor directory or elsewhere.

    However, remember that these development libraries should not be installed on production sites.

    For background on this change, see Use "composer install --no-dev" to create tagged core packages. For more information on Composer workflows for Drupal, see Using Composer to manage Drupal site dependencies.

    Categories: Elsewhere

    Drupal.org blog: What’s new on Drupal.org? - October 2016

    Fri, 11/11/2016 - 21:43

    Read our Roadmap to understand how this work falls into priorities set by the Drupal Association with direction and collaboration from the Board and community.

    The Drupal Association team has been getting back to work after coming back from DrupalCon Dublin in September. For the engineering team, October has been focused on some back-end services and infrastructure that support the Drupal project, while we continue to move forward on some longer term front facing initiatives.

    Drupal.org updates Promoting Drupal by Industry

    Last month we talked about the new homepage we released for Drupal.org, and using those editorial tools to build a membership campaign. We hinted that additional changes will be coming soon. While we're not ready to launch this new content - we can talk about it in some greater detail.

    Dries Buytaert, the project founder, has called Drupal the platform for ambitious digital experiences. That phrase expresses the incredible power and flexibility of Drupal, but also encapsulates an aspect of Drupal that can be difficult for newcomers. It can be very hard for newcomers to Drupal to understand how to take a base install of Drupal core, and extend that to achieve that ambitious vision.

    We want to help close that gap in understanding—to help evaluators see how Drupal achieves these ambitions. To do this, we'll be creating a series of landing pages that focus granularly on how Drupal creates success stories in particular industries. Look for more on this topic in coming months.

    DrupalCon Vienna Site Launched

    As is tradition, during the closing session of DrupalCon Dublin we announced that the next DrupalCon in Europe will be held in Vienna! We launched the splash page announcing the event at vienna2017.drupal.org and we have information about sponsorship and hotel reservations already available.

    DrupalCon Vienna will happen from the 25th to 29th of September 2017, and we'll hope to see you there!

    More flexible project testing

    We've made a significant update to how tests are configured on the Automated Testing tab of any project hosted on Drupal.org. Automated testing, using the DrupalCI infrastructure, allows developers to ensure their code will be compatible with core, and with a variety of PHP versions and database environments. In October, we updated the configuration options for module maintainers.

    Maintainers can now select a specific branch of core, a specific environment, and select whether to run the test once, daily, on commit, or for issues. Issues are limited to a single test configuration, to ensure that the code works in a single environment before being regression tested against multiple environments on on-commit or daily tests.

    Better database replication and reliability

    Behind the scenes, we've made some updates to our database cluster - part of our infrastructure standardization on Debian 8 environments managed in Puppet 4. We've made some improvements to replication and reliability - and while these changes are very much behind the scenes they should help maintain a reliable and performant Drupal.org.

    Response to Critical Security Vulnerabilities

    When it rains, it pours—a maxim we take to heart in Portland, Oregon—and that was especially true in the realm of security in October. The most widely known vulnerability disclosed was the 'DirtyCow' vulnerability in the Linux kernel. A flaw in the copy-on-write system of the Linux kernel made it possible, in principle, for an unprivileged user to elevate their own privileges.

    Naturally, responding to this vulnerability was a high priority in October, but DirtyCow was not the only vulnerability disclosed, as security releases were also made for PHP, mariadb, tar, libxslt, and curl. We mitigated each of these vulnerabilities in short order.

    Community Initiatives

    Community initiatives are a collaboration; with dedicated community volunteers building improvements to Drupal.org with the architectural guidance and oversight of the Drupal Association engineering team.

    Drupal 8 User Guide

    The Drupal 8 User Guide is getting very close to being available on Drupal.org. We are working closely with contributor jhodgdon to resolve some perplexing inconsistencies between what we're seeing in our development environment and in our initial production deployment.

    Dreditor

    markcarver who is currently leading the charge to port Dreditor features to Drupal.org, has invited anyone interested in contributing to join him in #dreditor on freenode IRC or the Dreditor GitHub.

    Documentation Maintainership

    Finally, we want to continue to encourage the community to become maintainers of Drupal documentation. If you are a developer interested in contributing code to the new documentation system, please contact tvn.

    ———

    As always, we’d like to say thanks to all the volunteers who work with us, and to the Drupal Association Supporters, who made it possible for us to work on these projects.

    If you would like to support our work as an individual or an organization, consider becoming a member of the Drupal Association.

    Follow us on Twitter for regular updates: @drupal_org, @drupal_infra

    Categories: Elsewhere

    MTech, LLC: Categorizing Migrations According to Their Type

    Fri, 11/11/2016 - 19:05
    Categorizing Migrations According to Their Type

    Very often in a migration of Drupal 6/7 to Drupal 8, have a need to run and test the migration many times. This applies more to sites that are very active, where site editors are updating or adding new content.

    Keep in mind that the Migration API in Drupal 8 offers a few paths to run migrations. The first is a user interface to make migrations through the path /upgrade. Through this method, the migration process is once and you can not make any customizations.

    The other method is to use drush to upgrade. And it is done by using these steps:

    Edys Meza Fri, 11/11/2016 - 12:05
    Categories: Elsewhere

    Pages