Installing a contributed module may be accomplished by going to /admin/modules and clicking the +Install new module button. This takes you to /admin/modules/install.

Installing a contributed theme may be accomplished by going to /admin/appearance and clicking the +Install new theme button. This takes you, not to /admin/appearance/install, but to /admin/theme/install instead. There is no /admin/theme page.

It would be more consistent to either change /admin/theme/install to /admin/appearance/install or else change /admin/appearance to /admin/theme instead.

The instruction and button for loading contributed modules are separated by an instruction that is on a completely different subject. They would best be moved next to each other.

/admin/modules

Currently is ordered as:

Download additional contributed modules to extend your site's functionality.

Regularly review and install available updates to maintain a secure and current site. Always run the update script each time a module is updated.

+Install new module (button)

Would better be ordered as:

Download additional contributed modules to extend your site's functionality.

+Install new module (button)

Regularly review and install available updates to maintain a secure and current site. Always run the update script each time a module is updated.

Justification:

Clicking the button in question cannot be used to install available updates.

/admin/modules

Currently is ordered as:

Download additional contributed modules to extend your site's functionality.

Regularly review and install available updates to maintain a secure and current site. Always run the update script each time a module is updated.

+Install new module (button)

Would better be ordered as:

Download additional contributed modules to extend your site's functionality.

+Install new module (button)

Regularly review and install available updates to maintain a secure and current site. Always run the update script each time a module is updated.

Justification:

Clicking the button in question cannot be used to install available updates.

/admin/appearance

Currently is ordered as:

Set and configure the default theme for your website. Alternative themes are available.

You can place blocks for each theme on the block layout page.

+Install new theme

Would better be ordered as:

Set and configure the default theme for your website. Alternative themes are available.

+Install new theme

You can place blocks for each theme on the block layout page.

Justification:

Clicking the button in question cannot be used to place blocks for each theme.

On the modules page (http://example.com/admin/modules), the action link to add new modules to system reads "Install new module" (see attachment).

The word "install" is synonymous to "enable". At least in the Drupal context : hook_install, .install file all relate to the action of enabling a module.

A better wording here might be "Add new module", with add meaning downloading and adding the module to your Drupal. (then installing it). :)

This is a meta issue to group together issues for various inconsistencise in the Appearance and Extend sections in administration as to how Drupal refers to and provides navigation for bringing contributed modules and themes into the file system. I've assigned this to the user interface text component, as this mostly seems related to what this action is called. However, there is at least one path anomaly as well.

Where I have filed issues on this topic, I am trying to keep the wording to address one particular independent inconsistency. However, if a new wording is agreed upon by the community, it will percolate into the other issues and potetially cause git merge issues between one Drupal issue and another. Thus this meta issue.

The most active discussion on what the terminology ought to be seems to be on #2577407: Module install form has two "install" buttons that do different things, which appears to be a duplicate of #1207354: Install new module v/s Add new module. It covers modules/Extend. However, themes/Appearance have a parallel structure and I believe it would be best if any terminology changes are harmonized across modules and themes.

I've added the following issues which spring from or will be impacted by the resolution to this issue:

#2888652: Move instruction and button for loading contributed modules or themes next to each other
#2888654: Loading a theme into the file system has an inconsistent path

Problem/Motivation

It is impossible to load additional JS libraries in an Ajax response and then call that code through Ajax commands, because Drupal.ajax does not guarantee that the JS library will already have loaded.

See #14 and #15 for details.

Proposed resolution

TBD.

Remaining tasks

TBD.

User interface changes

None.

API changes

TBD

Related Issues

TBD

Original report by [username]

Hi,

Thanks for your module, it works perfect for me.

But I found there one small bug there: if all my .js files are mapped to the external CDN, ajax redirects doesn't execute. After some tests I found that CDN rewrites all js urls, even for ajax. So I attached a small patch that solved this problem for me.

Best regards,
Spleshka.

DrupalDefaultEntityController::load(), on the first attempt to load entities, will
- load the raw entities from the database.
- attach fields and possibly more with ::attachLoad() to the entity objects.

On subsequent calls for the same ids, it will get these entities from the cache in $this->entityCache.
This way, it avoids redundant and repeated database queries and calls to ::attachLoad().

However, if DrupalDefaultEntityController::load() is called with a non-empty $condition array, and $ids === FALSE, then repeated calls to load entities by the same conditions will cause each time cause a query, and call ::attachLoad() for entities that are already in the cache.
The entities built this way are later discarded via $entities += $queried_entities.

Even in a case where both $ids and $conditions are provided, if only one id is missing, then ::attachLoad() will be called for all the entities, even those already in cache.

This can be avoided.

I don't know how common it is to repeatedly load entities by the same conditions.
But in case someone does, fixing this will radically reduce the time of this operation.

TaxonomyTermController::cacheGet() takes more time than it needs to.
The method was showing up as the top offender in xhprof "Excl CPU (microsec)" with 137 ms. This is a very site-specific number, obviously.

The method contains a foreach() loop that checks if the term name really matches.

Main optimization:
- The foreach() loop should only happen if isset($conditions['name']) is true.

Possibly other optimizations:
- drupal_strtolower($conditions['name']) should be taken out of the foreach() loop.
- The term should not be converted to array!
- Maybe build a new array instead of modifying the existing one?

On my very basic Drupal installation (default theme, Croatian/Bosnian/Serbian languages, AddToAny and Social Media Links block extensions) after upgrading from 8.2.6 to 8.3.0-rc1 or rc2 I get:

Got error 'PHP message: Uncaught PHP Exception InvalidArgumentException: "Field is unknown." at /var/www/zakon.link/html/core/lib/Drupal/Core/Entity/ContentEntityBase.php line 509\n

upon accessing a static page. Downgrading to 8.2.7 fixes the problem. This is all that is printed in PHP-FPM log. Any other info I can provide?

Problem/Motivation

I got the following error as I try to save a node when non-English language (Chinese in my case) is enabled. The problem does not exist when English is the default language.
PDOException: 在 dblog_watchdog() (行 157 在 D:\xampp\htdocs\modules\dblog\dblog.module).

When I catch the exception, I found the following issue:
Incorrect string value: '\xE6\x9F' for column 'link' at row 1

The problematic code is:

  Database::getConnection('default', 'default')->insert('watchdog')
    ->fields(array('uid' => $user_uid,'type' => substr($log_entry['type'], 0, 64),'message' => $log_entry['message'],'variables' => serialize($log_entry['variables']),'severity' => $log_entry['severity'],'link' => substr($log_entry['link'], 0, 255), // <----- problematic'location' => $log_entry['request_uri'],'referer' => $log_entry['referer'],'hostname' => substr($log_entry['ip'], 0, 128),'timestamp' => $log_entry['timestamp'],
    ))
    ->execute();

In my case, the link is: 查看

So, substr($log_entry['link'], 0, 255) truncates in the middle of the Chinese characters: 查看.

I tried to reduce the substr length to 200: substr($log_entry['link'], 0, 200), then I don't see the problem.

I don't care about such logs, I'd be happy if it is just caught. But I'm sure there is a nice way to fix it.

To reproduce the issue one can for example store a node with a long URL alias including non-standard characters. You can use some of the Chinese characters above or just this exact URL alias:

åååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååå

Proposed resolution

See patch.

Remaining tasks

User interface changes

API changes

Beta phase evaluation

Problem/Motivation

In our composer we use ~ often. In the composer doc is says that the caret:

is the recommended operator for maximum interoperability when writing library code.

Furthermore when there is a patch release for a dependency which we'd like to help ensure users using composer to manage their project's dependencies get this will help them. See #2768953: Prevent insecure Guzzle from being installed when using composer to manager your project dependencies.

Proposed resolution

Change composer dependency versions to ^1.2.3 style using the caret. This would also allow for users managing their own dependencies to update to later minor versions when needed (outside of core releases).

Remaining tasks

• Decide if we want to adopt ^1.2.3 style versioning
• Patch composer.json to adjust

User interface changes

n/a

API changes

n/a

Data model changes

n/a

On line 72 of: core/modules/user/src/AccountForm.php it sets:
$admin = $user->hasPermission('administer users');
then it uses it in several places, but misses opportunity in 2 other places, and just calls the hasPermisison() method again instead.

Patch in next comment. This is against 8.3.x, but I can also roll one for 8.4.x if I need to.

Install new module page /admin/modules/install reads:

For example: http://ftp.drupal.org/files/projects/name.tar.gz

Drupal.org hasn't used that protocol for some time. The text would better read:

For example: https://ftp.drupal.org/files/projects/name.tar.gz

https://api.drupal.org/api/drupal/core%21modules%21views%21src%21Plugin%...

Current description is confusing.

Does the style plugin allows to use style plugins.

It appears that the description was copied to some derived plugins (Table).

Problem/Motivation

When visiting a page which belongs to a child menu tree, menu block displays other trees on the same level, from different parents, when the parents are set to expanded and the starting level is greater than 1.

E.g. using the following menu hierarchy:

Observed Behavior:

When visiting either "About Event" page, the menu block displays items from Event 1 (active trail) and Event 2 (outside active trail):

Expected behavior:

When the user sets the menu block to level 2, they to see menu items from the active trail only:
Screenshot of expected behavior:

Proposed resolution

• If menu block level is greater than 1, show only the menu items along the active menu trail, regardless of "expanded" settings on other menu trails.
• For menu items with starting level > 1, remove the ability to show a fully-expanded menu tree

Remaining tasks

Improve the UI text which explains what the "Expanded" option means on the menu block configuration.
For menu items with level > 1, "Expanded" means "show all children of this menu item, only if this menu item or one of its children is in the active menu trail"

API changes

N/A

See #2735005: Convert all Simpletest web tests to BrowserTestBase (or UnitTestBase/KernelTestBase)

Conversion scope

All except: #2887869: Convert web tests to browser tests for user module part-2
- UserAdminSettingsFormTest
- UserPasswordResetTest
- UserBlocksTest
-UserRegistrationTest

Problem/Motivation

If I run the multilingual moderation test and look at the database after, I get something like the following:

mysql> select langcode,revision_id,workflow,moderation_state from test89968991content_moderation_state_field_revision ORDER BY langcode;
+----------+-------------+-----------+------------------+
| langcode | revision_id | workflow  | moderation_state |
+----------+-------------+-----------+------------------+
| en       |           1 | editorial | draft            |
| en       |           2 | editorial | draft            |
| en       |           3 | editorial | draft            |
| en       |           4 | editorial | published        |
| en       |           5 | editorial | published        |
| en       |           6 | editorial | published        |
| en       |           7 | editorial | draft            |
| en       |           8 | editorial | draft            |
| fr       |           1 | NULL      | draft            |
| fr       |           2 | NULL      | draft            |
| fr       |           3 | NULL      | published        |
| fr       |           4 | NULL      | published        |
| fr       |           5 | NULL      | draft            |
| fr       |           6 | NULL      | published        |
| fr       |           7 | NULL      | published        |
| fr       |           8 | NULL      | draft            |
+----------+-------------+-----------+------------------+

'workflow' is defined as a translatable field, so when the translation is added, the workflow isn't copied from the source language.

Proposed resolution

Either:

• Make workflow non translatable (why is it in the first place?)
• Copy the workflow field from the source translation to the new, when creating the entity.

Remaining tasks

Agree, patch.

User interface changes

API changes

Data model changes

Steps to reproduce:

1. Create a user view
2. Add relationship "Content authored"
3. Add field 'Rendered entity - content'
4. Save the view
5. Make sure there is no content for the user(s)

Expected behaviour:
I expected the same behaviour as other fields which are empty.

What happens:
A fatal error is thrown. This is because in Drupal\views\Plugin\views\field\RenderedEntity::render getEntityTranslation is called with a NULL value.

Proposed solution:
I created a patch that checks whether getEntity is not empty. This probably needs testing, but I need this for a project I am working on right now.

I found this error in my watchdog list:

Symfony\Component\Routing\Exception\MissingMandatoryParametersException: Some mandatory parameters are missing ("node") to generate a URL for route "". in Drupal\Core\Routing\UrlGenerator->doGenerate() (Zeile 180 in /xxx/xxx/xxx/www.xxx.com/core/lib/Drupal/Core/Routing/UrlGenerator.php).

Referrer:http://www.xxx.com/node/index.php

If I call this URL in a webbrowser I get a blank page with this message:

Symfony\Component\HttpKernel\Exception\NotFoundHttpException: No route found for "GET /node/index.php" (from "http://www.xxx.com/de/admin/reports/dblog/event/17642") in Symfony\Component\HttpKernel\EventListener\RouterListener->onKernelRequest() (line 176 of vendor/symfony/http-kernel/EventListener/RouterListener.php).

Background
In D8 the default access settings are simple: there is a single 'administer users' permission that controls editing other users.

More complex schemes are possible using contrib modules to allow selective editing of other users under certain conditions. An example of such a module is Administer Users by Role. I am the maintainer of this module, trying to port it to D8.

Problem
contrib modules cannot grant field-level access to some fields on the user. For example, in a view of users, the "status" column will not be present except to a user with 'administer users' permission.

• The code in the contrib module can implement hook_ENTITY_TYPE_access() for entity type "user" which works to allow editing of the user.
• The code in the contrib module can implement hook_entity_field_access, but this doesn't work because the default code in UserAccessControlHandler has set AccessResult::forbidden().

The documentation here states

Note: Even a single module returning an AccessResultInterface object from hook_node_access() whose isForbidden() method equals TRUE will block access to the node. Therefore, implementers should take care to not deny access unless they really intend to. Unless a module wishes to actively forbid access it should return an AccessResultInterface object whose isAllowed() nor isForbidden() methods return TRUE, to allow other modules or the node_access table to control access.

Solution
UserAccessControlHandler should set AccessResult::neutral. This prevents access by default, but allows other modules to override.

The password field is an exception because it should be forbidden for any user to read it under any circumstances.

Patch coming.

Problem/Motivation

Block titles can currently be displayed or hidden by site-builders. When hidden, the heading element is omitted from the HTML entirely. Hiding titles might be desirable for a visual design, however block titles can be useful for visually impaired users, providing contextual clarity and navigational cues via screenreaders.

Proposed resolution

Add another option in block configuration, to output visually-hidden block titles, with a "visually-hidden" class.
In D7 this functionality is provided by the a11y_titles module.

We have already added equivalent functionality to D8 for the FieldAPI label display. Offering visually-hidden block titles will extend the options available for site builders to fine-tune the page structure.

Before

After

Remaining tasks

• Usability review: this accomodates an additional option by replacing a checkbox with a select element, similar to the label display for field formatters.
• Documentation: explain the visually-hidden option on the block help page?
• Update settings form in \Drupal\Core\Block\BlockBase::buildConfigurationForm()
• Update HTML output in block module, adding "visually-hidden" class to title_attribute twig variable via template_preprocess_block. The block twig template does not need to be changed.
• Update block settings config schema. Not necessary - block_settings.label_display is already type: string, not boolean.
• Update installation config in core profiles/modules, changing block_settings.label_display values of '0' to explicit 'hidden'. It would be a BC break so keep the '0' value for hidden titles.
• hook_update(). Change block_settings.label_display values of '0' to explicit 'hidden'. Not usefull anymore (see previous)
• Write tests.
• Some blocks have custom behaviour, e.g. menu blocks already have visually hidden titles, and Bartik uses it's own CSS to hide block titles in the header region. Come up with an approach for these - we might be able to remove custom templates and CSS, relying instead on installation config. Should be done in follow-up issues.

User interface changes

Block title display option changes from a boolean checkbox option to 3 options in a select element: Visible, Visually Hidden, Hidden.
Aim for consistency with the Field API options in entity manage-display settings.

Also descriptive help text may change (D7 a11y_titles module says "Block titles can provide context to users who can’t rely on visual cues").

API changes

None expected.

Data model changes

We are introducing a third option to Block title display: 'visually-hidden'. Effect on data model are as follows:

• Config Schema: NO CHANGE. While we are introducing an additional option ('visually-hidden') for the core data type block_settings.label_display, this is already of type: string, which accommodates all proposed values (visible, visually-hidden, hidden).
• Installation Config: CHANGED. Block configuration files in config/install folders will need to be updated, changing block_settings.label_display values of '0' to explicit 'hidden'. Removed for BC
• Existing Sites' Config: UPDATE HOOK required, changing block_settings.label_display values of '0' to explicit 'hidden'. Removed for BC