Not the first time on the planet of digital marketing does the company initiate bargains with corresponding media platforms to contribute the innovative ad templates to curtail the commercial scramble. The new story is between Mondelez signing a deal with Fox to found a more customer friendly advertising experience.Advertisment Examples
Really on point one of Advertisment Examples that evolved just to deliver the true message to the targeted audience. Pervading its use of TrueX for Mondelez was part of the package deal. That was the advertising operations platform fox started working with in 2014 only, again, to engage audience. This allowed users to experience and engage with one ad at a time at the top of the program so that the latter can be followed by a more detailed content. Why to overwhelm the user with numerous ads with overload of content when you can provide them with the one they are searching followed by the detailed description they will need. And this changes companies implement do not necessarily crack the media budget. The intended amounts are quite enough to cover the expenses. Where there is no fraud or it is limited and the focus is on selecting digital players where people are involved and are checking out the content this system will work just fine.
read more at http://chasemediallc.com/advertisment-examples/

Problem/Motivation

language.module causes config schema discovery for every module that is installed after it and languages being created.

Proposed resolution

Add missing config_export property to ConfigurableLanguage, trust the data that is saved in install hooks (there is a lot of saving going on, optimizing that could be interesting too)

Remaining tasks

User interface changes

API changes

Data model changes

This issue is postponed on #2759849: Create a new user-facing core theme. See #67 for details.

Problem/Motivation

Drupal's render & theme system are too complex to use. Let's improve this.

Goals

1. Improve the TX by un-WTF-ifying the theme and render system, which is currently a maze of:
   • hook_theme() (with variables vs render element), preprocess hooks, theme suggestions and many more related hooks — all tied together using the theme registry
   • #type (@RenderElement plugins) vs. #theme, which are kind of the same thing but not really: when to use which is unclear
   • callback buffet: #pre_render, #post_render, #lazy_builder
   • mysterious keys in enormous render arrays AKA render arrays of DOOM
   • #render_children, #theme_wrappers and friends determining where the render system morphs into the theme system and back again
   • different systems calling each other: understanding the entire flow is nearly impossible, and probably rivals the complexity of some simpler biological organisms
   • better documentation and and examples are band-aid solutions — they address the symptoms, not the cause— @c4rl

   These have been known problems for years! First there was Form API, then Render API sprouted from that, and all the while there was the theme system, but starting in Drupal 7, the Render API and the theme system got deeply, deeply intertwined. Drupal 8 actually made it slightly better, but not enough.

2. Improve the TX for non-JS front end people (markup & CSS people):
   • automatically generated pattern library (== all #type/@RenderElements — but without having to know those details)
   • automatically generated style guides for every theme (== pattern library with the theme's overrides/extensions applied)

   in other words: bring style guide-driven development to Drupal as a default rather than a labor-intensive, hacked-on after-thought (without the need to duplicate markup and thus keep them in sync).

3. Long-term: make it possible to reuse templates on the client-side (JS people).
4. Retain compatibility with the existing Render & Theme systems. Allow for a gradual transition.
5. Support interface previews: #2632750: Interface previews

Requirements

To address all of those goals, I believe a component library can be the gateway to sanity a solution. It can be, if the following requirements are met:

1. components are not deeply tied to Drupal, and in fact, can be developed independently of Drupal— this is how we can guarantee simplicity and ease of getting started: we actively prevent components from being tightly coupled to Drupal code
2. components have:
   1. markup: *.html.twig (Twig template — which may include some logic to process received variables, just like in Drupal 8)
   2. assets: CSS, JS files
   3. metadata: YAML file

   Nothing else.

3. modules and themes can specify components — modules can define patterns that any other module can use, themes can specify theme-specific components
4. components are defined in a simple directory structure:
   

   <extension> (module or theme)
    |- components
       |- <component name>
          |- <component name>.yml
          |- <component name>.twig

   Concrete example:

   core/modules/system
    |- components
       |- label
          |- label.yml
          |- label.html.twig
          |- label.css
   cores/themes/classy
    |- components
       |- label
          |- label.yml
          |- label.html.twig
          |- ajaxified-label.js

5. The YAML file specifies:
   1. the variables (inputs) of the component. For each variable:
      • type: only A) primitives such as string/integer/bool, B) arrays of primitives such as string[], C) other components: component or components to slot in other components (perhaps even component:<name> to only allow certain components ) — this enables 3 big wins:
        1. improved TX: type validation, to avoid weird bugs
        2. improved TX: no messy Doxygen/PHPDoc comments repeated in both templates and preprocess functions, and all overrides of either of those
        3. client-side re-rendering

        (Also: having type specifications in Twig templates instead is A) undesirable, B) quite likely impossible, C) quite likely impossible to parse without refactoring Twig, D) would pick up calculated variables.)

      • description
      • default value, if any
      • example value (to be used in pattern library & style guide)
      • preview value (to be used when the component's data is not available yet, because it's being used for an interface preview)
   2. documentation: purpose, when to use, how to use, accessibility, related links — in other words: information to show in the pattern library & style guides
   3. less important metadata: human-readable name, which other components this component includes, whether this component supports interface previews …
6. The Twig template (*.html.twig) performs all the necessary processing of the variables received, this ensures we don't depend on preprocess functions. This removes the need for front-end developers to dive into PHP.
7. components can be extended: add attributes, modify markup, and so on
8. components can be composed: combine multiple components to create a new component
9. To allow for a gradual transition, we cannot fully back away from render arrays nor the existing theme system. At best, we'll be able to remove render arrays, the current render system and the current theme system in Drupal 9.

Proposed resolution — or: how to transition

Aspect 0: components

Let components be defined as explained above.

Aspect 1: '#component' => …

Allow render arrays to use components by using '#component' => 'something', instead of '#type' => 'something' or '#theme' => 'something'.

The associated CSS and JS assets have been registered as an asset library automatically, and this asset library is attached automatically. Just define it in the YAML file.

This is familiar and similar. The transition is simple and understandable. But why would you want to do this? See the next few aspects.

Aspect 2: strict validation

Let Renderer strictly validate '#component' => … render arrays.

Remember that a render array is effectively a tree. Whenever a node/element/thing in the tree is a component, we can be more strict for just that one node/element/thing, but not for its supertree (parent) nor for its subtree (children). Example:

['#type' => 'something''child' => ['#component' => 'image','#uri' => …,
    '#width' => …,
    '#height' => …,
    '#alt' => …,
  ]
]

In this case, the properties (#-prefixed values of the image component will be strictly validated: only the ones specified by the image component will be allowed, and their types will be validated). This allows us to bring sanity to render arrays, one component at a time, one conversion at a time.

Render arrays have certain special/reserved properties that are necessary for them to function correctly. Think #attached, #printed, et cetera. Those will be condoned, because they don't affect the way the component is rendered.

Aspect 3: opt-in eligible #type and #theme to become #component

Help with a graceful transition, and peaceful coexistence. We gradually remove #type => something and #theme => something and replace it with #component => something But it is hard/impossible to keep all contrib code working: we can't expect everybody to simultaneously change existing render arrays to use '#component' => 'something' as soon as there is a something component.

So, whenever the Renderer encounters #type or #theme, we map it to #component if and only if they are eligible, which is:

• if it was #type, we only do the mapping if no #pre_render/#post_render/… are defined on the render array
• if it was #theme, we only do the mapping if no preprocess hooks are defined for it in the theme registry

Finally, if it wasn't #component originally, we don't apply our strict validation.

Aspect 4: new things must be components

New patterns in Drupal core are implemented as components.

Eventually

Eventually, when all #type (@RenderElements) and #theme occurrences are gone from Drupal core, we drop the old system, and we tag Drupal 9.

At this point, we will have a render array representing the entire page. The render array representing the entire page is then once again a tree. But rather than an incomprehensible tree, it is a well-defined, well-structured tree. It can even be split up into two parts that fit into each other perfectly:

1. a component tree: html → page → region → block → … — and for each of those components, there are holes (where the variables go)
2. a variable tree: html variables → page variables → region variables → block variables → … — the variables on each of these levels fit into the holes in the component tree

(Conceptually speaking, because subtrees can of course still be lazily built. Details in that area TBD.)

At this point, render arrays are just an implementation detail, and we can easily simplify that implementation.

Long-form rationale

This part is less precise, but tells a hopefully helpful story of the two most important considerations: how we ended up with the current painful system (recommended reading: http://hackingdistributed.com/2016/04/05/how-software-gets-bloated/) and how we can at the same time start to make it possible to integrate with JS more easily.
And, how, funny enough, those actually need the same fundamental thing: simplicity.

JS: web apps vs web sites

"Apps" are the hot thing in software this decade. But building native apps for every platform is very expensive. So "web apps" are a thing: build once, run anywhere, deploy instantly.

Web apps must be written in JS (or at least compiled to JS), so, consequently, JavaScript is the hot language of this decade. As a result, we've seen enormous investments in JS: Node.js, browser engines' JS interpreters have become incredibly fast, and … JS-based frameworks. From jQuery UI to Angular to Ember to React to …

Everybody wants "an app". And so quite often what would have been a web site a few years ago now is a "web app". And since web apps are written in JS, this means Drupal is less likely to be chosen for those scenarios.

(I personally think the distinction between the two can be made by determining whether the business logic happens in JS on the client or on the server. Only if it's on the client, it is a "web app".)

But that doesn't mean there's no more need for "regular" web sites anymore. It doesn't make sense to build an app just to present hyperlinked information… because for that, we already have an app: the browser. We just need to feed it web sites: documents of structured content, with excellent accessibility & usability, beautiful layout & typography and most importantly: great information architecture.

(And indeed, there is a very, very blurry border between "web sites" and "web apps". I'm just trying to paint a picture of the two extremes, where the world of the web is still finding an equilibrium somewhere in between. And of course, in some cases, it makes sense to have parts on the client side and other parts on the server side.)

Drupal 8 is even better at building web sites than prior versions.

But Drupal is getting pressure to also support "web apps".

So we have a tension between wanting to improve Drupal for what it has traditionally done (improve front-end experience by improving its templates, its markup, removing preprocess functions, etc) and making it possible to build more app-like experiences with Drupal.
But Drupal is not written in JS. Perhaps at some point in the future, there will be tight integration. But we have no idea what that would look like, if it will happen.

Getting ready for the future, and facing the past

However, even with the current system, we have long-standing problems. Extremely frustrated reports go back to at least 2011. The theme system and render system are deeply intertwined. It's very confusing. The experience even to build just web sites (not web apps) is far from ideal. Drupal 7 introduced the render system, but let's not forget its origin: Form API. The render system was originally just for forms, but it's since been generalized to be used for all rendering.

• Drupal 6: Form API + theme system
• Drupal 7: Form API + theme system, and both depend on the render system

Drupal 8 has made big steps forward: Twig, removal of most preprocess functions, much cleaner templates, #theme is gone in favor of #type (but not at all completely…), no longer necessary to to sometimes call render() in templates …

Unfortunately, as soon as the render and theme system interact, it's still painful.

We started working on an experiment at Acquia, where we worked with the Angular & Ember.js teams to do a prototype of what a better commenting experience for Drupal would look like. A reference implementation in Drupal using the AJAX system ("the Drupal way") versus what they would do. They had to reuse our Twig templates. A big problem there was the fact that just about every template has "blobs of HTML": {{ content }}, which actually contained the majority of the interesting stuff. And those blobs of HTML are… yes, render arrays!

Of course, no JS is ever going to be able to render render arrays, because they're so deeply intertwined with PHP code. And it's impossible to automatically determine which Twig templates are associated with every subtree in a render array.

So this makes it effectively impossible to reuse our Twig templates in JS. Ideally, that would be possible, it'd make Drupal better prepared for the future. It's better to at least have that possibility than not to.

However, even today, and in fact, in years past, this very same problem has been a major frustration for themers: they could only go so far with achieving what they needed to achieve by creating/modifying templates and writing preprocess functions. Very often, they would need to dive deep into render arrays and implement lots of hooks.

Imagine if that weren't the case, and we'd have templates all the way down, rather than enormous blobs of the resulting HTML being defined in render arrays. Imagine if the resulting HTML was wholly based on templates. Templates all the way down. Power to the themers.

And imagine that rather than ill-defined variables, they'd actually have type hints. And validation. And examples. And actually usable documentation rather than incomplete (and duplicated) docblocks. Together, that would allow us to automatically generate a style guide/pattern library.

As a bonus, client-side (re-)rendering becomes possible.

References

A close-to-comprehensive list of the references I've used to write/build the above.

TX

• #1382350: [discussion] Theme/render system problems, particularly #18 by @sun (four years ago!), @c4rl in #45, @Snugug in #56, @Crell in #59, @c4rl in #66
• #2008450: Provide for a drillable variable structure in Twig templates, particularly #1 by @effulgentsia, questioning why #pre_render and preprocess hooks need to be separate concepts
• #1441320: Evaluate Twig template engine for Drupal core (as an alternative for PHPTemplate and possibly even theme functions), particularly #17 by @msonnabaum, and #61 by @Crell + @msonnabaum: the reason render arrays/API is unable to allow for rendering on either client or server side is that it is deeply tied with PHP callbacks. If it were just templates + variables, then we could easily send that to the client side and render there
• #1843798: [meta] Refactor Render API to be OO, particularly this from the IS: This is because things like the image src are prepared in the field theme callback preprocessor, which isn't available yet to the node template— but this issue still doesn't go far enough in addressing theme/render API pains, as well as #2 by Crell: Is render API even needed? With the newer, more powerful tools available to us and the shift from page-level to block-level thinking (even if that doesn't quite make it into core for D8, it will be in contrib and I fully expect it to be the default way that professionals actually build things) why bother putting OO lipstick on that pig? Just kill it and fry up some bacon.
• #2004872: [meta] Theme system architecture changes
• #2291449: Add Twig template inheritance based on the theme registry, enable adding Twig loaders

Components

• #1804488: [meta] Introduce a Theme Component Library
• #2235485: [meta] Automated Theme Component Library - Overall concept/discussion
• http://jacine.net/post/19652705220/theme-system
• http://jacine.github.io/drupal/
• https://events.drupal.org/losangeles2015/sessions/drupal-9-components-li...
• http://www.marcdrummond.com/posts/2016/03/25/drupal-front-end-future
• http://patternlab.io— Atomic design
• https://guides.emberjs.com/v1.10.0/components/
• https://github.com/eexit/twig-context-parser (note how it only works for "set" calls, it turns out to be impossible to automatically parse variables, and even if we could, we couldn't determine the expected types)
• http://webcomponents.org/
• Design systems and Drupal (Slides - Video), a talk that Crell has given a number of times on how Drupal's site building model actually fits really really well with design component thinking/Atomic design. Having our rendering layer have the same mental model can only help to reduce complexity and confusion.

CSS/style guide

• #2102191: Discuss the availiable solutions to document the Seven style guide
• #2293627: [meta] Document Human Interface Guidelines and make Seven style guide, particularly #19 by @jhodgdon, #21 by @LewisNyman
• https://www.advomatic.com/blog/decoupling-drupal-without-losing-your-hea...
• https://github.com/scaninc/kss-php/
• https://github.com/kss-node/kss-node
• https://github.com/scaninc/ScanKssBundle
• http://johnalbin.github.io/flower-power/

Other

• http://www.callumhart.com/blog/non-blocking-uis-with-interface-previews
• http://www.callumhart.com/demo/building-interface-previews-with-react

Remaining tasks

Lots.

User interface changes

None.

API changes

None, only additions.

Data model changes

None, only additions.

Problem/Motivation

In unit tests, for example, you can have the situation of not having any routes, but invoking the routing system nonetheless.

This makes the call to array_keys($this->pathRoots) in \Drupal\Core\EventSubscriber\PathRootsSubscriber::onRouteFinished() fail, because $this->pathRoots is not initialized to an (empty) array, so it is NULL.

Proposed resolution

Initialize $pathRoots to an empty array.

Remaining tasks

Write patch.

User interface changes

None.

API changes

None.

Data model changes

None.

Follow-up to #2260061: Responsive image module does not support sizes/picture polyfill 2.2

We have to decide what we want

1. Use the polyfill and add support for responsive images to as many browsers as possible
2. Use the picture tag and img + srcset to be as compliant as possible

1/ Polyfill

• Most visitors will see a responsive image
• We load extra javascript
• We abuse the srcset attribute on img for the fallback

2/ Plain

• People using an older browser, will only see the fallback.
• We can reduce the amount of javascript
• We output the fallback using the src attribute as it is meant to be

For reference:

• http://caniuse.com/#feat=srcset
• http://caniuse.com/#feat=picture

Current browser status (July 31st 2015):

Picture

• IE and Safari haven't yet started implementing and IE has it Under Consideration

srcset

• IE and Safari is starting to implement srcset

When a migration defines an entity reference and therefor depends upon another 2nd migration which gets run at a later time (thus not enforced via "migration_dependencies: required: ...") the migration will fail if the 2nd migration has Substr as one of the used plugins.

When the migration runs the entity references are created as stubs. The stubs are created creating a Row with only the target_id filled out, the rest of the values are empty. This stub row is then processed by the 2nd migration. When the 2nd migration defines Substr as the plugin for one of the values the Substr plugin will have to process a NULL value and throw MigrateException('The input value must be a string.');

This background-run of the 2nd migration on a stub row to create the entity-reference in the 1st migration effectively fails the whole migration.

The fix is to check for null on $value. If it is NULL then just return $value (NULL) because there won't be anything for Substr to do on NULL.

Problem/Motivation

Our customers frequently have problems with vanishing files. They upload them, then use them somewhere, then embed them and remove that usage again.

The file is then automatically deleted after 6 hours. That timeframe is now configurable and can be disabled completely but that means that we also no longer delete files that were uploaded in forms but never actually used and e.g. replaced again with another file.

This affects users which use file_entity more than most others, as e.g. media_entity has its own entity type and images there are explicitly kept until manually deleted. But it can also happen just with core, especially as we plan to add an actual media library and not just the useless view that we have now :)

Proposed resolution

A better approach could be to allow users to disable that files are automatically deleted when they are no longer used but were used at some point. That's not perfect either, you possibly want some files to be removed, but it seems like a useful start that is pretty easy to implement.

Core currently doesn't allow to manually delete a file or mark it as temporary , so we might need to postpone this issue on that? (file_entity has bulk operations for that, would be easy to move that to core)

Remaining tasks

User interface changes

API changes

Data model changes

Given an entity such as a $node, I have to do this to get the bundle entity:

  $node_type = entity_load($node->getEntityType()->getBundleEntityType(), $node->bundle());

Could we add a method to ContentEntityBase to do this?

Problem/Motivation

Core does not support IE8 anymore. The shiv is not required: http://caniuse.com/html5semantic

The motivation behind it was that core does not support IE8 any longer. If you're building a modern front-end, you'll drop support for IE8 - and maybe even IE9. This means there no need to include html5shiv. When creating a new Drupal 8 theme, html5shiv is always loaded; and it not documented on how to get rid of html5shiv in your theme.

Proposed resolution

The only people affected by the this patch are people who either opt-ed out of stable/classy explicitly with 'base theme: false' or extend our @Internal themes (Bartik and Seven)

Remove this library from core, leave it in Stable.

Remaining tasks

1. Write documentation on how you can remove this library in your theme.
2. Needs to be ported to the ie8 module contrib module,

patches welcome.

Problem/Motivation

D7 had a preserve_files option to trigger this behavior, we don’t have that in D8. This results in really slow migration when you're talking about multiple gigabytes of files.

Proposed resolution

Add a 'reuse' file configuration option. If that flag is set on the file migration, it will attempt to re-use files that are already in the destination with the same name.

Remaining tasks

Code a patch
Review

User interface changes

API changes

Additional process plugin option for file migrations to configure a 'preserve_files' flag.

Data model changes

Problem/Motivation

We are seeing random fails in the first tests run - see https://www.drupal.org/pift-ci-job/477829.

nstall_begin_request
exception: [Uncaught exception] Line 493 of core/includes/install.core.inc:
Drupal\Core\Installer\Exception\AlreadyInstalledException:
To start over, you must empty your existing database and copy default.settings.php over settings.php.
To upgrade an existing installation, proceed to the update script.
View your existing site.
 in install_begin_request() (line 493 of /var/www/html/core/includes/install.core.inc). install_begin_request(Object, Array) (Line: 112)
install_drupal(Object, Array) (Line: 485)
Drupal\simpletest\WebTestBase->doInstall() (Line: 457)
Drupal\simpletest\WebTestBase->setUp() (Line: 33)
Drupal\aggregator\Tests\AggregatorTestBase->setUp() (Line: 1049)
Drupal\simpletest\TestBase->run(Array) (Line: 744)
simpletest_script_run_one_test('29', 'Drupal\aggregator\Tests\DeleteFeedTest') (Line: 65)

This potentially could be related to #728702: Visiting index.php should redirect to install.php if settings.php already has database credentials but database is empty.

Proposed resolution

Remaining tasks

User interface changes

API changes

While running a few Drupal 8.0.x websites we noticed that images added via WYSIWYG editor were gone. After investigation we discovered that file_usage is not correctly incremented when adding a new translation for nodes. And because of that, deleting the image from the translation would mark that images as not used and will be deleted on cron next time it runs.

The easier fix I could find can be seen in the attached file.

Steps to reproduce:

• Add a new (translatable) node and add a image inside body via CKEditor image plugin
• Check file_usage for that file (should be 1)
• Add new translation for that node (save without changing anything)

Expected behavior:
File usage after new translation was added should be 2

Current behavior:
File usage after new translation is still 1.

There is a problem with the autoloader when using two classes with the same name (but a different namespace).

I get a class not found error although the class has been properly listed in the use statements.

When installing Drupal the following error occurs:

Error: Class 'Drupal\migrate\Event\MigrateEvents' not found in Drupal\mymodule\EventSubscriber\MigrationEventSubscriber::getSubscribedEvents()

I have an install profile that enables migrate, migrate_plus, migrate_tools and the following eventsubscriber:

namespace Drupal\mymodule\EventSubscriber;

use Drupal\migrate\Event\MigrateEvents as MigrateEventsCore;
use Drupal\migrate\Event\MigratePostRowSaveEvent;
use Drupal\migrate_plus\Event\MigrateEvents as MigrateEventsPlus;
use Drupal\migrate_plus\Event\MigratePrepareRowEvent;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;

class MigrationEventSubscriber implements EventSubscriberInterface {

  /**
   * {@inheritdoc}
   */
  public static function getSubscribedEvents() {
    $events[MigrateEventsPlus::PREPARE_ROW][] = array('onPrepareRow', 0);
    $events[MigrateEventsCore::POST_ROW_SAVE][] = array('onPostRowSave');
    return $events;
  }
   ...
}

Adding class_exists fixes the issue (as it will try to autoload the class):

    if (class_exists('Drupal\migrate\Event\MigrateEvents')) {
      $events[MigrateEventsCore::POST_ROW_SAVE][] = array('onPostRowSave');
    }

But the class should be autoloaded:

use Drupal\migrate\Event\MigrateEvents as MigrateEventsCore;
use Drupal\migrate_plus\Event\MigrateEvents as MigrateEventsPlus;

Problem/Motivation

Twig 1.25.0 is out. Help contrib - more methods marked deprecated or internal

• deprecated the ability to store non Node instances in Node::$nodes
• deprecated Twig_Environment::getLexer(), Twig_Environment::getParser(), Twig_Environment::getCompiler()
• deprecated Twig_Compiler::getFilename()
• marked the following methods as being internals on Twig_Environment:
  getFunctions(), getFilters(), getTests(), getFunction(), getFilter(), getTest(),
  getTokenParsers(), getTags(), getNodeVisitors(), getUnaryOperators(), getBinaryOperators(),
  getFunctions(), getFilters(), getGlobals(), initGlobals(), initExtensions(), and initExtension()

Changelog

Migrate's source plugin tests are currently kinda...not good.

For one thing, they are all unit tests. This is because that was the fastest way to satisfy the pointless "every patch must have a test" even when there's nothing to test on the majority of source plugins. It's the equivalent of writing "Interface for context" on ContextInterface to check a checkbox (except of course context does need documentation unlike source plugins where the majority still doesn't need a test).

Another problem is that, given the way they're structured, you can only test a single complete data set using a single set of plugin configuration. It's difficult to write very extensive test coverage if, say, you want to test the same plugin under different configurations. In fact, most of the time you need to write a completely new test class for that. Given how configurable source plugins can be, that's far from ideal.

This patch introduces a new pair of base test classes, extending KernelTestBase, for writing better and more comprehensive tests of source plugins. Because they are kernel tests, mocking services is unncessary -- only the migration itself is mocked (prophesized, actually). These classes are built around PHPUnit's dataProvider pattern, which makes it possible to easily test the same plugin many times with radically different data sets and configuration.

Because this introduces completely new test classes instead of altering existing ones, this patch maintains BC and would allow us to migrate the existing source plugin tests to it on a continuing basis. I've ported a single test -- for the d7_user_role plugin -- as proof of concept.

Similarly to #2551453: Follow-up: Consistently use "email" instead of "e-mail" in Drupal and #950534: [policy] Consistently use "email" instead of "e-mail" in Drupal and (the much less trivial: #2560783: Replace !placeholder with :placeholder for URLs in hook_help() implementations and #2566503: [meta] Replace remaining !placeholder for Non-URL HTML outputs only), I have noticed some inconsistencies and grammar mistakes with respect to the use of the acronym, "URL" and the correct article use, e.g. "... an URL alias" should be "... a URL alias".

Also, 'URL' is an acronym, so should consistently be spelled 'URL', not 'url' or 'Url' in text visible in the UI. Ideally, we should also fix this in comments, etc, but good care should be taken to avoid accidentally hitting anything code-affecting (annotations, array keys, etc)

Motivation

Grammar mistakes and spelling inconsistencies in the UI of a software product may not inspire confidence in the product's stability in areas that are more important.

Concerns

I do have serious concerns; I was hesitant to even bother to create a ticket for this for multiple reasons, especially:

• Translation issues: Strings already translated will be orphaned and seen as 'untranslated' in every language that already has the original string translated. Fixing the .po files could be far more tedious than searching out all the places where this "fix" might be "needed"
• Testing issues: Selenium/Webdriver tests may operate in a non-English installation where checkboxes, etc, may be selected by a label (makes tests much more readable) or tests may wait for a confirmation message. But when the label/message changes (back to English, due to lost translations), tests fail. Such tests may just be in various projects, not in core, so updating trivial strings should ideally include fixing .po files at the same time.
• Trivial changes like this tend to cause conflicts when merging other, more important, changes.
• We have plenty of bigger fish to fry.
• Where do we stop?

All that said...

This fits into a larger discussion about how to track trivial string changes to maintain translations in a more automated way. So while I'm hesitant to even suggest we fix this, I want to have this issue available for discussion and (perhaps) as a place to test tracking string changes of this sort. Here, such work as that started by justAChris in #2572771: List translation string changes following replacement of !placeholder and @placeholder and discuss ways to assist translation teams may be helpful. So this issue is meant as an example. String freeze comes with the RC, and a date for that has already been announced, so if we want to fix things like this first, it must happen soon.

Problem/Motivation

When you write a routing.yml file with a _custom_access check which points to a non existing method/class you get the following message:

InvalidArgumentException: The controller for URI "" is not callable. in Drupal\Core\Controller\ControllerResolver->getControllerFromDefinition() (line 81 of core/lib/Drupal/Core/Controller/ControllerResolver.php).
Drupal\Core\Access\CustomAccessCheck->access(Object, Object, Object)
call_user_func_array(Array, Array)
Drupal\Core\Access\AccessManager->performCheck('access_check.custom', Object)
Drupal\Core\Access\AccessManager->checkAll(Array, Object)
Drupal\Core\Access\AccessManager->check(Object, Object, Object, )
Drupal\Core\Access\AccessManager->checkRequest(Object, Object)
Drupal\Core\Routing\AccessAwareRouter->checkAccess(Object)
Drupal\Core\Routing\AccessAwareRo

Its not helpful

Proposed resolution

CustomAccessCheck should catch the InvalidArgumentException and convert it into a new exception
which explains which route / custom access check exactly is broken

Remaining tasks

User interface changes

API changes

Problem/Motivation

You cannot create a view and try to list rendered entities using relationship.

Steps to reproduce:
-Create a view with a relationship through entity reference
-Choose to use rendered entity and try to select relationship for the referenced entity
What happens is Views doesnt render referenced entity

Proposed resolution

Fix it

Remaining tasks

Fix it, by passing along the relationship as needed and using it.

User interface changes

API changes

Problem/Motivation

In D7 you could setup a view to taxonomy/term/% and pass it the term. Internally it loaded the term entity and automatically converted it to the TID itself.

At the same time it had the ability to set the title of the block to be the term name itself.
For some reason this entire functionality, both for users and for terms etc. just disappeared somehow in the meantime.

This appears to still work for page views.

Proposed resolution

• Add it back (if possible in a general way for all entities)
• Add proper test coverage

Remaining tasks

do it!

User interface changes

API changes

Problem/Motivation

Port over cronRun to BTB from WTB. This could be a trait potentially.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes