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

Creating an context object for an entity that is being deleted causes a fatal error

$
0
0

Problem/Motivation

function foo_entity_delete(EntityInterface $entity) {
  $context = EntityContext::fromEntity($entity);
}

This will fail.

Introduced in #2791269: Allow saving pre-existing references to inaccessible items

Proposed resolution

If \Drupal\Core\Entity\Plugin\Validation\Constraint\ValidReferenceConstraintValidator::validate() can't load the unchanged entity from the DB (because it no longer exists), use the one we have

Remaining tasks

N/A

User interface changes

N/A

API changes

N/A

Data model changes

N/A


What is the composer command to install Drupal 8 core?

Migrate D7 vocabulary language settings

$
0
0

Problem/Motivation

This is a D7 follow-up to #2975509: Migrate D6 vocabulary language settings.

Drupal 7 contributed i18n_taxonomy module provides multilingual capabilities to taxonomies. The vocabulary setting page has the following options when i18n_taxonomy is enabled:
Multilingual vocabulary options screenshot

The 'language' field of the vocabulary is only available in D7 when the 'Fixed language' option has been selected. In the Fixed language scenario this language is defaulted to all terms that are created to this vocabulary and the user can't change the language of the term.

D7 data source

The multilanguage mode is stored in D7 database in taxonomy_vocabulary.i18n_mode. Values are as follows:

  • 0: No multilanguage options for terms.
  • 1: Localized terms.
  • 2: Fixed language.
  • 4: Translated terms.

Vocabulary default language is stored in D7 database in taxonomy_vocabulary.language.

'Localized terms' concept

The data model in D7 is illustrated in the picture below.
D7 'localized' concept

  • The node translations are separate nodes but they are both pointing to the same term.
  • There is only one term entity, but the title and description of the term can be translated in D7.

The D8 equivalent to this concept is shown in the picture below.
D8 shared term with translations

D7 'Translated terms' concept

The data model in D7 is illustrated in the picture below.
D7 'translated terms' concept

  • The node translations are separate nodes.
  • There are two separate term entities which may be linked together as translations of each other but the translation link does not necessarily exist.

The closest D8 equivalent to this concept is shown in the picture below.
D8 separate terms

  • There is a conceptual difference between D7 and D8.
  • In D7, the different taxonomy term entities can be linked as translations of each other but in D8 they can not be linked like in D7.
  • The data model described in the picture above is the closest equivalent in D8.

D8 vocabulary settings

The D8 vocabulary settings are shown in the picture below.
D8 vocabulary settings

The 'Term language / Default language' corresponds to the D7 vocabulary language which is used in D7 when using the 'Fixed language' setting for terms.

Note that the vocabulary itself has a language in D8. This is not related to the D7 language settings, the 'Language' field of D8 can be used to indicate the language of the vocabulary so that the vocabulary name and description can be translated.

Proposed resolution

Common mapping to all multilingual modes

  • D8 Term default language: Migrate from D7 vocabulary language if it is set. Otherwise migrate to site default language.
  • Note: this does not impact the language of the terms to be migrated, only new terms that will be created in D8.

D7 'No multilingual options for terms' setting

  • D8 'Show language selector on create and edit pages': FALSE
  • D8 'Enable translation': FALSE.
  • D8 content type field settings for the term reference 'Users may translate this field': FALSE

D7 'localize terms'

  • D8 vocabulary 'Show language selector on create and edit pages': TRUE
  • D8 vocabulary 'Enable translation': TRUE
  • D8 content type field settings for the term reference 'Users may translate this field': FALSE

D7 'translated terms'

  • D8 vocabulary 'Show language selector on create and edit pages': TRUE
  • D8 vocabulary 'Enable translation': FALSE (This is because the terms are per language)
  • D8 content type field settings for the term reference 'Users may translate this field': TRUE

D7 'fixed language'

  • D8 'Show language selector on create and edit pages': FALSE
  • D8 'Enable translation': FALSE.
  • D8 content type field settings for the term reference 'Users may translate this field': FALSE

Remaining tasks

1. Patch
2. Add tests.
3. Review.
4. Commit

User interface changes

N/A

API changes

N/A

Data model changes

N/A

[META] Stabilise Migrate Drupal Multilingual module

$
0
0

Problem/Motivation

Migrate multilingual data from D6 and D7.

Proposed resolution

D6 migration and much of D7 is working so use those migrations, and their plugins as models for these migrations. It is preferred to improve the existing destination plugins instead of creating new ones.

Remaining tasks

Because D6 is nearing end of life, the D6 multilingual migrations are the highest priority as shown in the list below.

Top Priority

High priority - remaining content migrations

Multilingual taxonomies / content migrations

Comments

Medium Priority

Low Priority

Support category field in Views RssFields row plugin

Fix "Drupal\system\Plugin\views\field\BulkForm is deprecated in Drupal 8.5.x, will be removed before Drupal 9.0.0. Use \Drupal\views\Plugin\views\field\BulkForm instead." deprecation error

$
0
0

Problem/Motivation

Child issue of #2959269: [meta] Core should not trigger deprecated code except in tests and during updates

We currently ignore the "Drupal\system\Plugin\views\field\BulkForm is deprecated in Drupal 8.5.x, will be removed before Drupal 9.0.0. Use \Drupal\views\Plugin\views\field\BulkForm instead. See https://www.drupal.org/node/2916716." deprecation error.

Quit ignoring it, and fix deprecated usages.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Notice: Undefined index: #default_value in Drupal\Core\Datetime\Element\Datetime::valueCallback() (line 103

$
0
0

Fix for this

Go to Drupal installation folder and following core lib file.
core\lib\Drupal\Core\Datetime\Element\Datetime.php

On line 103 make necessary changes to look like this.
$date = isset($element['#default_value']) ? $element['#default_value'] : null;
if ($date !=null && $date instanceof DrupalDateTime && !$date->hasErrors()) {

I don't know how to commit, so posting here if someone can help in committing this i really appreciate that.

Thanks,
Shah.

Usability Issue - Block configuration form

$
0
0

Visibility controls in Blocks configurations form are missing help text in Drupal 8 .
We had this help text in Drupal 7 (Which actually helps non-tech User in understanding the feature)
PFA - Screengrab for reference

I propose to have it added for 'Content type'& 'Roles' Visibility controllers.

Cheers,
SwapS


user_schema() reports uid as primary key for the user_data table when it's just part of the primary key

$
0
0

API page: https://api.drupal.org/api/drupal/core%21modules%21user%21user.install/f...

The description given for the uid field in the user_data table is the following.

'description' => 'Primary key: {users}.uid for user.'

It is not the primary key, since that is the following.

'primary key' => ['uid', 'module', 'name']

It should be described similarly to how nid is described for the node_access table. (See https://api.drupal.org/api/drupal/core%21modules%21node%21node.install/f....)

'description' => 'The {node}.nid this record affects.'

When content language detection is different from interface language detection, the detected language is not applied to the rendered content

$
0
0

Problem

When setting language detection method, the checkbox Customize Content language detection to differ from User interface text language detection settings is not applied, only the interface configuration.

This leads to two critical issues with translating content:

  1. It is not possible to edit translated version of a node. All "Edit" urls on node's "Translate" tab are the same and lead to main editing form. See edit.png.
  2. Translated content is never shown to the user. Default language is always displayed.

Steps to reproduce

On a fresh D8 install:

  1. Enable content translation and language modules
  2. Add another language
  3. Set Detection and selection method to session and browser (tested both, both are broken)
  4. Configure content type "Article" to be translatable (Administration >> Configuration >> Regional and language)
  5. Add a node and set it's language to default one (I used article with image. All fields were filled including image)
  6. Translate node to a second language and save.
  7. Go to "Translate" tab and investigate "Edit" links. Both lead to the same page.
  8. Go to the newly create node and try switching language using "session" parameter. You will still see the node in default language.
  9. Do the same with a browser running second language (or just spoof the browser string to change language). You will still see the node in default language.

Remaining tasks

  1. Investigate why the checkbox Customize Content language detection to differ from User interface text language detection settings is ignored. The source of the issue lies probably inside Drupal\language\Form\NegotiationConfigureForm::submitForm() function. - the configuration is correctly saved
  2. Create patch - Patch is provided

User interface changes

No changes to the UI are required for the fix.

API changes

The protected variable type which indicates whether a given type of language usage (language_content, language_interface, language_url) changes to an array to allow different types to initialize during the initialization of another.

Many documentation / handbook URLs redirect to D7 content

$
0
0

Problem/Motivation

Following a somewhat recent update to Drupal.org that attempted to create separate handbooks for D7 and D8, there are many problems with D8 documentation: #2855171: Documentation migration makes significant sections of the Drupal 8 handbook unnavigable or redirect to Drupal 7 docs

In particular, though, many generic URLs once linked from core help hooks, etc. now redirect to Drupal 7-specific content. Example: #2854586: Stark's helptext link redirects to D7 theme guide We need to check and probably fix this on many or even most of the links in core.

Proposed resolution

Identify links to D7 docs in core, and fix them.

Remaining tasks

  1. Compile a list of the d.o handbook links in core. grep is your friend.
  2. Evaluate whether they have a redirect (possibly programmatically because it is going to be a lot).
  3. For anything redirected, list the redirect destination.
  4. For those that have a "7" in the redirected path, they are definitely wrong and need to either have the correct D8 docs identified, or have a documentation bug report filed that there are no D8 docs since the migration.

User interface changes

Many changed strings as we fix URLs. Correct links

API changes

N/A

Data model changes

N/A

user_schema() has wrong structure for foreign_keys

$
0
0

Problem/Motivation

The definition of the {users_data} table in user_install() includes this for the foreign_keys key:

'foreign keys' => [
      'uid' => ['users' => 'uid'],
    ],

This is not consistent with the structure of that key as described in the Schema API page in the API docs.

Proposed resolution

Change those lines to be consistent with the API docs. Several other modules define foreign_keys correctly. The {node_access} table, defined in node_schema() in node.install is a good model.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Replace the schema example

$
0
0

The Schema API page shows the code to define the database schema for the node table, but node_schema() doesn't define any node table anymore.
The example should be replaced with one still used in Drupal core code.

Replace instances of the deprecated LOCALE_PLURAL_DELIMITER const with Drupal\Core\StringTranslation\PluralTranslatableMarkup::DELIMITER

$
0
0

Problem/Motivation

Various parts of code are using the deprecated LOCALE_PLURAL_DELIMITER const instead of Drupal\Core\StringTranslation\PluralTranslatableMarkup\PluralTranslatableMarkup::DELIMITER which the former just points to anyway.

The reason it should be changed sooner rather than later is that this makes unit testing certain classes much more difficult. For example, when trying to unit test a subclass of Drupal\views\Plugin\views\field\NumericField, I received the following error:

Use of undefined constant LOCALE_PLURAL_DELIMITER - assumed 'LOCALE_PLURAL_DELIMITER'

There are ways around this, but the work has already been done and this issue should just be fixed in core.

Proposed resolution

Replace all instances of LOCALE_PLURAL_DELIMITER with Drupal\Core\StringTranslation\PluralTranslatableMarkup\PluralTranslatableMarkup::DELIMITER. The former already points to the latter anyway, so the current tests should suffice and no additional work should be needed.

Ajax attached to Views exposed filter form does not trigger callbacks

$
0
0

If you try to use #ajax on a Views exposed filter form element, the callback is never invoked. This was discussed at length in the Views issue queue here:

#1183418: Ajax attached to exposed filters in form_alter doesn't trigger callback

The same bug exists in the version of Views in Drupal 8 core. As merlinofchaos wrote:

Views are $_GET forms and they specifically remove the form_id and form_build_id and form_token because they are 'submitted' even when they aren't submitted. That means the standard #ajax tools don't work with them, since those rely on being able to cache the form in core's form cache. That system is to naive to work with core's filters. I've never really tried to do anything like this in D7 yet, so I don't know what the solutions might be, but I can say that it's going to provide very ugly URLs if you hack the form id back in.

The proposed solution is to add a little custom JS magic so that we identify all the form info via after_build callbacks, stash those in JS settings, and then inside the JS, we reattach the relevant form info to the #ajax-enabled form elements so that their callbacks can be properly invoked.


Replace the schema example with one actually used from a module

$
0
0

The example of schema given in the Schema API documentation uses code that the Node module doesn't use anymore, since node_schema() doesn't define anymore a node table.

$schema['node'] = array(
  'description' => 'The base table for nodes.',
  'fields' => array(
    'nid' => array(
      'type' => 'serial',
      'unsigned' => TRUE,
      'not null' => TRUE,
    ),
    'vid' => array(
      'type' => 'int',
      'unsigned' => TRUE,
      'not null' => TRUE,
      'default' => 0,
    ),
    'type' => array(
      'type' => 'varchar',
      'length' => 32,
      'not null' => TRUE,
      'default' => '',
    ),
    'language' => array(
      'type' => 'varchar',
      'length' => 12,
      'not null' => TRUE,
      'default' => '',
    ),
    'title' => array(
      'type' => 'varchar',
      'length' => 255,
      'not null' => TRUE,
      'default' => '',
    ),
    'uid' => array(
      'type' => 'int',
      'not null' => TRUE,
      'default' => 0,
    ),
    'status' => array(
      'type' => 'int',
      'not null' => TRUE,
      'default' => 1,
    ),
    'created' => array(
      'type' => 'int',
      'not null' => TRUE,
      'default' => 0,
    ),
    'changed' => array(
      'type' => 'int',
      'not null' => TRUE,
      'default' => 0,
    ),
    'comment' => array(
      'type' => 'int',
      'not null' => TRUE,
      'default' => 0,
    ),
    'promote' => array(
      'type' => 'int',
      'not null' => TRUE,
      'default' => 0,
    ),
    'moderate' => array(
      'type' => 'int',
      'not null' => TRUE,
      'default' => 0,
    ),
    'sticky' => array(
      'type' => 'int',
      'not null' => TRUE,
      'default' => 0,
    ),
    'translate' => array(
      'type' => 'int',
      'not null' => TRUE,
      'default' => 0,
    ),
  ),
  'indexes' => array(
    'node_changed' => array(
      'changed',
    ),
    'node_created' => array(
      'created',
    ),
    'node_moderate' => array(
      'moderate',
    ),
    'node_frontpage' => array(
      'promote',
      'status',
      'sticky',
      'created',
    ),
    'node_status_type' => array(
      'status',
      'type',
      'nid',
    ),
    'node_title_type' => array(
      'title',
      array(
        'type',
        4,
      ),
    ),
    'node_type' => array(
      array(
        'type',
        4,
      ),
    ),
    'uid' => array(
      'uid',
    ),
    'translate' => array(
      'translate',
    ),
  ),
  'unique keys' => array(
    'vid' => array(
      'vid',
    ),
  ),
  // For documentation purposes only; foreign keys are not created in the
  // database.
  'foreign keys' => array(
    'node_revision' => array(
      'table' => 'node_field_revision',
      'columns' => array(
        'vid' => 'vid',
      ),
    ),
    'node_author' => array(
      'table' => 'users',
      'columns' => array(
        'uid' => 'uid',
      ),
    ),
  ),
  'primary key' => array(
    'nid',
  ),
);

I would rather use the schema for the user_data table, once it gets fixed.

(As usual, I am linking the 8.6.x documentation, since the 8.7.x documentation is not yet available.)

ConfigurableLanguage is missing config_export property and language.module does untrusted config saves during install

$
0
0

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

Call to a member function isTranslatable() on null in SqlContentEntityStorage

$
0
0

Hi,

I get a blank page in admin/content. No error. Everything else is working fine in the Admin Menu including Add content and Comments under the Content Menu.

Drupal 8.4.2 (problem was the sma with 8.4.1)
Modules
Admin Toolbar 8.x-1.21
Calendar 8.x-1.x-dev (2017-Oct-04)
CAPTCHA 8.x-1.0-beta1
Content Access 8.x-1.0-alpha1
Field tools 8.x-1.0-alpha4
Menu block 8.x-1.4
Menu Multilingual 8.x-1.x-dev (2017-Nov-27)
Module Filter 8.x-3.1
Protected Pages 8.x-1.0
reCAPTCHA 8.x-2.2
Rules 8.x-3.0-alpha3
Simple Google Maps 8.x-1.4
Typed Data API enhancements 8.x-1.0-alpha1
Views Templates 8.x-1.0-alpha1
Webform 8.x-5.0-beta24

Security updated issue by clicking in CMS menu settings

$
0
0

Hi,

I have recently installed Php7 and upgraded my server to Ubuntu 18.04.
After upgradation, Drupal asked me to upgrade from Drupal 7.59 to Drupal 7.60.
I did that, but I am unable to update any other module module, where security updated are necessary.
Also When I try to set Menu, it is giving security updates issue.
Please see the screen shots attached.

Please help me as this is urgent issue of our live website.

Thanks and Regards,
Deepti

Move responsibilities of deprecated EntityHandlerBase to the implementations that need it

$
0
0

Problem/Motivation

#2168333: Ensure custom EntityType controllers can be provided by modules introduced EntityHandlerBase (then EntityControllerBase) with an @todo to convert it to a trait. Since it was introduced, 2/3 of the class has already been replaced by traits, and all it does now is store a module handler dependency for the entity handler.

This is a little strange. On the one hand, it does not really make sense for the remaining API in EntityHandlerBase to become a trait--it's a dependency for the classes that use it. On the other, the base class is a layer of misdirection we don't need, since it does not implement, nor reference, nor remotely resemble EntityHandlerInterface. We also now have two different ways of adding this dependency to handlers. See in EntityManager::createHandlerInstance():

    if (is_subclass_of($class, 'Drupal\Core\Entity\EntityHandlerInterface')) {
      $handler = $class::createInstance($this->container, $definition);
    }
    else {
      $handler = new $class($definition);
    }
    if (method_exists($handler, 'setModuleHandler')) {
      $handler->setModuleHandler($this->moduleHandler);
    }
    if (method_exists($handler, 'setStringTranslation')) {
      $handler->setStringTranslation($this->translationManager);
    }
    return $handler;

Proposed resolution

  1. Deprecate the base class for removal in 9.x.
  2. Add StringTranslationTrait and DependencySerializationTrait wherever they are actually needed.
  3. Move the module handler dependency to the implementations that need it but don't yet use the interface.

#3 needs some clarification/explanation, since it's odd that we have this disconnect in the first place.

This issue is filed against 8.1.x because it does not meet the allowed beta changes criteria. We can keep BC in 8.1.x by deprecating instead of removing the base class and updating the code paths that expect it.

Remaining tasks

TBD

User interface changes

N/A

API changes

EntityHandlerBase is deprecated. Others TBD.

Viewing all 294541 articles
Browse latest View live


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