<?php | |
namespace Drupal\webhook_migrate\EventSubscriber; | |
use Drupal\webhook_migrate\MigrateRunner; | |
use Drupal\webhooks\EventSubscriber\NonBlockingSubscriberBase; | |
use Drupal\webhooks\Webhook; | |
use Drupal\webhooks\WebhookRelayQueue; | |
use Drupal\migrate\Plugin\MigrationInterface; | |
use Drupal\Core\Lock\LockBackendInterface; |
A co-worker recently asked me if the following is a good way to identify objects in Drupal 8:
get_class($object) == 'Drupal\Namespace\Thinger\ThingObjectService'
That totally works. It's just not very durable.
In Drupal 8, there is a built-in notion that almost anything might be swapped out for a different behavior. Thinger Service is known to be powered by a given class, but that class can be changed. Plugin X is defined as associated with a given class by annotations and whatnot, but those, too, can have their class changed. This means any code that hardwires a specific class has a slight amount of brittleness.
FROM node:4-alpine | |
ENV YO_P2_VERSION 2.2.0 | |
ENV PATTERN_LAB_STARTER_VERSION 2.0.0 | |
ENV GADGET_VERSION 1.0.0-rc1 | |
ENV P2_ENV_VERSION 1.2.0 | |
RUN node -v | |
RUN npm -v | |
RUN echo "Yeoman Doctor will warn about our npm version being outdated. It is expected and OK." |
<?php | |
namespace Drupal\back_reference; | |
use Drupal\field\Entity\FieldConfig; | |
use Drupal\Core\Entity\Query\QueryFactory; | |
use Drupal\Core\Entity\EntityTypeManager; | |
use Drupal\Core\Entity\EntityFieldManager; | |
/** |
/** | |
* Customized site install routine. | |
* | |
* Used as part of grunt install. | |
* | |
* Place this file wherever custom grunt-drupal-tasks plugins are loaded, such as bin/grunt for an Outrigger Drupal project. | |
*/ | |
module.exports = function(grunt) { | |
// Modify the drush site-install component of the routine. |
The individual files in this gist each have a unique trick to offer. They may be moved to official documentation or individual gists at a future date. | |
This file is mostly added because gists insist on titling the page with the alphabetically first file name, instead of the gist title. |
{ | |
"$schema": "http://json-schema.org/draft-04/schema#", | |
"id": "http://www.api-dx.vm/schemata/node/article?_format=schema_json&_describes=hal_json", | |
"type": "object", | |
"title": "node:article Schema", | |
"description": "Use <em>articles</em> for time-sensitive content like news, press releases or blog posts.", | |
"properties": { | |
"nid": { | |
"type": "array", | |
"title": "ID", |
# This Dockerfile uses multi-stage builds: https://docs.docker.com/engine/userguide/eng-image/multistage-build/ | |
# The builder image has all the dependencies necessary to assemble the website. | |
FROM node:8-alpine as builder | |
# The COPY operation looks to see if any of the source files changed since the last time the container was built. | |
# If not changed, it uses the cached copy of this operation. If it is changed, it performs the copy and all | |
# following steps for the builder, and for the COPY operation in the nginx image below. | |
COPY ./package.json ./package-lock.json /code/frontend/ | |
WORKDIR /code/frontend | |
RUN npm install |
Yesterday saw a couple small releases to some of the Outrigger docker images.
The Outrigger Dashboard image is automatically spun up by rig start
and rig dashboard
,
which automatically checks for updates. THe Dashboard image has been updated to Bootstrap 4, and now has a shiny navbar to connect your
use of Outrigger with the various online resources related to it. Check out what it will look like in the
Navbar Pull Request.