Problem/Motivation

#2863819: Convert theme hooks (defined by hook_theme()) to be objects provides a new API for writing hook_theme() implementations.
It changes the consumers of hook_theme(), but not the implementations themselves.

Proposed resolution

Convert hook_theme() implementations
Example from block_theme():

Before

  return [
    'block' => [
      'render element' => 'elements',
    ],
  ];

After

  return [
    ThemeHook::create('block')
      ->setRenderElement('elements'),
  ];

Remaining tasks

Convert all implementations
Add extensive test coverage of array-based examples for BC reasons

User interface changes

API changes

Data model changes

Problem/Motivation

DX of creating hook_theme implementations in a hook is not good.

Also, it is difficult for themers to find the contents of these functions. The plan has been that themers shouldn't have to read any PHP if possible.

Furthermore, themes could be declared in the same way as layouts in the layout api module, giving the ability to declare aditional themes (see block styles module as example) and aditional information for example as thumbs for a richer administration UI.

Proposed resolution

Move into configuring hook_theme implementations inside yml. That would be a self-documenting way to specify contents of hook_theme implementations. This would be especially powerful in combination with #2809683: Make it required to specify variables passed to templates.

Deprecate hook_theme from Drupal 8 and mark it to be removed from Drupal 9.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/motivation

Improve Drupal’s current theme system by making templates more re-usable and fixing major TX issues. This is parallel issue for #1804488: [meta] Introduce a Theme Component Library and #2702061: Unify & simplify render & theme system: component-based rendering (enables pattern library, style guides, interface previews, client-side re-rendering). This plan tries to achieve similar goals but by evolution instead of revolution.

Plan

Phase A (Target 8.3.x)

1. #2818121: Create render array generator that can be used in Twig
   • To expose component templates for the theme system, it should be as easy as possible to load templates using the theme system (with preprocess and such, instead of using Twig includes).
2. #2809689: Move hook_theme implementations into yml
   • We should convert theme hooks to YML so that frontend developers are not forced to write PHP in order to create a new template.
3. #2809679: Add versions for render arrays
   • To allow making changes for the render- and theme system we have to be able to make BC breaking changes.
4. #2809675: Convert contextual_preprocess to #post_render
   • This issue helps us understand how to work around modules that currently depend on preprocess functions.

Phase B (Target 8.4.x)

1. #2809683: Make it required to specify variables passed to templates
   • Enforce that all theme hooks must have variables defined. This is required to make all theme hooks reusable. Use render elements as render array generators instead of preprocess.
2. #2821376: Allow extending theme implementations
   • Add new key ‘extends’ for theme implementations to allow additions for pre-existing theme implementations in yml.
3. #2809691: Make it possible to add libraries inside hook_theme implementation
   • Allow attaching libraries to theme implementations. This would essentially allow us to automatically attach libraries for templates without using preprocess or attach_library() in Twig.
4. #2714509: Remove usages of #theme_wrappers
   • #theme_wrappers are confusing and definitely a Drupalism. Try to get rid of them if possible since nested render arrays could be always used.

Part of #2571965: [meta] Fix coding standards in core.

Approach

We are testing coding standards with PHP CodeSniffer, using the Drupal coding standards from the Coder module. Both of these packages are not installed in Drupal core. We need to do a couple of steps in order to download and configure them so we can run a coding standards check.

Step 1: Add the coding standard to the whitelist

Every coding standard is identified by a "sniff". For example, an imaginary coding standard that would require all llamas to be placed inside a square bracket fence would be called the "Drupal.AnimalControlStructure.BracketedFence sniff". There are dozens of such coding standards, and to make the work easier we have started by only whitelisting the sniffs that pass. For the moment all coding standards that are not yet fixed are simply skipped during the test.

Open the file core/phpcs.xml.dist and add a line for the sniff of this ticket. The sniff name is in the issue title. Make sure your patch will include the addition of this line.

Step 2: Run the test

Now you are ready to run the test! From within the core/ folder, run the following command to launch the test:

$ composer run phpcs -- -p

This takes a couple of minutes. The -p flag shows the progress, so you have a bunch of nice dots to look at while it is running.

Step 3: Fix the failures

When the test is complete it will present you a list of all the files that contain violations of your sniff, and the line numbers where the violations occur. You could fix all of these manually, but thankfully phpcbf can fix many of them. You can call phpcbf like this:

$ composer run phpcbf

This will fix the errors in place or composer will tell you that Script phpcbf --standard=core/phpcs.xml.dist --runtime-set installed_paths $($COMPOSER_BINARY config vendor-dir)/drupal/coder/coder_sniffer -- handling the phpcbf event returned with error code 1 meaning there was no files fixed and you need to fix them manually. You can then make a diff of the changes using git. You can also re-run the test with phpcs and determine if that fixed all of them.

Updated: Comment #47

Problem/Motivation

First the setup to recreate this problem:

- A sub theme set to the Admin theme
- Another sub theme (with same base theme as admin theme) set as the main front end theme
- Both sub themes have custom theme settings

When changing the theme settings for the front end theme, they are saved and take effect, however when the settings page reloads all the settings for the admin theme are loaded instead, not the front end themes settings.

To show this clearly please watch this video.

--

@bfroehle summarizes the problem technically in #2:

The theme settings pages are built by system_theme_settings(). This function generates the form by running THEME_system_theme_settings_alter() for the theme you are trying to edit, as well as all of that theme's parents. In each case, $GLOBALS['theme_key'] is set to the name of the theme we're trying to edit.

After the form is initially built, we reset $GLOBALS['theme_key'] to the name of the administration theme, and finish processing the form by calling drupal_alter() which then calls THEME_system_theme_settings_alter() and overwrites the correct sub-theme values.

Proposed resolution

We need to move away from the drupal_alter() namespace in this case as form alter hooks are the main cause of this issue.

Remaining tasks

1. There is a patch attached to comment #43 that needs help to get passing tests

User interface changes

N/A

API changes

@JohnAlbin provides a good explantion of the API changes in #34

As discussed in https://drupal.org/node/1164790 if we rename system_theme_settings() to system_theme_config() and THEME_form_system_theme_settings_alter() to THEME_theme_config() (That would also make the module's hook alter be hook_form_system_theme_config_alter().)

Related Issues

N/A

Problem/Motivation

In Drupal 8 we've been working to remove 'magic array keys'. But we still have render arrays, which everytime you use them cause you to need to look-up the allowed keys.
This is bad for DX.

Proposed resolution

Provide builder classes for each element type to make defining render arrays discoverable from IDEs
before

$variables['table'] = array(
    '#type' => 'table',
    '#header' => $headers,
    '#rows' => $rows,
    '#attributes' => array(
      'id' => $table_id,
    ),
    '#tabledrag' => array(
      array(
        'action' => 'order',
        'relationship' => 'sibling',
        'group' => $weight_class,
      ),
    ),
  );

after

$variables['table'] = TableElement::create()
    ->setHeader($headers)
    ->setRows($rows)
    ->setAttributes(array(
      'id' => $table_id,
    ))
    ->setTableDrag(array(
      array(
        'action' => 'order',
        'relationship' => 'sibling',
        'group' => $weight_class,
      ),
    ))->toRenderArray();

Borrows heavily from both Url helper and FieldDefinition stuff.

Remaining tasks

Review

User interface changes

None

API changes

Creates a new optional way to create render elements.

Problem/Motivation

When creating a view for a Payment Method in Drupal Commerce, the View will die on save if it has a bundle ViewsFilter plugin. Configuring the form is fine, and so is the preview. However, upon save the following exception is unhandled

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "" entity type does not exist. in Drupal\Core\Entity\EntityTypeManager->getDefinition() (line 133 of /var/www/html/web/core/lib/Drupal/Core/Entity/EntityTypeManager.php).

That is because the bundle plugin assumes the entity bundle type is always an entity with a relation value, instead of just a string value.

Proposed resolution

Check if getBundleEntityType is null before attempting to retrieve its storage.

Remaining tasks

• Create a test
• Create a patch

User interface changes

None

API changes

None

Data model changes

None

When viewing a layout in Umami profile (even with Bartik as theme) then the pencil icon to modify already placed blocks does not show up.

I'm tagging this as layout.module issue initially in case someone thinks it might have wider implications than Umami.

Problem

Drupal\Core\Template\Attribute has become a bit of a God class with too many responsibilities. Move CSS Class parsing code off to its own class and apply some speed improvements to the logic of the class.

Issue History Note

This issue ticket was began over two years ago with the Twig rendering system. There are references in the older patches to Twig Environment and the then concurrently being developed assertion system. As of the most recent patch these references are removed. This issue thread is maintained for needed context for the code reviewers. The remaining Twig issues have their own issues.

<?php

use Drupal\Core\Template\Attribute;

require_once 'autoload.php';

function providerTestAttributeData() {
  return [
    ['&"\'<>' => 'value'],
    ['title' => '&"\'<>'],
    ['class' => ['first', 'last']],
    ['disabled' => TRUE],
    ['disabled' => FALSE],
    ['alt' => ''],
    ['alt' => NULL],
    [
      'id' => 'id-test',
      'class' => ['first', 'last'],
      'alt' => 'Alternate',
    ],
    [],
  ];
}

$startTime = microtime(true);
// Your content to test
$attributesData = providerTestAttributeData();
for ($i=0; $i < 10000; $i++) {
  foreach ($attributesData as  $attributes) {
    // Convert array to attribute object.
    $attribute = new Attribute($attributes);
    // Change Attribute.
    $attribute->addClass(array('orange', 'blue'));
    $attribute->removeAttribute('id');
    // Cast to string.
    $value = (string) $attribute;
  }
}
$endTime = microtime(true);
$elapsed = $endTime - $startTime;

echo "Execution time : $elapsed seconds";

Problem/Motivation

Conceptually, the discovery of theme functions and templates is part of the Theme Registry. In actuality, the two discover functions (drupal_find_theme_templates() and drupal_find_theme_functions()) are still in theme.inc and portions of them call the Theme Registry service.

The practical implication is that extending/modifying template discovery is much harder with these procedural functions.

Proposed resolution

• Create methods on the theme registry service for finding theme templates and theme functions.
• Have the procedural functions to nothing more than wrap the service.

Remaining tasks

Mark functions as deprecated?
Update interface?

User interface changes

None

API changes

Mark the procedural functions as deprecated?

Data model changes

none

Modules dealing with themeable HTML email including simplenews and swiftmailer need a way to consistently and reliably perform rendering using a predetermined theme, regardless of the other things going on in the environment that invoked the mailer (such as call via cron, drush, or URL path having admin as the active theme)

As an experimental solution, I wrote a patch for simplenews that defined another service backed by Drupal\Core\Render\Renderer so that I'd have another instance of Renderer to use for the email content rendering. I was free then to just configure in the yml for it to get a ThemeManager that used Drupal\Core\Theme\DefaultNegotiator -- so my Renderer instance was being told always to use the site's default theme, without regard to things like invoking path.

But I found some small issues in the Registry and ThemeRegistry classes, mostly that ThemeRegistry gets a Registry instance always by direct \Drupal::service('theme.registry'); and that one will pull templates from whatever the active theme is.

I'm including a patch intended to non-disruptively enhance ThemeRegistry / Registry to handle use cases such as described where setting up a separate rendering path from the primary one for page output is needed.

Follow-up to #2652834: [D7] Allow the use of callbacks instead of global functions in theme processor functions

Problem/Motivation

Theme preprocessor callbacks cannot be callables because the code checks function_exists():

Proposed resolution

Use is_callable() instead of function_exists().

Remaining tasks

Review

User interface changes

None

API changes

None.

Data model changes

None

Problem/Motivation

Over in #2962110-39: Add the Media Library module to Drupal core, we discovered that there is an accessibility problem with the entity operation drop-buttons exposed by Views. Namely:

The entity operations (dropbutton) links are [a] problem ... users need to know which media item they apply to. Just like bulk-ops checkbox, the dropbuttons currently get context from the HTML table row structure. But in the new grid, the dropbutton is outside of the rendered entity's <article> wrapper.

There's already an issue to address this in EntityListBuilder, but the dropbuttons in the new media library actually come from the EntityOperations views field plugin.

Proposed resolution

Change the EntityOperations plugin so that the label of the entity is embedded in a way that will be visible to assistive technology.

Remaining tasks

Write a patch, write tests, get the accessibility team's blessing, and commit.

User interface changes

Entity operation drop buttons in views may change when seen by screen readers, etc. A Views plugin may receive new administrative UI options.

API changes

TBD;

Data model changes

None anticipated.

Follow-up to #2208429: Extension System, Part III: ExtensionList, ModuleExtensionList and ProfileExtensionList, which provides new extension listing classes ExtensionList, ProfileExtensionList, ModuleExtensionList.

Problem/Motivation

Due to the size of the theme list refactoring scope, we need a separate issue.

Proposed resolution

Create new ThemeExtensionList and ThemeEngineExtensionList classes, refactor theme discovery functionality into this class.

Remaining tasks

Patch
Reviews
Commit

User interface changes

None

API changes

1. ThemeHandler constructor has new argument $theme_list of type ThemeExtensionList but is an optional argument. Service signature not changed in core.services.yml.
2. ThemeInstaller constructor has new argument $theme_list of type ThemeExtensionList but is an optional argument. Service signature not changed in core.services.yml.
3. New ThemeExtensionList class and extension.list.theme service. Class marked internal.
4. New ThemeEngineExtensionList class and extension.list.theme_engine service. Class marked internal.
5. The ModuleExtensionList and ProfileExtensionList classes also marked internal.
6. The protected $defaultFeatures class property removed from ThemeHandler
7. The protected $extensionDiscovery class property removed from ThemeHandler

Data model changes

None.

Problem/Motivation

This is a child issue of #2949363: Impossible to make deprecated trait without fails

In that issue we discovered that we can't perform test discovery on files which @trigger_error() for deprecation.

These include abstract classes, such as base classes and traits.

The problem: Reflection loads the file, which triggers the deprecation error whether the class is used or not in any test.

In #2296635: Evaluate performance impact of limiting test discovery to *Test.php filename suffix we considered excluding all files from scan except for *test.php files. This presents BC problems because it could lead to false positives for the unaware.

Proposed resolution

Modify TestDiscovery to exclude reflection on files which end in TestBase.php or Trait.php.

Remaining tasks

User interface changes

API changes

Data model changes

Currently the links on the dropdown aren't saying which items are to be edited / enabled / etc. Those labels should really contain some visually-hidden text that provides that context verbally.

Followup for #2946419-9: Entity: Convert system functional tests to phpunit

Problem/Motivation

It is impossible to make a deprecated trait without fails of tests with 'simpletest' module dependency.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

This is a follow up from #2938194: Focus styles should meet accessibility guidelines in Umami theme

===
Underlines are best for indicating the presence of a link at all, in their resting style, especially inside sentences. The footer links would be better with an underline to distinguish them from nearby text, so they'll need an outline focus style.
===

Blocked by: #2853509: Don't render status messages if there are no messages but also include their assets if there might be

Problem/Motivation

Provide a consistent method for displaying messages in JavaScript.

Currently the Settings tray module needs to provide various message via JavaScript in:
#2773601: Display "You are now in edit mode" prompt when user enters edit mode
#2785047: In Outside In mode, form validation messages should appear in the off-canvas tray, not the main page

And also Inline Form Errors needs to be able to update messages through JavaScript:
#2876321: Update inline form errors summary after form validation with AJAX

Proposed resolution

Change div for {{ messages }} to always be rendered and add a data-drupal-messages attribute for JavaScript to select.

Add new methods for:

• Adding a message
• Removing one or multiple messages
• Clearing all messages of a specific type
• Clearing all messages

How to test manually

1. Apply the latest patch
2. Install standard
3. Install the js_message_test module. You need to ensure $settings['extension_discovery_scan_tests'] = TRUE; is in your settings.php in order to enable it.
4. Visit the url /js_message_test_link on your site.

Remaining tasks

Review patch
Write change record

API changes

Persistent div for {{ messages }} would be required in themes.

API Additions

const messageInterface = new Drupal.Message();

const messageId = messageInterface.add(message, options);
const messageList = messageInterface.select(type);

messageInterface.remove(messageId);

messageInterface.clear();

Original report by kkaefer

While developing some JavaScript enhancements for Drupal, I am facing the problem of how to indicate the status of an action properly. For example, when editing a label, the user needs to know if the action has been successful (saving the new title) or if it failed. Of course, some widgets can use their own status indicating system (like the autocomplete textfield), but others have to display text.

But – we already have status messages in Drupal! Take a look at theme_status_message(). We just need to make sure that the status message div is always there so that we can inject new items via JavaScript... How about that? Post your opinion or your own suggestion for this issue.

In Umami theme login link not showing underline on hover. All other links are underlined on hover e.g: the main menu, footer links are underlined on hover.