Drupal Planet

KnackForge: How to update Drupal 8 core?

10 miesięcy 3 tygodnie hence
How to update Drupal 8 core?

Let's see how to update your Drupal site between 8.x.x minor and patch versions. For example, from 8.1.2 to 8.1.3, or from 8.3.5 to 8.4.0. I hope this will help you.

  • If you are upgrading to Drupal version x.y.z

           x -> is known as the major version number

           y -> is known as the minor version number

           z -> is known as the patch version number.

Sat, 03/24/2018 - 10:31

DrupalEasy: DrupalCon Baltimore Day 1 Recap

12 godzin 58 minutes ago

Direct .mp3 file download.

Join Kelley Curry, Ryan Price, Liz Lipinski, Dan Schiavone, Kevin Lannahan, Lakia Newkirk and Mike Anello discuss the goings-on at Day 1 of DrupalCon Baltimore. Music: Drupalcon Baltimore (to the tune of Good Morning Baltimore) from the Prenote.

CiviCRM Blog: CiviCRM Entity 2.0-beta7 Released

1 dzień 13 godzin ago

CiviCRM Entity 2.0-beta7 has been released.

Pick it up now at the Drupal.org Project Page

Changes since beta6:

Add Rules action Assign Contact to Group
Add Rules action Remove Contact from Group
Add Integration for IM entity
Add Integration for Website entity
Add integration for Contribution Recur
Add Rules event for CiviCRM Price Set Field 'After Successful CC Transaction'
CiviCRM Price Set Field , improved support for price fields with multiple checkboxes
Fix issues with CiviCRM Core Contribution Recur Views integration
Enable CiviCRM Entity Reference field on parent entity 'add', Inline Entity Form Single widget, for Contacts
Expose civicrm_world_region table to Views

Views Relationships:

  • Membership -> Membership Payment
  • Participant -> Participant Payment
  • Participant Payment -> Participant
  • Explicit Relationship from Address -> Country
  • Country -> World Region

Overhaul of CiviCRM Entity Inline, inline entity form widget FAPI generation and handling
Minor bug fixes for CiviCRM Entity, CiviCRM Price Set Field, CiviCRM Entity Discount, CiviCRM Entity Reference Field

 

CiviCRM Entity is close to its stable, non-beta release.  We've had fewer and fewer bug reports each release, and only 1 found in the main module since beta6. Unless something is broken, 2.0 will be cut next.

Development sponsored by Skvare

Thanks to all our contributors and users!

ToolsDrupalExtensionsRelease

Tim Millwood: Content Moderation + Content Translation = Crazy

1 dzień 14 godzin ago
Content Moderation + Content Translation = Crazy

As part of the Drupal Workflow Initiative we have critical issue relating to Content Moderation and translations. This is not actually a Content Moderation issue, but is just surfaced by Content Moderation because it allows you to create forward revisions. The video here should explain the issue:

Forward revisions + translation UI can result in forked draft revisions and Only having one default revision per entity forces translations to be kept in sync are the related core issues.

timmillwood Fri, 28/04/2017 - 16:08 Tags drupal-planet drupal 8 drupal core drupal Add new comment

Valuebound: How to create a Drupal Entity programmatically in Drupal 8

1 dzień 14 godzin ago

Entities have been introduced late in Drupal 7. Drupal entity is an instance of a particular instance type. For example, the entity type for taxonomy terms is named taxonomy_term and the class name Term. We include the class like  Drupal\taxonomy\Entity\Term. Here taxonomy is a core module name, and Term is the class name of Entity.

A. How to create an user programmatically.

The fields to be created are as follows:

  1.  Username
  2.  Email address

Amazee Labs: DrupalCon Baltimore, Heads or Tails?

1 dzień 17 godzin ago
DrupalCon Baltimore, Heads or Tails?

Every few years at DrupalCon, a new theme sweeps through the community. It’s a conceptual theme—a motif, a forward-looking glimpse into the future (not the kind with a .info file). The topic tends to dominate conversations and fill sessions. People have varying ideas of how to best approach the new frontier.

Kathryn McClintock Fri, 04/28/2017 - 13:38

When I first began attending DrupalCons in 2011, I remember the hype about responsive websites: the difference between responsive and adaptive layouts, which grid system to use, and how to best add and target classes to efficiently apply media queries.

In 2014, there was a natural and communal shift in interest to Drupal 8’s frontend. Twig was the new kid on the block and everyone wanted a taste. Developers aimed to learn the new syntax and eagerly compared the new D8 techniques to their tried and true D7 counterparts.

This year at DrupalCon Baltimore, the hot topic has been headless Drupal. Decoupling Drupal’s frontend has been buzzed about for years, but in the past it seemed to be just that—a buzz word—a conceptual, potentially problematic, but exciting idea. Today, on the last day of DrupalCon, it’s clear developers are not just buzzing anymore, they’re building headless Drupal sites and loving it. Amazee Labs is building headless Drupal sites and loving it.

Amazee’s history with headless Drupal is a complicated one. In fact, our own Michael Schmid pointed out during his and Brandon’s React, GraphQL and Drupal session, how Amazee Labs was both skeptical and dismissive of the decoupled/headless vision when the idea initially emerged. In the last quarter of 2016 however, Amazee’s stance on headless changed. I’d encourage you to review Michael and Brandon’s Wednesday session for a deeper explanation as to the reasons behind that shift. 

Technology is a rapidly changing thing and always will be. As developers, it’s natural to feel more or less acceptance towards some changes than others. As a frontend developer who’s grown to master and enjoy working in Drupal’s theme layer, the shift to headless is a tough pill to swallow. I’d equate the sensation to experiencing some kind of loss—there’s a kind of mourning for all the hard, long hours put into building expertise in a complex, yet rewarding theme system. I’ve grown to love Twig, transforming Drupal’s notoriously bad markup into something simple and semantic, and creating truly beautiful Drupal experiences “the old fashioned way.”

Dries published an article Tuesday during the conference, Drupal is API-first, not API-only. In the post, he discusses the benefits of preserving the coupling between Drupal’s front- and back- ends, at least in part. His summary on headless CMSs has validated many of the thoughts I have regarding a fully decoupled Drupal. There are reasons to remain coupled, reasons to go headless, and reasons for a middle-of-the-road approach.

We are certainly future-looking at Amazee Labs. As a company, we are committed to enhancing our team’s skills and providing clients cutting-edge solutions. My takeaway from DrupalCon Baltimore is to embrace and learn new skills required to build innovative headless frontends while simultaneously working to improve and educate others on Drupal 8’s theme layer. The best of both worlds. Let me hear from you, fellow frontend Drupal devs—what’s your take?

Jeff Geerling's Blog: Don't drown in your open source project!

2 dni 10 godzin ago

I presented Just Keep Swimming! Or, how not to drown in your open source project at DrupalCon Baltimore 2017, as part of the Being Human track. Below is a text summary of the presentation (along with the associated slides).

(I will also add a link to the video of the presentation once it's finished uploading.)

Hi, I'm Jeff Geerling, known most places around the Internet as geerlingguy. I've been involved with the Drupal community for almost nine years, and the Ansible community for four. I work for a company named Acquia, one of the largest Drupal service providers, and I write a lot (mostly about open source software), and automate a lot of things (mostly using Ansible).

Matt Glaman: DrupalVM and Circle CI: Deploying for the wins

2 dni 13 godzin ago

DrupalVM is a tool created by Jeff Geerling that “makes building local Drupal development environments quick and easy” for Drupal. It is built using Vagrant and provisioned with Ansible. Since it uses Ansible, it also provides a means to support a production environment deployment. This allows for a repeatable and determinable environment when developing and deploying to remote servers.

In fact, I currently use DrupalVM to power a Drupal Commerce 2 environment that I run locally and in production. The production environment is updated using continuous deployment via CircleCI. The wonderful roles created by Jeff Geerling and his playbook in DrupalVM handle my production deployment.

Want the tl;dr, skip to bottom for the example.

Setting up DrupalVM within your project

First things first, you’ll need to use DrupalVM. In this example we will add DrupalVM as a project dependency, using Composer. This is important. It ensures that any developer using this project, the CI/CD environment, and the final destination all have the same version of files. It also makes it easier to manage and receive upstream fixes.

For my project I followed Jeff’s blog post Soup to Nuts to configure DrupalVM and setup my DigitalOcean droplet to be my production target. You might want to read that over if you have yet to see how DrupalVM can go to production. I won’t copy those steps here, I’ll show how you can get CircleCI to deploy your DrupalVM configuration to a remote host.

See the article for full details, or my example linked later. For now I’ll do a quick review of some basic config.

The inventory file:

[drupalvm] 192.168.1.12 ansible_ssh_user=drupalvm

The config.yml file:

drupal_domain: "example.com" vagrant_hostname: "{{ drupal_domain }}" apache_vhosts: - servername: "{{ drupal_domain }}" documentroot: "{{ drupal_core_path }}" extra_parameters: "{{ apache_vhost_php_fpm_parameters }}"


The vagrant.config.yml file:

# Note, {{ drupal_domain }} overridden for Vagrant to use local.* prefix. drupal_domain: "local.example.com" The prod.config.yml file: drupal_deploy: true drupal_deploy_repo: "git@bitbucket.org:organization/repo.git" drupal_deploy_dir: "/var/www/drupal"

Those are the only tidbits in my production configuration. I treat the config.yml as primary with specific non-production overrides in vagrant.config.yml.

Adding Circle CI

NOTE! You’ll need to be able to deploy from CircleCI to a remote server, which means adding SSH permissions. With CircleCI you must create a key on your server and give the private key to project configuration.

Okay! So DrupalVM is running, you have accessed your site. Now, let’s run this sucker with CircleCI to do testing and deployment. Create a circle.yml file and let us walk through writing it.

First, we need to specify what language we’re using. In this case, I am using a PHP 7.0 image.

machine: php: version: 7.0.7 Defining dependencies

Next we want to set up our dependencies. Dependencies are things that we will need to actually run our tests, and they can be cached to speed up future runs. I’ll annotate specific steps using comments within the YAML.

dependencies:
  # Cache the caches for Composer and PIP, because package download is always a PITA and time eater.
  cache_directories:
    - ~/.composer/cache
    - ~/.cache/pip
  pre:
    # Install Ansible
    - pip install ansible
    - pip install --upgrade setuptools
    - echo $ANSIBLE_VAULT_PASSWORD > ~/.vault.txt
    # Disable xdebug (performance) and set timezzone.
    - echo "date.timezone = 'America/Chicago'"  > /opt/circleci/php/7.0.7/etc/conf.d/xdebug.ini
  override:
    # I save a GitHub personal OAuth token for when Composer beats down GitHub's API limits
    - git config --global github.accesstoken $GITHUB_OAUTH_TOKEN
    - composer config -g github-oauth.github.com $GITHUB_OAUTH_TOKEN
    - composer install --prefer-dist --no-interaction

Running tests

Before deploying anything to production or staging, we should make sure it does not deploy broken code.

test: pre: # Containers come with PhantomJS, so let's use it for JavaScript testing. # We specify it to run in background so that Circle CI saves output as build artifacts for later review. - phantomjs --webdriver=4444: background: true # Sometimes the test script can get cranky when this directory is missing, so make it. - mkdir web/sites/simpletest # User the PHP built-in webserver for tests, also run in background for log artifacts. - php -S localhost:8080 -t web: background: true override: # Run some tests - ./bin/phpunit --testsuite unit --group commerce - ./bin/phpunit --testsuite kernel --group commerce - ./bin/behat -f junit -o $CIRCLE_TEST_REPORTS -f pretty -o std Saving artifacts

In the event that our tests do fail, it would be great to see additional artifacts. Any process that had background: true defined will have its logs available. Adding the following lines will let us access HTML output from the PHPUnit Functional tests and any Behat tests.

general: # Expose test output folders as artifacts so we can review when failures happen. artifacts: # Folder where Functional/FunctionalJavascript dump HTML output - "web/sites/simpletest/browser_output" # Folder where Behat generates HTML/PNG output for step failures - "tests/failures" Setting up deployment

Now, it is time to tell CircleCI about our deployment process. Nothing too magical here. We are simplify defining that when the master branch passes to run a specific command. This command will load our production config and run the DrupalVM provisioning playbook on our production server. We specify the drupal tags to limit the scope of deployment.

deployment: prod: branch: master commands: # Specify DrupalVM environment and fire off provisioning. # DRUPALVM_ENV specifies which *.config.yml to load. - DRUPALVM_ENV=prod ansible-playbook \ -i vm/inventory \ vendor/geerlingguy/drupal-vm/provisioning/playbook.yml \ # Points to directory containing your config.yml files. -e "config_dir=$(pwd)/vm" \ --sudo --tags=drupal # I exported my Ansible user sudo password to environment variables to make provisioning work. --extra-vars "ansible_become_pass=${ANSIBLE_VAULT_PASSWORD}"

If your tests fail then the deployment will not run.

Example

Want to see an example of the full config? See my