Quantcast
Channel: Issues for Drupal core
Viewing all 297778 articles
Browse latest View live

Loading a theme into the file system has an inconsistent path

$
0
0

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.


Move instruction and button for loading contributed modules or themes next to each other

$
0
0

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.

Install new module v/s Add new module

$
0
0

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). :)

[meta] Hamonize Extend module/theme-add/update terminology

$
0
0

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

Drupal.ajax does not guarantee that "add new JS file to page" commands have finished before calling said JS

$
0
0

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

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.

Cached entities are loaded again, if $condition is given.

$
0
0

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.

Optimize TaxonomyTermController::cacheGet(), and prevent memory leaks.

$
0
0

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?

InvalidArgumentException "Field is unknown" in ContentEntityBase

$
0
0

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?


PDOException when saving a node on non-English languages

$
0
0

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

Reference: https://www.drupal.org/core/beta-changes
Issue categoryBug because PDOExceptions
Prioritized changesThe main goal of this issue is to fix a bug and reduce fragility of code. The bug also exists in Drupal 7.

Prefer caret over tilde in composer.json

$
0
0

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

User AccountForm.php sets $admin var but doesn't use (PATCH INSIDE)

$
0
0

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 from a URL example refers to out-of-date protocol

Fix description for StylePluginBase::$usesRowPlugin property

Menu subtrees in menu blocks show all subitems regardless of the active menu item

$
0
0

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:
screenshot of 3-level event hierarchical menu

Observed Behavior:

When visiting either "About Event" page, the menu block displays items from Event 1 (active trail) and Event 2 (outside active trail):
menu items visible from outside of 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:
menu items only from active trail

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

Convert web tests to browser tests for user module


ContentModerationState 'workflow' column empty for all non-default translations.

$
0
0

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

Views Rendered Entity from relationship results in fatal error if empty

$
0
0

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.

Symfony\Component\Routing\Exception\MissingMandatoryParametersException: Some mandatory parameters are missing ("node") to generate a URL for route "<current>". in Drupal\Core\Routing\UrlGenerator->doGenerate()

$
0
0

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).

Allow hook_entity_field_access() to grant field-level access to User fields: 'forbidden' -> 'neutral'

$
0
0

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.

Add option for visually-hidden block titles

$
0
0

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

Contributor tasks needed
TaskNovice task?Contributor instructionsComplete?
Create a patchInstructionsDone
Reroll the patch if it no longer applies.InstructionsDone
Add automated testsInstructionsDone
Update the patch to incorporate feedback from reviews (include an interdiff)InstructionsDone
Manually test the patch NoviceInstructionsDone
Embed before and after screenshots in the issue summary NoviceInstructionsDone
Review patch to ensure that it fixes the issue, stays within scope, is properly documented, and follows coding standardsInstructions
  • 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
Viewing all 297778 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>