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

References to CSS, JS, and similar files should be relative to server

$
0
0

References to CSS, JS, and similar files should be relative to the server. Example, in this code:

<link type="text/css" rel="stylesheet" media="all" href="https://drupal.org/files/css/css_1dc04e833f57cb8b13983deeca546394.css" />

Should be:

<link type="text/css" rel="stylesheet" media="all" href="/files/css/css_1dc04e833f57cb8b13983deeca546394.css" />

The attached patch adds a feature to file_create_url() which allows it to create server-relative URLs and puts that feature to work in various core functions.

This change reduces file size, tidies up the code, helps with caching since there does not have to be a different version for HTTP and HTTPS.


In AttachedAssetsTest.php, separate a 3-part test into 3 separate tests

$
0
0

In AttachedAssetsTest.php, testAggregation(), there is a test that tests 3 related things in 1 test. This should be broken up into 3 separate tests to make it easier to figure out what is wrong when the test fails.

format_size() erroneously passes NULL as langcode in options array

$
0
0

Follow-up to #2583041: GD toolkit & operations should check for available memory

Problem

File common.inc, function format_size()

This function either calls:

<?php
\Drupal::translation()->formatPlural($size, '1 byte', '@count bytes', array(), array('langcode' => $langcode));
?>

or:
<?php
    $options = ['langcode' => $langcode];
    ...
    return new TranslatableMarkup('@size ...', $args, $options);
?>

However, the parameter $langcode may be null or absent with a default of null. in which case the $option array contains an entry 'langcode' with a value of null.

Deeper down this leads to:

  • Missing merging in defaults (core\lib\Drupal\Core\StringTranslation\TranslationManager.php:doTranslate():
        // Merge in options defaults.
        $options = $options + [
          'langcode' => $this->defaultLangcode,
          'context' => '',
        ];
  • Checking/assigning key NULL (core\lib\Drupal\Core\StringTranslation\Translator\StaticTranslation.php:getStringTranslation()):
        if (!isset($this->translations[$langcode])) {
          $this->translations[$langcode] = $this->getLanguage($langcode);
        }
  • Checking/assigning key NULL; implicitly converting NULL to string; Missing cache (or even using cache built in another language?) via core\modules\locale\src\LocaleTranslation.php:getStringTranslation() and core\modules\locale\src\LocaleLookup.php:getCid():
        if (!isset($this->translations[$langcode][$context])) {
          $this->translations[$langcode][$context] = new LocaleLookup($langcode, $context, $this->storage, $this->cache, $this->lock, $this->configFactory, $this->languageManager, $this->requestStack);
        }

          $this->cid = "locale:{$this->langcode}:{$this->context}:$rids";

From these examples it may be clear that in Drupal translation:
- A parameter $langcode may be left out or null if explicitly indicated so.
- A parameter $langcode may not be null (or the empty string ) if it is documented as being of type string.
- A key 'langcode' in a $options parameter of type array may be absent but not null.

Errors against this pattern are also found in:
- \Drupal\Core\Datetime\DateFormatter::formatInterval()
- \Drupal\Core\Datetime\DrupalDateTime::format(), formatDiff()
- File system.tokens.inc, function system_tokens(), call to formatTimeDiffSince
- \Drupal\Core\Validation\DrupalTranslator

Proposed resolution

Check for null before creating a key 'langcode' in the options array, leave it absent if null.

Remaining tasks

  • Decide: is this indeed an error in the calling functions or should we make the receiving API's more lax?
  • Do we need to better document this pattern?
  • Write patch for all cases.
  • Review patch.
  • Accept patch.

User interface changes

None.

API changes

None.

Data model changes

None.

Add tests for multiple pagers on a given page

Category matching from source feed

$
0
0

I am trying to import RSS feeds that have categories in the source. I want the information from the source to be reflected in my categories, e.g. if an item with the category "News" is imported it should be added to an existing category of News in my Drupal site. Ultimately, I plan to use views to group the content based on the information from the source feeds.

Question:
- If a source feed item has a category, but no categories are configured in my Drupal site, I assume nothing will happen? Is it possible to configure the aggregator to create categories if they don't exist (tagging style)?
- If a source feed item has a category and the same category exists in my Drupal site, will it match the individual feed item to belong to this category in my Drupal site?

In my test I don't seem to get any of the source categories at all. Is that by design or am I missing a setting somewhere?

Thanks, J.

PHP exception on manage fields after enabling Configuration Translation

$
0
0

Here is the error displayed when trying to access a "manage fields" page on any content type:

Uncaught PHP Exception RuntimeException: "A config mapper can only contain configuration for a single language." at /.../d8_test/core/modules/config_translation/src/ConfigNamesMapper.php line 399

To reproduce on a clean install:
- Install drupal with a different language than english
- Add two languages.
- Enable the 'Configuration Translation' module
- Try to access /admin/structure/types/manage/article/fields

Here are some variables values just before the exception.

<?php
$langcodes = Array ( [0] => fr [1] => en );
$this->pluginId = node_type;
$this->pluginDefinition = Array (
  [title] => type de contenu,
  [names] => Array ( [0] => node.type.article, [1] => core.base_field_override.node.article.title ),
  [weight] => 10,
  [class] => Drupal\node\ConfigTranslation\NodeTypeMapper,
  [base_route_name] => entity.node_type.edit_form,
  [entity_type] => node_type
);
?>

Remove the $langcode parameter in EntityAccessControllerInterface::access() and friends

$
0
0

Problem/Motivation

Per #1953892-24: Move language node access logic into NodeAccessController, as of #1810370: Entity Translation API improvements, an entity translation is also an entity, so the $langcode parameter to the access controller is:
- extraneous, because the $entity parameter that's passed in should already be the desired translation
- confusing, because if the passed in $langcode is different from $entity->language()->id, it's not clear what the expected behavior should be

This issue is critical, because it is required by #1953892: Move language node access logic into NodeAccessController, which is required by #1947880: Replace node_access() by $entity->access(), which is required by #1938318: Convert book_remove_form to a new-style Form object and other places where core or contrib needs to move a route to the new routing system but requires a node_access() check.

Proposed resolution

Remove the parameter. Require calling code to pass in the desired translation, rather than the original entity (or a random translation of it) and a separate $langcode.

API changes

$langcode parameter removed from:

  • EntityAccessControlHandlerInterface::access()
  • EntityAccessControlHandler::checkAccess()
  • NodeGrantDatabaseStorageInterface::access()
  • hook_entity_access()
  • hook_ENTITY_TYPE_access()

This therefore affects all implementations of the interfaces and hooks.

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue categoryTask because nothing is actually broken.
Issue priorityMajor because this affects the whole Entity Access API.
Prioritized changesThe main goal of this issue is reducing fragility by streamlining the Entity Access API and thus improving security by removing the possibility of writing ambiguous code.
DisruptionDisruptive for core, contributed and custom modules because it will require a BC break: the code will need to be adjusted to pass the proper entity translation object instead of specifying a language parameter.

Add @return to theme.inc functions

$
0
0

From what I can tell, none of our theme_*() functions have @return in their documentation, except:

- theme_filter_html_image_secure_image(), which declares a return of void, since that is unusual.
- theme_aggregator_page_opml(), which only received an @return as part of #2039277: Convert aggregator/opml to the new controller style., and there's no comment on that issue explicitly discussing that.

Should we add @return docs to all theme_*() functions, or do something different for them?


Add composer.json to \Drupal\Component\Bridge component.

$
0
0

Parent issue: #2337283: [meta] Add a composer.json file to every component (module, later)

Problem/Motivation

Part of the parent parent issue: #1826054: [Meta] Expose Drupal Components outside of Drupal

Each of the \Drupal\Component\ namespaces need their own composer.json file, so that they can eventually be offered to the world as a library.

Proposed resolution

Add the LICENSE.txt, README.txt, TESTING.txt, and composer.json files from the template in this patch: https://www.drupal.org/node/2337283#comment-9706563

Verify the various dependencies of the component, so they can be included as requirements.

Add the component's directory to \Drupal\Tests\ComposerIntegrationTest:: getPaths().

Use composer validate in the component directory to make sure the composer.json file is valid.

Remaining tasks

User interface changes

API changes

Contributor tasks needed
TaskNovice task?Contributor instructionsComplete?
Create a patchInstructions
Reroll the patch if it no longer applies.Instructions
Update the issue summary noting if allowed during the rcTemplate
Update the patch to incorporate feedback from reviews (include an interdiff)Instructions
Manually test the patch NoviceInstructions
Review patch to ensure that it fixes the issue, stays within scope, is properly documented, and follows coding standardsInstructions

Views field rewrite for "Content: Path" incorrectly escapes HTML

$
0
0

Problem

The rewrite for "Content: Path" says "You may include HTML or Twig." but then it escapes any HTML.

Steps

  1. Create view to show fields for content
  2. Add a "Content: Path" field
  3. Rewrite the field and add HTML
  4. The rewrite incorrectly escapes the HTML

Enabling translation for menu links / taxonomy terms results in "Entity/field definitions" -- "Mismatch detected" on reports/status page

$
0
0

I was able to enable translation for "custom menu link" under Admin => Configuration => Region and Language => Content language and translation.

However, after that, page "admin/reports/status" give an error:

Entity/field definitions: Mismatch detected. Mismatched entity and/or field definitions.

I think this is related to translation, so put it under translation_entity.module component.

Please help.

Thanks.

screenshot 1

screenshot 2

screenshot 3

Remove unused local variable in /core/includes/theme.inc

Fixing typos and docblocks for core/lib/Drupal/Core/Entity

$
0
0

Issue referred from https://www.drupal.org/node/2599524#comment-10490444

  1. +++ b/core/lib/Drupal/Core/Entity/EntityAutocompleteMatcher.php
    @@ -45,13 +45,13 @@ public function __construct(SelectionPluginManagerInterface $selection_manager)
    +   *   Thrown when the current user doesn't have access to the specifies entity.

    Typo:

    specifies -> specified

  2. +++ b/core/lib/Drupal/Core/Entity/Query/Sql/Query.php
    @@ -92,11 +92,11 @@ public function execute() {
    +   *   Thrown if the base table does not exists.
  3. exists => exist

  4. +++ b/core/lib/Drupal/Core/Entity/Query/Sql/Tables.php
    @@ -235,7 +235,9 @@ public function isFieldCaseSensitive($field_name) {

    @@ -235,7 +235,9 @@ public function isFieldCaseSensitive($field_name) {
        * Join entity table if necessary and return the alias for it.
        *
        * @param string $property
    +   *
        * @return string
    +   *
        * @throws \Drupal\Core\Entity\Query\QueryException
        */

    Sigh. This @param and @return need to have docs added to them. Having @param and @return with only a type and no documentation is not OK.

Update upgrading procedure describing in UPGRADE.txt

$
0
0

I was a little confused during upgrade. May be this part
3. Remove all old core files and directories, except for the 'sites' directory and any custom files you added elsewhere.
can be changed to something like
3. Remove all old core files and directories, except for the 'sites', 'modules', 'themes', 'profiles' directories and any custom files you added elsewhere
In these directories (in case not multisite configuration) user can save additional modules/themes. And for me, from UPGRADE.txt not obvious that I should not delete these folders.

Missing sequence types in config schemas

$
0
0

There are 4 cases in core, where the sequence type isn't specified for config schema elements of type "sequence". They were found while scanning them by potx in #2601370: [META] Parsing notices with Drupal 8 RC2.

core/modules/image/config/schema/image.schema.yml

image.effect.image_desaturate:
  type: sequence

core/modules/user/config/schema/user.schema.yml

search.plugin.user_search:
  type: sequence
  label: 'User search'

core/modules/views/config/schema/views.cache.schema.yml

views.cache.none:
  type: views_cache
  label: 'No caching'
  mapping:
    options:
      type: sequence
      label: 'Options'

views.cache.tag:
  type: views_cache
  label: 'Tag based caching'
  mapping:
    options:
      type: sequence
      label: 'Options'

{% trans %} is unable to use URL escaping

$
0
0

Problem/Motivation

In #2565895: Add a new :placeholder to SafeMarkup::format() for URLs that handles bad protocols we added :variable placeholders so that URLs can be secured from bad protocols. However this is not possible in Twig {% trans %}, which has the equivalent of @ and % only.

Proposed resolution

Add a Twig filter and placeholder for {% trans %}.

Remaining tasks

Commit

User interface changes

None.

API changes

A new filter and placeholder for {% trans %}.

Data model changes

None.

Why this should be an RC target

#2565895: Add a new :placeholder to SafeMarkup::format() for URLs that handles bad protocols which introduced this on the PHP side was an RC/release blocking critical. It should have already added support for :placeholder in Twig. Not allowing Twig templates to use the URL filtering like the rest of the Drupal codebase may lead to security issues and translatable string inconsistencies (Eg. a string properly using the :placeholder in PHP will not be reusable in templates because Twig's %trans% lacks support for it).

Unnecessary @param tags & Missing variable names in block, block_content module

$
0
0

Found few functions has unnecessary @param tags

  1. File : core/modules/block/src/BlockViewBuilder.php
    Function : lazyBuilder()
  2. File : core/modules/block/src/Tests/Migrate/d6/MigrateBlockTest.php
    Function : assertEntity()

Few function missing variable name for @param tags.

    File : core/modules/block_content/src/Plugin/Block/BlockContentBlock.php
    Function : __construct()

Fix docs on test without injected drupal_set_message() AggregatorPluginSettingsBaseTest

Fix comment standards for filter module

$
0
0

Fix few minor comment standards for filter module.

data in bulk_form_key should not be separated by -

$
0
0

Problem/Motivation

Investigating a problem with bulk form submissions / actions on a site with a few different languages, we've come across the situation where bulk_form_keys are being generated which look like this:

en-gb-1234

Where 'en-gb' is the language code, and 1234 is the nid.

At present loadEntityFromBulkFormKey explodes the key on '-' and expects to find either two items (langcode and ID) or three items (langcode, ID and vid).

<?php
  protected function loadEntityFromBulkFormKey($bulk_form_key) {
    $key_parts = explode('-', $bulk_form_key);
    $revision_id = NULL;

    // If there are 3 items, vid will be last.
    if (count($key_parts) === 3) {
      $revision_id = array_pop($key_parts);
    }  

    // The first two items will always be langcode and ID.
    $id = array_pop($key_parts);
    $langcode = array_pop($key_parts);
?>

This means that if there's a langcode with a dash in it, the id is mistakenly used as the vid and bad things happen (in this case Drupal was writing rows to the node_field_revision with the nid of the nodes in question set as the value for vid).

Proposed resolution

Assuming that it's valid for langcodes to contain hyphens (which is fairly common), something else should be used as the separator for the bulk_form_key to avoid this situation.

Remaining tasks

Commit.

User interface changes

None.

API changes

None.

Data model changes

None.

Why this should be an RC target

Data is corrupted. As per the problem report: If there's a langcode with a dash in it, then nid is mistakenly used as the vid, so Drupal is writing rows to the node_field_revision with the nid of the nodes in question set as the value for vid.

Viewing all 292913 articles
Browse latest View live


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