Planet Drupal

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

FFW Agency: Mastering the Basics: The Content Plan

mar, 09/08/2016 - 21:26
Mastering the Basics: The Content Plan Ray Saltini Tue, 08/09/2016 - 19:26

It is amazing how often the content equation is underestimated or misunderstood whether building new properties or renewing existing sites.

The essence of any web project is the content or message to be conveyed. Understandably organizations will engage terrific creative agencies that will put tremendous effort into strategy and design. Unfortunately this often has the unintended effect of de-emphasizing existing content that may, or may not, need to be migrated to your new project. A thorough content audit early on in your planning process will help streamline your project and your budget.

Rarely is content brought over to a project wholesale without some important changes. This can be obvious like making PDF content more search engine friendly or less obvious like adding or changing metadata and reforming its underlying data structure. An audit will help determine if content migration should be included in your web development scope or handled as a separate component.

But unlike planning for strategy and design, resources are often scarce when it comes to content planning and conducting a content audit. It is likely the content planning process will be reduced to task level milestones and allocated to support staff or subject matter experts with little accommodation for the importance, difficulty or breadth of the requirements. This can lead to unforeseen and unwanted surprises during the development and user acceptance cycles of your project. 

Here are a few quick resources to get you started understanding the content planning process is Drupal.

A topic central strategy from a blog post that has only gotten more important: Understanding Content Planning: Why Taxonomy is Your New Best Friend

A great book from an accomplished Drupalist that will answer a lot of basic questions around content planning: The Drupal User's Guide by Emma Jane Hogbin Westby.

And a new series of articles about distributed content management by our very own Hank VanZile Director of Pre Sales Consulting starting with 'What is Distributed Content Management'

Tagged with Comments
Catégories: Elsewhere

FFW Agency: Breaking New Ground - Tapping Free Open Source Drupal to Achieve Big Gains in the Energy Sector

mar, 09/08/2016 - 21:10
Breaking New Ground - Tapping Free Open Source Drupal to Achieve Big Gains in the Energy Sector Ray Saltini Tue, 08/09/2016 - 19:10

Upheavals in the energy sector in recent years are driving a new Texas-sized need for efficiencies in all facets of business operations and are leading companies to begin mining new areas for streamlining and savings.

Houston, we have a solution.

The good news is open source technologies are opening up areas for exploration previously overlooked by many in the energy sector. In this multi-part series we’ll begin to look at how energy companies use the web and how open source internet technologies can drastically reduce acquisition costs, enable rapid prototyping, and create a potential for windfall profits.

Here’s a preview of our upcoming series on Drupal for the Energy Sector. Use the form below to sign up for our newsletter to get notified when we post new articles or sign up for our free training session on September 16 in Houston.

Acquisition Cost

Ever test drive a Lamborghini? Me neither. How about a proprietary web experience platform by one of the venders in Gartner’s Quadrants? Not happening. You wouldn’t buy a car you couldn’t test drive. Why consider purchasing a software platform you couldn’t pilot? Unless it’s open source you’re going to have to pay dearly for the privilege of any kind of test drive. Among the platforms listed in Gartner’s magic platform, Drupal is the only system you can freely pilot around your business needs.

Rapid Prototyping

Just because its free doesn’t mean you know what to do with it. Many open source systems have a huge transparent install base. You can install a simple plugin in your web browser that will tell you what Content Management System, technology or platform is being used. Drupal takes it even further with free custom developed distributions for different functional needs like ERP, localization and translation, publishing, ecommerce, event organizing, and networking. Agencies can build in various front end technologies and connect them to a Drupal backend with minimal customization.

Windfall Profits

How large is your IT department? Chances are the answer is something like, ‘Not big enough to do the job we have ahead of us.’ The nature of an open source project means you can tap more personnel than you could ever achieve a return on with a proprietary system. Drupal alone has over 3,000 developers that contributed to their latest version, Drupal 8. All of them are writing code that is highly secure and available for you to try and use for free.

Stay tuned for more on each of these and other topics in the coming days.
 

Tagged with Comments
Catégories: Elsewhere

jmolivas.com: The DrupalConsole RC-1 release is close with a lot of changes.

mar, 09/08/2016 - 20:27
The DrupalConsole RC-1 release is close with a lot of changes.

To make the DrupalConsole project more modular and easy to maintain, we are decoupling into separated projects.

jmolivas Tue, 08/09/2016 - 18:27
Catégories: Elsewhere

Gábor Hojtsy: There will be a Drupal 9, and here is why

mar, 09/08/2016 - 20:20

Earlier this week Steve Burge posted the intriguingly titled There Will Never be a Drupal 9. While that sure makes you click on the article, it is not quite true.

Drupal 8.0.0 made several big changes but among the biggest is the adoption of semantic versioning with scheduled releases.

Scheduled releases were decided to happen around twice a year. And indeed, Drupal 8.1.0 was released on time, Drupal 8.2.0 is in beta and Drupal 8.3.x is already open for development and got some changes committed that Drupal 8.2.x will never have. So this works pretty well so far.

As for semantic versioning, that is not a Drupalism either, see http://semver.org/. It basically means that we have three levels of version numbers now with clearly defined roles. We increment the last number when we make backwards compatible bug fixes. We increment the middle number when we add new functionality in a backwards compatible way. We did that with 8.1.0 and are about to do it with 8.2.0 later this year. And we would increment the first number (go from 8.x.x to 9.0.0) when we make backwards incompatible changes.

So long as you are on some version of Drupal 8, things need to be backwards compatible, so we can just add new things. This still allows us to modernize APIs by extending an old one in a backwards compatible way or introducing a new modern API alongside an old one and deprecate (but not remove!) the old one. This means that after a while there may be multiple parallel APIs to send emails, create routes, migrate content, expose web services and so on, and it will be an increasingly bigger mess.

There must be a balance between increasing that mess in the interest of backwards compatibility and cleaning it up to make developer's lives easier, software faster, tests easier to write and faster to run and so on. Given that the new APIs deprecate the old ones, developers are informed about upcoming changes ahead of time, and should have plenty of time to adapt their modules, themes, distributions. There may even be changes that are not possible in Drupal 8 with parallel APIs, but we don't yet have an example of that.

After that Drupal 9 could just be about removing the bad old ways and keeping the good new ways of doing things and the first Drupal 9 release could be the same as the last Drupal 8 release with the cruft removed. What would make you move to Drupal 9 then? Well, new Drupal 8 improvements would stop happening and Drupal 9.1 will have new features again.

While this is not a policy set in stone, Dries Buytaert had this to say about the topic right after his DrupalCon Barcelona keynote in the Q&A almost a year ago:

Read more about and discuss when Drupal 9 may be open at https://www.drupal.org/node/2608062

Catégories: Elsewhere

php[architect]: Testing Your Drupal Site with Behat

mar, 09/08/2016 - 20:05

If automated testing is not already part of your development workflow, then it’s time to get started. Testing helps reduce uncertainty by ensuring that new features you add to your application do not break older features. Having confidence that your not breaking existing functionality reduces time spent hunting bugs or getting reports from clients by catching them earlier.

Unfortunately, testing still does not get the time and attention it needs when you’re under pressure to make a deadline or release a feature your clients have been asking for. But—like using a version control system and having proper development, staging, and production environments—it should be a routine part of how you do your work. We are professionals, after all. After reading all the theory, I only recently took the plunge myself. In this post, I’ll show you how to use Behat to test that your Drupal site is working properly.

Before we dive in, the Behat documentation describes the project as:

[…] an open source Behavior Driven Development framework for PHP 5.3+. What’s behavior driven development, you ask? It’s a way to develop software through a constant communication with stakeholders in form of examples; examples of how this software should help them, and you, to achieve your goals.

Basically, it helps developers, clients, and others communicate and document how an application should behave. We’ll see shortly how Behat tests are very easy to read and how you can extend them for your own needs.

Mink is an extension that allows testing a web site by simulating interacting with it through a browser to fill out form fields, click on links, and so forth. Mink lets you test via Goutte, which makes requests and parses the contents but can’t execute JavaScript. It can also use Selenium, which controls a real browser and can thus test JS and Ajax interactions, but Selenium requires more configuration.

Requirements

To get started, you’ll need to have Composer on your machine. If you don’t already, head over to the Composer Website. Once installed, you can add Behat, Mink, and Mink drivers to your project by running the following in your project root:

composer require behat/behat composer require behat/mink composer require behat/mink-selenium2-driver composer require behat/mink-extension

Once eveything runs, you’ll have a composer.json file with:

"require": { "behat/behat": "^3.1", "behat/mink": "^1.7", "behat/mink-selenium2-driver": "^1.3", "behat/mink-extension": "^2.2" },

This will download Behat and it’s dependencies into your vendor/ folder. To check that it works do:

vendor/bin/behat -V

There are other ways to install Behat, outlined in the quick introduction.

The Drupal community has a contrib project, Behat Drupal Extension, that is an integration for Behat, Mink, and Drupal. You can install it with the requre command below. I had to specify the ~3.0 version, otherwise composer couldn’t satisfy dependencies.

composer require drupal/drupal-extension:~3.0

And you’ll have the following in your composer.json:

"drupal/drupal-extension": "~3.0", Configuring Behat

When you run Behat, it’ll look for a file named behat.yml. Like Drupal 8, Behat uses YAML for configuration. The file tells Behat what contexts to use. Contexts provide the tests that you can run to validate behavior. The file configures the web drivers for Mink. You can also configure a region_map which the Drupal extension uses to map identifiers (left of the :) to CSS selectors to identify theme regions. These come in very handy when testing Drupal theme output.

The one I use looks like:

default: suites: default: contexts: - Drupal\DrupalExtension\Context\DrupalContext - Drupal\DrupalExtension\Context\MarkupContext - Drupal\DrupalExtension\Context\MessageContext - FeatureContext extensions: Behat\MinkExtension: goutte: ~ javascript_session: selenium2 selenium2: wd_host: http://local.dev:4444/wd/hub capabilities: {"browser": "firefox", "version": "44"} base_url: http://local.dev Drupal\DrupalExtension: blackbox: ~ region_map: breadcrumb: '#breadcrumb' branding: '#region-branding' branding_second: '#region-branding-second' content: '#region-content' content_zone: '#zone-content' footer_first: '#region-footer-first' footer_second: '#region-footer-second' footer_fourth: '#region-footer-fourth' menu: '#region-menu' page_bottom: '#region-page-bottom' page_top: '#region-page-top' sidebar_first: '#region-sidebar-first' sidebar_second: '#region-sidebar-second' Writing a Simple Feature

Now comes the fun part. Let’s look at writing a feature and how to test that what we expect is on the page. The first time we run it, we need to initialize Behat to generate a FeatureContext class. Do so with:

vendor/bin/behat --init

That should also create a features/ directory, where we will save the features that we write. To behat, a feature is test suite. Each test in a feature evaluates specific functionality on your site. A feature is a text file that ends in .feature. You can have more than one: for example, you might have a blog.feature, members.feature, and resources.feature if your site has those areas available.

Of course, don’t confuse what Behat calls a feature—a set of tests—with the Features module that bundles and exports related functionality into a Drupal module.

For my current project, I created a global.feature file that checks if the blocks I expect to have in my header and footer are present. The contents of that file are:

Feature: Global Elements Scenario: Homepage Contact Us Link Given I am on the homepage Then I should see the link "Contact Us" in the "branding_second" region Then I should see the "Search" button in the "branding_second" region Then I should see the "div#block-system-main-menu" element in the "menu" region

As you can see, the tests is very readable even though it isn’t purely parsing natural language. Indents help organize Scenarios (a group of tests) and the conditions needed for each scenario to pass.

You can set up some conditions for the test, starting with “Given”. In this case, given that we’re on the homepage. The Drupal Extension adds ways to specify that you are a specific user, or have a specific role, and more.

Next, we list what we expect to see on the webpage. You can also tell Behat to interact with the page by specifying a link to click, form field to fill out, or a button to press. Again here, the Drupal extension (by extending the MinkExtension), provides ways to test if a link or button are in one of our configured regions. The third test above uses a CSS selector, like in jQuery, to check that the main menu block is in the menu region.

Testing user authentication

If you’re testing a site that is not local, you can use the drush api driver to test user authentication, node creation, and more. First, setup a drush alias for your site (in this example, I’m using local.dev. Then add the following are in your behat.yml:

api_driver: 'drush' drush: alias: "local.dev"

You can then create a scenario to test the user login’s work without having to specify a test username or password by tagging them with @api

@api Scenario: Admin login Given I am on the homepage Given I am logged in as a user with the "admin" role Then I should see the heading "Welcome" in the "content" region

If you’ve customized the username text for login, your test will fail. Don’t worry! Just add the following to your behat.yml file so that the test knows what text to look for. In this case, the username field label is just E-mail.

text: username_field: "E-mail" Custom Testing by Extending Contexts

When you initialized Behat, it created a features/bootstraps/FeatureContext.php file. This can be a handy class for writing custom tests for unique features on your site. You can add custom tests by using the Drupal Extension’s own sub-contexts. I changed my Feature Context to extend the Mink Context like this:

class FeatureContext extends MinkContext implements SnippetAcceptingContext {

Note that if you do that, you’ll need to remove MinkContext from the explicit list of default context in behat.yml.

No matter how you organize them, you can then write custom tests as methods. For example, the following will test that a link appears in the breadcrumb trail of a page. You can use CSS selectors to find items on the page, such as the ‘#breadcrumb’ div in a theme. You can also re-use other tests defined by the MinkContext like findLink.

/** * @Then I should see the breadcrumb link :arg1 */ public function iShouldSeeTheBreadcrumbLink($arg1) { // get the breadcrumb /** * @var Behat\Mink\Element\NodeElement $breadcrumb */ $breadcrumb = $this->getSession()->getPage()->find('css', 'div#breadcrumb'); // this does not work for URLs $link = $breadcrumb->findLink($arg1); if ($link) { return; } // filter by url $link = $breadcrumb->findAll('css', "a[href=\"{$arg1}\"]"); if ($link) { return; } throw new \Exception( sprintf("Expected link %s not found in breadcrumb on page %s", $arg1, $this->getSession()->getCurrentUrl()) ); }

If your context implements the SnippetAwareContext, behat will generate the Docblock and method signature when it encounters an unknown test. If you’re feature has the following:

Then I should see "foo-logo.png" as the header logo.

When you run your tests, behat will output the error message below that you can copy and paste to your context. Anything in quotes becomes a parameter. The DocBlock contains the annotation Behat uses to find your test when it’s used in a scenario.

/** * @Then I should see :arg1 as the header logo. */ public function iShouldSeeAsTheHeaderLogo($arg1) { throw new PendingException(); } Selenium

Follow the Behat docs to install selenium: http://mink.behat.org/en/latest/drivers/selenium2.html. When you’re testing you’ll need to have it running via:

java -jar /path/to/selenium-server-standalone-2.53.0.jar

To tell Behat how to use selenium your behat.yml file should have:

selenium2: wd_host: http://local.dev:4444/wd/hub capabilities: {"browser": "firefox"}

You’ll also need to have Firefox installed. OF course, at the time of this writing, Firefox is asking people to transition from use Webdriver to Marionette for automating browser usage. I have Firefox 47 and it’s still working with Webdriver as far as I can tell. I have not found clear, concise instructions for using Marionette with Selenium. Another option is to use Phantom.JS instead of Selenium for any features that need a real browser.

Once everything is working—you’ll know it locally because a Firefox instance will pop up—you can create a scenario like the following one. Use the @javascript tag to tell Behat to use Selenium to test it.

@javascript Scenario: Modal Popup on click Given I am at "/some/page" When I click "View More Details" Then I wait for AJAX to finish Then I should see an "#modal-content" element Then I should see text matching "This is a Modal" Conclusion

If you don’t have tests for your site, I urge you to push for adding them as part of your ongoing work. I’ve slowly added them to my main Drupal client project over the last few months and it’s really started to pay off. For one, I’ve captured many requirements and expectations about how pages on the site work that were only in my or the project manager’s heads, if not lost in a closed ticket somewhere. Second, whenever I merge new work in and before any deploy I can run tests. If they are all green, I can be confident that new code and bug fixes haven’t caused a regression. At the same time, I now have a way to test the site that makes it less risky to re-factor or reorganize code. I didn’t spend a lot of time building tests, but as I work on a new feature or fix a bug, writing a test is now just part of confirming that everything works as expected. For complicated features, it’s also become a time saver to have a test that automates a complicated interactions—like testing a 3-page web form, since Behat can run that scenario much faster than I can manually.

The benefits from investing in automated testing outweigh any initial cost in time and effort to set them up. What are you waiting for?

Catégories: Elsewhere

Arpit Jalan: GSOC 2016- Moving supporting functions to services and abstract parent classes- Week 11

mar, 09/08/2016 - 18:11
TL;DR Last week I had worked on modifying the tests for “Fill Alt Text”, “Emotion Detection” and “Image Properties” features of the Google Vision API module. The only tasks left are moving the supporting functions to a separate service, in addition to, creating an abstract parent class for tests and moving the functions there.

The issues Alt Text field gets properly filled using various detection features, Emotion Detection(Face Detection) feature and Implementation of Image Properties feature of the Google Vision API module are still under review by my mentors. Meanwhile, my mentors asked me to move the supporting functions of the “Fill Alt Text” issue to a separate service and use it from there. In addition, they also suggested me to create an abstract parent class for the Google Vision simple tests, and move the supporting functions to the parent class. Thus, this week, I contributed to follow these suggestions and implement them out.

There are few supporting functions, namely, google_vision_set_alt_text() and google_vision_edit_alt_text() to fill the Alt Text in accordance to the feature requested from the Vision API, and also to manipulate the value, if needed. I moved these functions to a separate service, namely, FillAltText, and have altered the code to use the functions from there instead of directly accessing them.

In addition, there are a number of supporting functions used in the simple web tests of the module, to create users, contents and fields, which were placed in the test file itself, which in one way, is a kind of redundancy. Hence, I moved all these supporting functions to abstract parent class named GoogleVisionTestBase, and altered the test classes to extend the parent class instead and in place of WebTestBase. This removed the redundant code, as well as, gave a proper structure and orientation to the web tests.
These minor changes would be committed to the module directly, once the major issues are reviewed by my mentors and committed to the module.
Catégories: Elsewhere

Galaxy: GSoC’ 16: Port Search Configuration module; coding week #11

mar, 09/08/2016 - 18:05

I have been involved with the Google Summer of Code' 16 project Search Configuration module to Drupal 8. It is entering into the final week of coding. I have really enjoyed the project process. This give university students a unique opportunity to code for real world projects that will be used by the various open source organisations.
Past week I dealt with testing certain components of my ported module. I worked on implementing the simpletest to test the various functionalities. I would like to take this opportunity to share with you the features of simpletest and how to implement it to test the proper working of the functionalities of various sections of the Drupal modules.

The test files are generally kept in src/Tests/ of the root of the module directory. The name of the test file should be suffixed by Test.php. Add a class that extends the webTestBase. Also, you need to add a namespace for the easy location of the class.

Add the name of the module to get loaded. i.e,
public static $module = ['search_config'];

Now lets start writing the test cases. The functions which should be executed should be prefixed by 'test'. For instance, to navigate to a particular link and check whether it returns the correct page;
public function testLink() {
$this->drupalGet('mypages/search');
$this->assertResponse(200);
}

You can run this test by going to Configuration->Testing->Select the test.
Also, add this test file to the .info.yml file. The following line of code will be sufficient enough.
files[]: src/Tests/fileTest.php

There are various types of test cases, here are the assertions available.
So, here is the complete structure of a sample test file to check the accessibility of a page in my search configuration module:
<?php

namespace Drupal\search_config\Tests;
use Drupal\simpletest\WebTestBase;

/**
* Class searchTest
* @group search_config
*/
class SearchConfigFormTest extends WebTestBase {
public static $module = ['search_config'];

/**
* Function to test the accessibility of the search configuration module location.
*/
public function testSearchConfigURL() {
$this->drupalGet('admin/config/search/pages');
$this->assertResponse(200);
}
}

We need to ensure that we write the group of test, i.e the @group tag. Here in this case is the search_config. The tests won't appear in the testing option in the absence of this tag. Also, ensure that a good definition of the function is given as comments for better understanding for the users reading the code.
You could also try out the various other assertions available to explore the various functionalities implemented. The development version of the module is currently available in the Drupal core.

Stay tuned for further updates on this porting process.

Tags: drupal-planet
Catégories: Elsewhere

Acquia Developer Center Blog: A Gentle Introduction to Data Science

mar, 09/08/2016 - 16:23

The words "Data Science" are not themselves sources of dread in most people. At just four and seven letters, respectively, they're almost too cute to be really off-putting like some of the other terms you come across when you begin digging into the field; terms like "k-nearest neighbors" or "tessellation."

And if you can hear the phrase "Euclidian minimum spanning tree" without feeling as though you've encountered something both bizarrely fascinating and deeply disturbing, you are a stronger intellectual force than I.

Tags: acquia drupal planet
Catégories: Elsewhere

Cheeky Monkey Media: Bootstrap Carousel + Drupal Paragraphs = Magic

mar, 09/08/2016 - 16:17
Bootstrap Carousel + Drupal Paragraphs = Magic calvin Tue, 08/09/2016 - 14:17

NOTE: This tutorial assumes you have some knowledge of Drupal site building, field and field display management. It will include some theming code examples.

If you've never heard of the Paragraphs module, it allows you to create "bundles" of fields and then call in those bundles via a paragraphs field on another entity. You can then add any number of these bundles into the entity, in any combination, to build out a page or some other super snazzy component.

Build bundles for a masthead, a pull quote, a banner, a simple text area... etc., and an editor now has a collection of tools to build dynamic pages, beyond the oldschool Title/Body/WYSIWYG situation. There are even modules that will help you get all parallaxy and animated with paragraphs.

The really beautiful thing is, you can nest paragraphs items. Yes, paragraphs items, within paragraphs items within... (The word Inception popped up a lot as we worked out various models).

Ok, so here's a practical example I built recently.

Catégories: Elsewhere

Anexus: How to add ReactJS in Drupal 8 with Composer

mar, 09/08/2016 - 15:37
How to add ReactJS in Drupal 8 with Composer

Inside the Drupal-verse the usage of Composer in our workflow is getting more and more popular.

To be honest, the immersion of composer in Drupal community hasn't been easy, but changes never are easy.

For the beginning of 2015, a new project sees the light Drupal Composer with the idea of modifying the way we do our development process in Drupal.

Drupal Composer project cover from install Drupal core, modules, themes, dependencies, patches and a long list of etc.

One of the elements that Drupal Composer it's going to replace is the famous *Drush Make*.

As I said the changes are not easy, and mostly everybody in our community is little lost (including me) regarding became familiar with this new way of doing our daily task in your jobs.

For that reason, I want to share with your, how to install ReactJS as a library to be used in our Drupal 8 Projects.

Maybe you could be thinking, well what is the fuss, and we could install ReactJS easily using Bower

But, the problem of use Bower is related with the fact of Bower doesn't know anything about Drupal, Bower doesn't have any idea where libraries in Drupal must be allocated, for that reason isn't the proper tool for our needs.

1. Drupal Installation.

In this example I will assume that did you install Drupal using *Drupal Composer* project, using an instruction similar to the following:

$ composer create-project drupal-composer/drupal-project:8.x-dev some-dir --stability dev --no-interaction 2. Adding repository

The library, ReactJS is not part of composer Packagist, but event that is possible to define a custom repository using ReactJS GitHub repository, adding a new composer repository in your composer.json file

"repositories": [ { "type": "package", "package": { "version": "15.3.0", "name": "drupal-libraries/reactjs", "type": "drupal-library", "source": { "url": "https://github.com/facebook/react.git", "type": "git", "reference": "15.3.0" }, "dist": { "url": "https://github.com/facebook/react/releases/download/v15.3.0/react-15.3.0.zip", "type": "zip" } } } ]

As you can see, we provide the ReactJS information in two formats, the first one is the GitHub repo and the second is a zip file of a specific release, depends of composer options, ReactJS will be clones or just downloaded and extracted. 

3. Adding ReactJS  in your project 

With your new ReactJS repository correctly added in your composer.json file the only remaining task in download the code using the next instructions.

$ composer require drupal-libraries/reactjs 15.3.0

When this command finished we will get inside /web/libraries/reactjs the requires files

libraries `-- reactjs |-- build | |-- react-dom.js | |-- react-dom.min.js | |-- react-dom-server.js | |-- react-dom-server.min.js | |-- react.js | |-- react.min.js | |-- react-with-addons.js | `-- react-with-addons.min.js |-- examples | |-- basic | |-- basic-click-counter | |-- basic-commonjs | |-- basic-jsx | |-- basic-jsx-external | |-- basic-jsx-harmony | |-- basic-jsx-precompile | |-- fiber | |-- jquery-bootstrap | |-- jquery-mobile | |-- quadratic | |-- README.md | |-- shared | |-- transitions | `-- webcomponents `-- README.md

I recommend checking the slides Improving your Drupal 8 development workflow http://weknowinc.com/talks/2016/drupalgov-workflow for more references about how to use Composer in Drupal 8 projects
 

If you are interested in more tricks and tips related to the new workflow in Drupal 8, stay tuned because Jesus Olivas and I will propose a BOF in DrupalCon Dublin to talk about the subject. 

enzo Tue, 08/09/2016 - 07:37
Catégories: Elsewhere

InternetDevels: Drupal 8: overview of the Commerce 2.x module for online stores

mar, 09/08/2016 - 14:28

E-commerce in Drupal 8 is a topic of interest for many developers. If you are among them, you’ve come to the right place — our Drupal developer has written a blog post on the Commerce 2.x module.

Read more
Catégories: Elsewhere

ComputerMinds.co.uk: Drupal 8 Config Management - how should I add config to a D8 site?

mar, 09/08/2016 - 14:00

For me this is the biggest unanswered question hanging over my development of Drupal 8 websites: How should I add config to a Drupal 8 site?

This article will provide plenty of options, but unfortunately no definitive answer.

Catégories: Elsewhere

MD Systems blog: MD Systems introduced NP8 to the Big Apple

mar, 09/08/2016 - 10:46
At the beginning of July we attended NYC Drupal camp, which is part of a bigger, mission-driven open source conference called Open camps. NYC Drupal camp is one of the biggest community-organized Drupal events in the world and we are always eager to return to it.
Catégories: Elsewhere

Chromatic: The Road to Speaking at DrupalCon

lun, 08/08/2016 - 19:06

Earlier this year I was fortunate to speak at DrupalCon New Orleans. I'd been working towards speaking at DrupalCon for a few years and it wasn’t until after I spoke that I reflected on just how much effort went into it. I had underestimated the process. Because I’m likely not alone in doing so, I’d like to share what I have learned along the way.

I'll start with why I wanted to speak at DrupalCon. I'll then share my story before providing some concrete advice for every step of the way.

Why speak at DrupalCon? The audience benefits

We’re an open source community and a well-crafted presentation is a valuable form of contribution. It provides information in a format that is often more effective than lines of code and walls of text. It also provides attendees with immediate access to the author for questions. Not to mention, the audience in the room is a small percentage of whom a recorded session will reach.

Your organization benefits

Sponsoring an event like DrupalCon isn't always within reach for a smaller organization. While a session should never be a sales pitch, each one is a marketing opportunity. A chance to mention the organization, sport its logo, and hand out swag. The success of a session can also boost the perception of a given agency or organization.

You benefit

Public speaking is an effective way to conquer a common fear and build confidence. Even veteran speakers still get nervous. Battling those nerves and coming out victorious is an excellent feeling.

Public speaking engagements are also an impressive line on a resume. Or perhaps it helps convince your boss that you’ve gone the extra mile and deserve that raise.

Finally, even though you’ll be the one presenting, you will learn a lot while preparing. It’s common to believe you don't know enough about a topic to talk about it. If you're interested in a topic, propose it anyway and use it as motivation to dive deep into that topic.

My story: You want to speak at DrupalCon? Start smaller

I first proposed a session hoping for a benefit I didn't already mention: a free ticket to DrupalCon Austin (2014). I'd co-founded a self-funded company and we were trying to save money. We submitted a session together and I knew we were in trouble when the proposal asked about our previous speaking experience. We didn't have any and our session wasn't selected. Strike one.

The company didn't last (not because we had to pay for the ticket), but I still wanted to speak at a DrupalCon. I now knew I would need to first speak at smaller events.

I was living in Chicago and MidCamp 2015 accepted one of three sessions I proposed. I then proposed three for DrupalCon Los Angeles shortly thereafter. Unfortunately, MidCamp was after LA session selection so I still had little to show. Once again, my sessions weren’t selected. (Of course, it could’ve also been because my topics weren’t worthy.) Strike two.

Shortly after LA I moved to Golden, CO, and shortly after that I spoke at DrupalCamp Colorado. Unfortunately my session didn't get recorded, but I was refining my skills nonetheless. Months later I spoke about theme functions and render arrays at BADCamp 2015 and I loved it. After BADCamp, I felt like I had established a track record and found a topic worthy of DrupalCon.

I took a third swing. I proposed a session on render arrays to DrupalCon New Orleans (2016). I spent over five hours writing just the proposal. A month or two later I was ecstatic when I received word that my session was selected. Home run!

Speaking at DrupalCon was a lot of fun, and was worth everything it took to get there. Looking back, I am thankful that the organizers consider experience at smaller events. Without that experience I would have been much less prepared. Speaking at DrupalCamps helped me refine my techniques and mental approach. It helped me build the confidence it takes to speak in front of a couple hundred people.

Advice for speaking at any Drupal event

There are plenty of websites, articles, and videos dedicated to providing advice for public speaking. I'm going to keep my advice to a list more tailored to Drupal events. I will link to some of those websites and articles when appropriate.

Picking an event
  • Drupical is a great way to find DrupalCamps and other events. If nothing else, attend and attempt to speak at the camps closest to you.
  • If you’re able to travel for a DrupalCamp, you might as well attend the bigger ones. You can often find camp websites from previous years. See how many sessions they had, who from the community spoke, and how many people attended.
  • Speaking at local meetups is another opportunity to practice. You may find the smaller and more familiar audience to be a benefit or it might make you more nervous.
Picking a topic
  • Consider the event's audience when brainstorming topics. DrupalCons often focus on the newest technology. Sessions at smaller events are more likely to be about less ambitious topics.
  • Only speak about topics you’re excited about. If not, it will be difficult to prepare for, and the audience will suffer from your lack of enthusiasm.
  • If you don't have confidence in your knowledge on intermediate topics, propose a beginner session. There are plenty of beginners at Drupal events and they need those sessions. That said, your lack of confidence may just be Imposter Syndrome speaking.
Proposing a session
  • When proposing a session, tell a story. Another simple formula: introduce a pain point, allude to your solution, and explain what you’re going to cover. Be sure to proofread it! Compare it to those written by seasoned veterans and try to determine if yours is on the same level.
  • Update your profile on the event's site with your picture and information. Make sure your online presence elsewhere, such as your Drupal.org profile, is up to date. Most events don’t do blind selections and they will look around to determine if you’re worthy.
  • DrupalCon track chairs and DrupalCamp organizers make themselves available for feedback on session proposals. Ask them about yours! Listening to their suggestions and building familiarity with them is only going to help.
Preparing and practicing
  • When preparing slides for a session, I’d recommend the design tips listed on speaking.io. I’d recommend reading the entire site, actually. It is my favorite resource on speaking about technical topics. I also bought the remote he suggests and I love it.
  • I aim to finish building my slides a week before my talk. I then practice once a day for the week leading up to the talk. This reduces the pressure and gives me time to tweak anything I don't like while rehearsing.
  • I also rehearse my talk in front of my wife. It helps get over the nerves because it’s hard to practice in front of someone you know well. She often has no idea what I’m talking about, but if she still doesn’t after 45 minutes of talking, I may have failed. Her questions often expose weaknesses in what I'm saying.
Presenting a session
  • I received great advice before first speaking at MidCamp: If you've arrived early and are waiting to start your session, talk to people in the audience. It helps break the tension.
  • Most Camps and all DrupalCons record the sessions. This may require you to remember to start the recording before you begin speaking. A volunteer will explain the technology to you, so you don’t have to worry about that. Just don’t forget to hit the record button!
  • As for the rest, I’d again recommend reading speaking.io’s advice on scoping out the room, dealing with nervousness, delivery, and handling questions. Zach covers these topics better than I ever would.
  • Start talking and have fun!

That’s about all I’ve got. Please reach out on Twitter (@guschilds or @chromatichq) if you have any questions or any ideas to add to the list. We are an open source community, after all!

Catégories: Elsewhere

Drupal core announcements: Don’t Miss the Drupal Midwest Developer Summit — Sign Up Today!

lun, 08/08/2016 - 18:24

It’s 80 degrees and sunny in beautiful Ann Arbor, Michigan, and we are enjoying a tasty cold beverage while dreaming of sprints for Drupal 8 and the community that comes with them.

Make your plans to join us for the Drupal Midwest Developer Summit, August 19-21, on the University of Michigan campus, in Ann Arbor MI.

Drupal community members will be sprinting for 3 days to make D8 the best it can be. You don’t have to be a coder to come! We also need help with writing documentation, designing UI, and helping to organize the sprints.

We will be having a group lunch on Friday and Saturday provided by your registration fees.

Sign up now before registration closes in a little over a week.

Register at https://mwds2016.eventbrite.com

Questions? Contact mlhess@drupal.org.

Catégories: Elsewhere

Acquia Developer Center Blog: Cf Shell: Streamlining CloudFormation Development with a Familiar Approach

lun, 08/08/2016 - 17:46

As Amazon Web Services has grown into the vast platform that it is today, it has created many opportunities for innovation: in how we interact with the products and how we fit all the pieces together. AWS's API-based nature has allowed an ecosystem of products to arise, all piggybacking on each other, ultimately enabling developers to explore unique ways to use their products.

Tags: acquia drupal planet
Catégories: Elsewhere

Deeson: Getting to grips with automated deployment in Drupal 8

lun, 08/08/2016 - 16:24

Many agencies have a well defined way of deploying updates to their customers’ Drupal 7 sites. Deeson is no exception to that rule. With the massive changes in Drupal 8, we figured this process would need to be looked at again. Our recent Notes Day, a dedicated day for improving how we work as an agency, was the perfect opportunity to do so.

Before we start

To get a good understanding of what we were trying to (re)build, here’s a quick run-down of a common Drupal 7 set-up:

  1. We use Drush make to download and patch everything that isn’t custom.
  2. Custom modules, themes and libraries are version controlled, while contributed code isn’t. This keeps the repository small.
  3. Drupal core is the exception: It is also version controlled so we can easily track changes to .htaccess files and the like.
  4. Configuration is stored using the Features module. Our features are version controlled as custom modules.
  5. The .gitignore file is configured for all of the above.
  6. We use the Master module to enable/disable modules per environment

 

Composer all the things! Or not?

Our first goal was to move away from Drush make and use what everyone else is using: Composer. Drupal 8 uses it to build its own dependencies and has recently opened a Composer repository of its own. Keep in mind this is still in alpha.

But here we already ran into a major issue. Packagist, the main Composer repository, already lists Drupal as a package. So if we want to grab the “drupal/drupal” package or the “drupal/core” package, Composer grabs it from Packagist instead of the official Drupal repository. This is due to Packagist trumping all other repositories.

You can, however, disable Packagist as a repository. But then you disable it for all required packages. Meaning if your site also needs a library from Packagist, you’re out of luck. There is no way to disable Packagist for just one package.

To add insult to injury, there’s also another community-built repository at https://packagist.drupal-composer.org/ and a “drupal/drupal” on Packagist which claims to replace “drupal/core”, even though the latter is the one you ideally want to use.

Conclusion: We have sources all over the web claiming to host Drupal for Composer, hardly any of them play together nicely and with the official repository in alpha it doesn’t seem like the situation will improve any time soon.

 

So what should we use?

If you are dead-set on using Composer, have a look at the drupal-project repository on Github by Bojan Živanović. He knows a ton about Composer and managed to get it to work with Drupal 8.

As you can tell by looking at his repository, there is a lot more needed than just a composer.json file to get it to work. We found this to be a dealbreaker as we would be relying on Bojan’s expertise blindly without knowing half of what’s actually going on within our build process.

If you share our inhibitions and want to see how things evolve first, we do have good news! Drush make still works beautifully so you can port that workflow straight to Drupal 8 with little to no alterations. We decided to go with this option for the time being.

 

Next up: Configuration management

With Drupal 8 came the configuration management initiative (CMI). This basically replaces the Drupal 7 Strongarm module by allowing you to export any configuration as a YAML file.

We figured we’d use this instead of Features because it’s always good to cut out the middle man, right? Wrong. It turns out you can’t simply ship some YAML file updates to your server and expect the site to “revert” to the new state like Features used to do in Drupal 7.

If you want to update your configuration, you’ll need to both export the new YAML file and write an update hook that details exactly what’s changed. This is obviously quite cumbersome.

Furthermore, you can’t enable a module that has certain configuration if it already exists in the website. Seeing as features are modules that do exactly that, the Features team had to swap out the configuration manager in Drupal 8 in order to make this work. Sounds dirty, but at least it works.

Conclusion: We gladly accept the presence of the middle man known as Features. We would have loved to use “just” Drupal core for this. Sadly it seems CMI fixed a lot of things, but not deployment workflows.

 

Wow, so what about the Master module?

So far we’ve scored 0 out of 2. The silver lining being that we can keep using the old workflow just fine. So with high hopes we took a look at the Drupal 8 version of the Master module. At least, we tried to - we couldn’t because there is no release for Drupal 8.

According to the module maintainer “derhasi”, there are no plans to port Master to Drupal 8. Because this news has made us all really sad pandas, we may spend one of our developer lounges cooking up a successor because let’s face it: Nobody likes to score 0 out of 3.

 

In conclusion

To sum things up: It’s perfectly safe to use your old workflow for the time being. We’ve tried and tested it and it all works fine. Except Master. Master is really, really dead right now.

However, we don’t want to advocate stagnation so we will keep a close eye on future developments regarding this subject.

It would also be great to hear from the people behind what we just investigated: Larry Garfield (Crell) for CMI or Bojan Živanović (bojanz) for Composer. Let’s see if we can get them to weigh in on the matter and get a discussion going.

Catégories: Elsewhere

Kristian Polso: How to install Drupal 8 (and Composer) on Windows 10 Bash

lun, 08/08/2016 - 15:29
Microsoft released Windows 10 Anniversary Update on August 2nd 2016, and this update included a much awaited "Windows Subsystem for Linux", which allows the user to run bash and command line Linux applications. It uses Ubuntu 14.04 as the base and as such is a great platform for local PHP development. In this tutorial I will show you how to install Drupal 8 (and Composer) environment on it. Roughly speaking, the necessary steps for this are:
Catégories: Elsewhere

Annertech: Top 5 Places to Visit While at DrupalCon Dublin

lun, 08/08/2016 - 11:12
Top 5 Places to Visit While at DrupalCon Dublin Coming to DrupalCon Dublin? Planning to take some extra time to explore the city? Here's our top 5 list of things to do and see while here - other than Drupal of course!
Catégories: Elsewhere

Pages