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

Allow custom database drivers to extend and have the same name as the core ones

$
0
0

Problem/Motivation

In #3109534: Raise the minimum MySQL version to 5.7.8 and MariaDB version to 10.2.7 in Drupal 9, we raised the minimum MySQL version to 5.7 for Drupal 9.0. However, MySQL 5.6 isn't EOL until Feb. 2021. We should therefore make it possible for people to have a custom driver that allows MySQL 5.6, at least for a little while. At some point, possibly as early as Drupal 9.1, we might start using MySQL 5.7 features, such as JSON, that'll be hard for a 5.6 driver to implement. But even if a MySQL 5.6 custom driver is only functional for Drupal 9.0 (and not 9.1), Drupal 9.0 will be supported until after Feb. 2021, so even a trivial custom driver can get people past MySQL 5.6's EOL.

To a large extent, core already allows custom drivers to extend the core ones. Within settings.php, you can have:

$databases['default']['default'] = array (
  'namespace' => 'Drupal\\Driver\\Database\\mysql',
  'driver' => 'mysql',
  ...
);

which works as expected.

However, there are two places where the above namespace from the above connection info array is not checked:

  1. In db_installer_object(), used by the installer before settings.php has been written.
  2. In Database::convertDbUrlToConnectionInfo(), which can be called from places that only have a db URL and not a connection info array. In core, that's just tests and console commands.

In these two places, HEAD currently checks the core namespace first, and only checks the custom namespace for drivers that aren't in core. This would prevent, for example, a custom MySQL driver from being used during installation and tests.

Proposed resolution

Change the above two places to check for a driver in the custom namespace first, and then fall back to the core namespace.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet


Class active-trail not added to li element when linking to front page

$
0
0

There is a bug with the "active-trail" class not showing up on <li> for menu items with Drupal 7.14. The problem is that "active-trail" is missing for a menu link to the front page (path "<front>"), all other links have "active-trail" just fine.

The situation is also slightly different for the horizontal primary link tabs that can be switched on from theme settings Toggle display - Main menu, than they are for the vertical navigation in the Main menu block. In the horizontal tabs the front page <li> has "active" but not "active-trail". So "active" could be used to do get around this issue for horizontal menus. But unfortunately if you want the vertical menu, there is no "active" nor "active-trail".

I verified that both "active" and "active-trail" are missing with a fresh install without any added modules on Drupal 7.4 to 7.14. The behaviour is identical with Bartik, Garland and Stark themes, as well as Zen.

Steps to reproduce:

1. Create a fresh install of Drupal 7.14.
2. On the front page go to Structure -> Blocks.
3. Move "Main menu" block to "First sidebar"
4. Create a new "Basic page" with test content and click "Provide a menu link" -> "Parent item" [Main menu]
5. Use e.g. Firebug to verify that the newly created test page link on the sidebar has "active-trail" on <li> but "Home" does not.

Attached is a patch that fixes the bug by adding special handling for the front page when adding the active-trail class. A better solution would be to get the 'in_active_trail' variable correctly set for links to <front>, but unfortunately I could not find out how to do that.

[D7] Class active-trail not added to li element when linking to front page

$
0
0

From parent D8 issue:
#1578832: Class active-trail not added to li element when linking to front page

There is a bug with the "active-trail" class not showing up on <li> for menu items with Drupal 7.14. The problem is that "active-trail" is missing for a menu link to the front page (path "<front>"), all other links have "active-trail" just fine.

The situation is also slightly different for the horizontal primary link tabs that can be switched on from theme settings Toggle display - Main menu, than they are for the vertical navigation in the Main menu block. In the horizontal tabs the front page <li> has "active" but not "active-trail". So "active" could be used to do get around this issue for horizontal menus. But unfortunately if you want the vertical menu, there is no "active" nor "active-trail".

I verified that both "active" and "active-trail" are missing with a fresh install without any added modules on Drupal 7.4 to 7.14. The behaviour is identical with Bartik, Garland and Stark themes, as well as Zen.

Steps to reproduce:

1. Create a fresh install of Drupal 7.
2. On the front page go to Structure -> Blocks.
3. Move "Main menu" block to "First sidebar"
4. Create a new "Basic page" with test content and click "Provide a menu link" -> "Parent item" [Main menu]
5. Use e.g. Firebug to verify that the newly created test page link on the sidebar has "active-trail" on <li> but "Home" does not.

Attached is a patch that fixes the bug by adding special handling for the front page when adding the active-trail class. A better solution would be to get the 'in_active_trail' variable correctly set for links to <front>, but unfortunately I could not find out how to do that.

Allow themes to declare dependencies on modules

$
0
0

Problem/Motivation

The critical need

As documented in #3051352: [Plan] Remove unused jQuery UI components and replace with a suite of contrib packages for the continuous upgrade path, jQueryUI is deprecated in Drupal9 core. In Drupal 9, contrib themes dependent on jQueryUI should be satisfying their jQueryUI requirements via the contrib jQueryUI modules. It needs to be possible for these themes to declare these contrib modules as dependencies.

Additional motivation

Parsing .info files for dependency information is already implemented on the modules administration page. Adding support for the same dependencies in theme.info files, and implementing the same behavior on the admin/build/themes page, would allow designers building heavily customized themes to make safer assumptions about their target sites.

A theme might require the existence of imagecache to auto-generate variations of a header image. This would be a nice compromise between systems like Wordpress and Joomla!, which give themes much greater control over the functionality of the site, and Drupal's module-centric approach.

Proposed resolution

  • Allow themes to add the dependencies to .info.yml files
  • Show these dependencies on /admin/appearance and make it impossible to install without the requirements via UI or command line
  • Install dependencies automatically on API level.Moved to followup #3100374: Make it possible to install dependent modules when installing theme
  • Validation is added to prevent installing themes that depend on uninstalled modules, and prevent uninstalling modules that are depended upon by installed themes. This is implemented at a level that prevents these installs/uninstalls from occurring programatically or via cli (Drush/Drupal Console).

Follow-ups

  1. #3100374: Make it possible to install dependent modules when installing theme
  2. Update #3005229: Provide optional support for using composer.json for dependency metadata to read composer.json theme's also

User interface changes

Themes listed in admin/appearance will list the modules they depend on and the ability to install that theme will not be available unless those module dependencies are met.
The module descriptions found at admin/modules and admin/module/uninstall will include themes in their "Required By" description.

API changes

Themes will be able to define modules dependencies in their info.yml via the dependencies key.

Release notes snippet

Pending.

Original report by [eaton]

Issue Summary
Parsing .info files for dependency information is already implemented on the modules administration page. Adding support for the same dependencies in theme.info files, and implementing the same behavior on the admin/build/themes page, would allow designers building heavily customized themes to make safer assumptions about their target sites.

A theme might require the existence of imagecache to auto-generate variations of a header image. This would be a nice compromise between systems like Wordpress and Joomla!, which give themes much greater control over the functionality of the site, and Drupal's module-centric approach.

Return NULL on EntityRepository::loadEntityByUuid() when the UUID is invalid or it doesn't exist

$
0
0

Problem/Motivation

EntityRepository::loadEntityByUuid() is documented with the following documentation comment.

  /**
   * Loads an entity by UUID.
   *
   * Note that some entity types may not support UUIDs.
   *
   * @param string $entity_type_id
   *   The entity type ID to load from.
   * @param string $uuid
   *   The UUID of the entity to load.
   *
   * @return \Drupal\Core\Entity\EntityInterface|null
   *   The entity object, or NULL if there is no entity with the given UUID.
   *
   * @throws \Drupal\Core\Entity\EntityStorageException
   *   Thrown in case the requested entity type does not support UUIDs.
   */

EntityRepository::loadEntityByUuid() doesn't check for invalid nor unexisting UUIDs.

Proposed resolution

Let's return NULL, in case we have a wrong UUID.

Remaining tasks

User interface changes

API changes

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue categoryBug because the behavior does not match the interface documentation.
Issue priorityNormal.
Prioritized changesThe goal of this issue is to clarify the entity API, and to expand testing to make sure implementations meet that expectation.
DisruptionNo disruption.

xdebug does not work with Dynamic Page cache, internal page cache modules enabled.

$
0
0

Xdebug started finding breakpoints only after manually disabling modules Internal dynamic page cache & Dynamic page cache. Possible solutions may be:

  1. Disable internal caches modules automatically if user has turned off caching by choosing "no caching" from the performance configuration tab
  2. Do these modules hook correctly to cache enable/disable sections of core? In this particular case, a custom form had the form_state->cache set to 0 (zero), but the module(s) didn't seem to respect that.

Note: Have not tested with disabling just one of these modules and check if only one of them is the culprit. For be absolutely sure, would need new instance of Drupal for each of these tests. Can do that in case this is actually an issue and we need to dig further to resolve.

Image generation is not working for social media bot

$
0
0

When the facebook bot visits a URL that is pasted, Drupal throws this error...

Symfony\Component\HttpKernel\Exception\ServiceUnavailableHttpException: Image generation in progress. Try again shortly. in Drupal\image\Controller\ImageStyleDownloadController->deliver() (line 160 of /home/gabriolalife/public_html/gabriolalife.ca/docroot/core/modules/image/src/Controller/ImageStyleDownloadController.php).

The image is clearly there...
https://gabriolalife.ca/sites/default/files/styles/facebook/public/2020-...

url() should return / when asked for the URL of the frontpage

$
0
0

I've been very confused with the addition of canonical links in Drupal 7. The default behaviour seems to be to assign the actual node url of the node being displayed on the front page as the canonical uri. But that must be incorrect, since going to that uri will only redirect to the front page. So I've made a few changes to two files:

common.inc, line 2143, before:

  if ($path == '<front>') {
    $path = '';
  }

changed to:

  if ($path == '<front>' || $path == variable_get('site_frontpage', 'node')) {
    $path = '';
  }

Now the front page has "/" as canonical url. Also, other tags like < meta about ..> get updated.

Once I got going, I made two other changes as well in node.module, line 2592:

  $uri['options']['absolute'] = TRUE;
  // Set the node path as the canonical URL to prevent duplicate content.
  $canonical_href = url($uri['path'], $uri['options']);
  drupal_add_html_head_link(array('rel' => 'canonical', 'href' => $canonical_href), TRUE);
  // Set the non-aliased path as a default shortlink.
  $shortlink_href = url($uri['path'], array_merge($uri['options'], array('alias' => TRUE)));
  if(strlen($shortlink_href) < strlen($canonical_href)) {
    drupal_add_html_head_link(array('rel' => 'shortlink', 'href' => $shortlink_href), TRUE);
  }

This does two things:
1. Sets canonical links as absolute urls, which seems better if site can be accessed from different urls. Should perhaps be an option somewhere?
2. Only adds the shortlink IF its url is actually shorter than the aliased path. It seems weird to say that the shortlink of "/" is "/node/12345", or that another shortlink of "/abc" is "/node/34567".

What do you think about these changes? I think it's crucial SEO-wise to get it right. I'm not an SEO expert but I've asked around a bit and this seems to be along the right tracks. I hope that the Drupal core can be updated some way to be more optimized for SEO and web standards.


Call to a member function getSetting() on null in Drupal\migrate_drupal\Plugin\migrate\EntityReferenceTranslationDeriver->getDerivativeDefinitions()

$
0
0

I have been developing a site that uses migrate fairly heavily to migrate data from a D6 site to a D8 site. Migration has run just fine on the site until doing an upgrade to 8.5.4 - the migration runs in 8.5.3, but after upgrading to either 8.5.4 or 8.5.5 migration consistently is broken. The symptom, for example when running drush ms is

Error: Call to a member function getSetting() on null in             [error]
Drupal\migrate_drupal\Plugin\migrate\EntityReferenceTranslationDeriver->getDerivativeDefinitions()
(line 101 of
/home/elections/domains/develections.cruiskeenconsulting.com/public_html/core/modules/migrate_drupal/src/Plugin/migrate/EntityReferenceTranslationDeriver.php)
#0
/home/elections/domains/develections.cruiskeenconsulting.com/public_html/core/lib/Drupal/Component/Plugin/Discovery/DerivativeDiscoveryDecorator.php(101):
Drupal\migrate_drupal\Plugin\migrate\EntityReferenceTranslationDeriver->getDerivativeDefinitions(Array)
#1
/home/elections/domains/develections.cruiskeenconsulting.com/public_html/core/lib/Drupal/Component/Plugin/Discovery/DerivativeDiscoveryDecorator.php(87):
Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDerivatives(Array)
#2
/home/elections/domains/develections.cruiskeenconsulting.com/public_html/core/modules/migrate/src/Plugin/MigrationPluginManager.php(256):
Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDefinitions()
#3
/home/elections/domains/develections.cruiskeenconsulting.com/public_html/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php(175):
Drupal\migrate\Plugin\MigrationPluginManager->findDefinitions()
#4
/home/elections/domains/develections.cruiskeenconsulting.com/public_html/core/modules/migrate/src/Plugin/MigrationPluginManager.php(109):
Drupal\Core\Plugin\DefaultPluginManager->getDefinitions()
#5
/home/elections/domains/develections.cruiskeenconsulting.com/public_html/modules/contrib/migrate_tools/migrate_tools.drush.inc(499):
Drupal\migrate\Plugin\MigrationPluginManager->createInstances(Array)
#6
/home/elections/domains/develections.cruiskeenconsulting.com/public_html/modules/contrib/migrate_tools/migrate_tools.drush.inc(149):
drush_migrate_tools_migration_list('')
#7 phar:///usr/bin/drush/includes/command.inc(422):
drush_migrate_tools_migrate_status()
#8 phar:///usr/bin/drush/includes/command.inc(231):
_drush_invoke_hooks(Array, Array)
#9 phar:///usr/bin/drush/includes/command.inc(199): drush_command()
#10 phar:///usr/bin/drush/lib/Drush/Boot/BaseBoot.php(67):
drush_dispatch(Array)
#11 phar:///usr/bin/drush/includes/preflight.inc(66):
Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#12 phar:///usr/bin/drush/includes/startup.inc(462): drush_main()
#13 phar:///usr/bin/drush/includes/startup.inc(369):
drush_run_main(false, '/', 'Phar detected. ...')
#14 phar:///usr/bin/drush/drush(114): drush_startup(Array)
#15 /usr/bin/drush(10): require('phar:///usr/bin...')
#16 {main}.
Error: Call to a member function getSetting() on null in /home/elections/domains/develections.cruiskeenconsulting.com/public_html/core/modules/migrate_drupal/src/Plugin/migrate/EntityReferenceTranslationDeriver.php on line 101 #0 /home/elections/domains/develections.cruiskeenconsulting.com/public_html/core/lib/Drupal/Component/Plugin/Discovery/DerivativeDiscoveryDecorator.php(101): Drupal\migrate_drupal\Plugin\migrate\EntityReferenceTranslationDeriver->getDerivativeDefinitions(Array)
#1 /home/elections/domains/develections.cruiskeenconsulting.com/public_html/core/lib/Drupal/Component/Plugin/Discovery/DerivativeDiscoveryDecorator.php(87): Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDerivatives(Array)
#2 /home/elections/domains/develections.cruiskeenconsulting.com/public_html/core/modules/migrate/src/Plugin/MigrationPluginManager.php(256): Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDefinitions()
#3 /home/elections/domains/develections.cruiskeenconsulting.com/public_html/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php(175): Drupal\migrate\Plugin\MigrationPluginManager->findDefinitions()
#4 /home/elections/domains/develections.cruiskeenconsulting.com/public_html/core/modules/migrate/src/Plugin/MigrationPluginManager.php(109): Drupal\Core\Plugin\DefaultPluginManager->getDefinitions()
#5 /home/elections/domains/develections.cruiskeenconsulting.com/public_html/modules/contrib/migrate_tools/migrate_tools.drush.inc(499): Drupal\migrate\Plugin\MigrationPluginManager->createInstances(Array)
#6 /home/elections/domains/develections.cruiskeenconsulting.com/public_html/modules/contrib/migrate_tools/migrate_tools.drush.inc(149): drush_migrate_tools_migration_list('')
#7 phar:///usr/bin/drush/includes/command.inc(422): drush_migrate_tools_migrate_status()
#8 phar:///usr/bin/drush/includes/command.inc(231): _drush_invoke_hooks(Array, Array)
#9 phar:///usr/bin/drush/includes/command.inc(199): drush_command()
#10 phar:///usr/bin/drush/lib/Drush/Boot/BaseBoot.php(67): drush_dispatch(Array)
#11 phar:///usr/bin/drush/includes/preflight.inc(66): Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#12 phar:///usr/bin/drush/includes/startup.inc(462): drush_main()
#13 phar:///usr/bin/drush/includes/startup.inc(369): drush_run_main(false, '/', 'Phar detected. ...')
#14 phar:///usr/bin/drush/drush(114): drush_startup(Array)
#15 /usr/bin/drush(10): require('phar:///usr/bin...')
#16 {main}
Error: Call to a member function getSetting() on null in Drupal\migrate_drupal\Plugin\migrate\EntityReferenceTranslationDeriver->getDerivativeDefinitions() (line 101 of /home/elections/domains/develections.cruiskeenconsulting.com/public_html/core/modules/migrate_drupal/src/Plugin/migrate/EntityReferenceTranslationDeriver.php).
Drush command terminated abnormally due to an unrecoverable error.   [error]

I'm not quite certain how to proceed at this point, this sounds quite a lot like it may be related to https://www.drupal.org/project/drupal/issues/2912348 - but that appears to be fixed. If there is any help possible here I'd appreciate it.

MenuLinkContent updateLink function generates a PHP Warning for override-able keys that are not present in the loaded entity

$
0
0

Problem/Motivation

When updating a MenuLinkContent item with new definition values programmatically, there is a possibility that the entity property value may not already exist, even when present in the overrideAllowed list.

This will generate the PHP warning "Creating default object from empty value" when warning or strict modes are set.

The specific code is line 215 of MenuLinkContent.php:

213      $entity = $this->getEntity();
214      foreach ($overrides as $key => $value) {
215        $entity->{$key}->value = $value;
216      }

Proposed resolution

We have a few options. The simplest and easiest patch:

foreach ($overrides as $key => $value) {
  if (!isset(entity->{$key}) {
    $entity->{$key} = new stdClass();
  }
  $entity->{$key}->value = $value;
}

Creates an empty object as a property if the property is not already present.

Other solutions:

  1. Modify the MenuLinkContent getEntity() function to always populate like other entity loads
  2. Modify the MenuLinkContent updateLink() function to work more like other updateLink functions

These solutions will require a decent rewrite of their respective functions.

Remaining tasks

Any decision making for the other solutions.
A patch is incoming shortly.

User interface changes

None.

API changes

Removing a PHP Warning from \Drupal\menu_link_content\Plugin\Menu\MenuLinkContent::updateLink()

Allow users with access to unpublished nodes to create unpublished books

$
0
0

Problem/Motivation

It is currently not possible to create unpublished book pages as children of another unpublished node page: unpublished pages do not appear in the Parent combo of the node creation page. That would be useful if I want to create a book but not publish it immediately.

To reproduce the problem:
1) Install a fresh Drupal 8, enable book module
2) Add a book node -> set title as "Front Page" -> edit the book outline -> select "create a new book" -> save
3) Add a book node -> set title as "Chapter 1" -> edit the book outline -> select "Front Page" as parent item
4) Add a book node -> set title as "chapter 2" -> edit the book outline -> select "Front Page" as parent item
5) Add a book node -> set title as "Page 1" -> edit the book outline -> select "Chapter 1" as parent item
6) Add a book node -> set title as "Page 2" -> edit the book outline -> select "Chapter 2" as parent item
7) Unpublish the Front page.
8) Edit "Chapter 1" book node, in book outline, book name and parent item become empty
9) Edit "Page 1" book node, in book outline, book name and parent item become empty
10) Publish "Front Page" again
11) Go to edit page of "Chapter 1" book node, in book outline, book name and parent item is good now
12) Edit "Page 1" book node, in book outline, book name and parent item is good now
13) Unpublish "Chapter 1" book node
14) Edit "Page 1" book node, in book outline, parent item have been changed from "Chapter 1" to "Front Page"

Proposed resolution

The Entity Query alone is sufficient to check access, so the explicit status condition can be removed.

Remaining tasks

Review.

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue categoryBug unpublished nodes disappear from books
Issue priorityMajor because this causes confusion when administering books
Prioritized changesThe main goal of this issue is usability

ExpectDeprecationTrait is not compatible with PHPUnit 8

$
0
0

Problem/Motivation

Discovered in #3063887: Support PHPUnit 8 in Drupal 9, drop support for PHPUnit 7.

Drupal\Tests\Traits\ExpectDeprecationTrait implements

protected function expectDeprecation($message)

This method has a name collision with a PHPUnit 8 method on PHPUnit\Framework\TestCase that has a different signature and a different purpose.

This will prevent future usage of PHPUnit 8.

Proposed resolution

  • Rename expectDeprecation to something else: addExpectedDeprecationMessage
  • Deprecate expectDeprecation
  • Add/adjust tests

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Add tests for DrupalRequestSanitizer to Drupal 7

$
0
0

Problem/Motivation

Tests were added to D8 for the new RequestSanitizer in #2969053: Add unit tests for SA002 and SA004

However, D7 has no test coverage for its version of this code.

This makes touching the RequestSanitizer code somewhat risky - see e.g. #3084935: element_children() and DrupalRequestSanitizer::stripDangerousValues() should not use integer keys as array

Proposed resolution

Not sure if we can do a fairly straight backport of the D8 tests, but that would be ideal.

Remaining tasks

Backport test coverage, or implement our own for D7 if necessary.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

N/A?

Allow to verify imported user passwords using other Crypt schemes

$
0
0

Problem

  • Users, whose accounts (including passwords) were imported from another application, cannot log in to Drupal — even though their (Blowfish/Bcrypt) password encryption scheme is natively supported by PHP.

Proposed resolution

  1. When a password cannot be handled by Drupal's Phpass password scheme, verify it through all Crypt schemes supported by password_verify() in PHP Core, which is natively available since PHP 5.5.

Remaining tasks

  • Add unit/kernel tests to prove that the fallback works as expected.

User interface changes

– none –

API changes

– none –

Data model changes

– none –

Document how to perform format mappings in D6/D7 upgrade


Overwriting reference variable causes only some batch sets to run on installation

$
0
0

Some installation tasks (in my case installing local language po files) aren't being run. Only the last set of the batch in install_run_task() is being run.

The problem is caused by overwriting a reference variable in core/includes/install.core.inc in the batches loop, we use the variable $batch twice. This was introduced in http://drupal.org/node/1993452.

This is easier to demonstrated with an example of the code, rather than a Drupal test, maybe someone else can write the proper Drupal test. Below is a simple test using just PHP showing how using the same general code causes the problem.

<?php

class Test {

  function run() {
    $exsiting = $this->getTestResultsExisting();
    batch_reset();
    $fixed = $this->getTestResultsFixed();
    print_r(get_defined_vars());
  }

  function getTestResultsExisting() {
    $batches = [
      ['value' => 'test1'],
      ['value' => 'test2'],
    ];
    foreach ($batches as $batch) {
      batch_set($batch);

      $batch =& batch_get();
      $batch['progressive'] = FALSE;
    }

    $batch =& batch_get();
    return $batch;
  }

  function getTestResultsFixed() {
    $batches = [
      ['value' => 'test1'],
      ['value' => 'test2'],
    ];
    foreach ($batches as $batch_definition) {
      batch_set($batch_definition);

      $batch =& batch_get();
      $batch['progressive'] = FALSE;
    }

    $batch =& batch_get();
    return $batch;
  }

}

$test = new Test;
$test->run();

function &batch_get() {
  static $batch = [];
  return $batch;
}

function batch_set($batch_definition) {
  if ($batch_definition) {
    $batch =& batch_get();
    $batch_set = $batch_definition + ['sandbox' => []];
    $batch['sets'][] = $batch_set;
  }
}

function batch_reset() {
  $batch =& batch_get();
  $batch = [];
}

Allow multiple vocabularies in the taxonomy filter

$
0
0

Problem/Motivation

Field UI allows you to select multiple target bundles for a field.
When you get to the views UI though you can select just a single vocabulary. For some usecases this is a problem

Proposed resolution

Allow to set multiple vocabularies

Remaining tasks

  • Write a proper update path
  • Write a test for the new capability
  • Write a test for the update path

Before:

After:

Drupal open social 8.8.3 media not posting

$
0
0

Using centos 7 apache 2 with cpanel and WHM php ver 7.3 database mysql drupal instalation of open social 8.8.3 fully enabled. Loged in as admin making a post for public or community stream the media uploads and I am able to crop it. But after I post it the media never shows up in activity stream. There is space reserved for the media but its just a blank space no pictures When I try to edit the post the media is there but fails to post in stream. Attached is one of the pictures I am trying to post.

Database reserved keywords need to be quoted as per the ANSI standard

$
0
0

Problem/Motivation

Over many years Drupal has held off checking queries for reserved words in column names, table names and aliases because it was a design decision. The idea is that we just just should not use reserved words. However, time has made it clear that this position (as stated in the long discussions in #371: resolve ANSI SQL-92/99/2003 reserved words conflict in query statements) is not really tenable. Here are the problems:

  • The list of reserved words is different for different database drivers even those the support the various ANSI SQL standards. For example OFFSET is reserved in PostgreSQL but not in MySQL
  • Database drivers add new reserved keywords in new versions. MySQL has been doing this in every new version for example 5.7 and 8

Proposed resolution

  • Add a new syntax square bracket syntax to the query builder to know what identifiers (column names/ aliases) are. Leverage work in #371: resolve ANSI SQL-92/99/2003 reserved words conflict in query statements suggested using [COLUMN_NAME] to match {TABLE_NAME}. This supports db_query(), addExpression() and addWhere()
  • Automatically quote fields and aliases in escapeField() and escapeAlias().
  • All identifiers should be quoted. This helps us ensure that the database API is properly used when query building and will make edge-cases less likely.

Using [] to identify identifiers (field names / aliases)

There is precedence - this is the quote character in MSSQL.

The one consideration is that :variable[] is used to identify and expand array variables.

Discarded resolution(s)

We could deprecate SELECT, UPDATE, INSERT queries via \Drupal\Core\Database\Connection::query() since the methods like \Drupal\Core\Database\Connection::select() require fields to be specified. If we do that we have to worry about performance - see #1067802: Compare $connection->query() and $connection->select() performance. Also this does not work for columns added using ->addExpression() or ->addWhere(). Therefore this resolution has been discarded.

Remaining tasks

Fix the blockers:

File follow-ups:

  • add coder rule to try to check for missing []
  • Ensure core uses new square bracket syntax

User interface changes

None

API changes

At the moment \Drupal\Core\Database\Connection::escapeField() and \Drupal\Core\Database\Connection::escapeAlias() in their core implementations are re-entrant. And some core code relies on this. That said the docs hint that this should not be case. In the new implementation methods also now quote identifiers BUT because the code removes the quotes before adding them they still are re-entrant. The new implementations result in strings like users_data.uid becoming "users_data"."uid".

\Drupal\Core\Database\Query\ConditionInterface::condition()'s first argument $field must be a field and cannot be (ab)used to do ->condition('1 <> 1'). The way to do this is to use the new API added by #2986334: Add a way to enforce an empty result set for a database condition query

\Drupal\Core\Database\Connection::prepareQuery() now takes additionally takes a boolean that is derived from a query's $options['allow_square_brackets'] value that allows specific queries to use square brackets and to not them for identifier quotes. The default value for $options['allow_square_brackets'] is FALSE.

\Drupal\Core\Database\Connection::prefixTables now quotes tables so {node} becomes "node".

Data model changes

None

Release notes snippet

All identifiers (table names, database names, field names and aliases) are quoted in database queries. Column names or aliases should be wrapped in square brackets when using Connection::query(), db_query(), ConditionInterface::where() or SelectInterface::addExpression. Custom or contrib database drivers should read https://www.drupal.org/node/2986894 to see what changes are necessary.

Change hardcoded quote identifier in EntityQueryTest to square brackets

$
0
0

Problem/Motivation

#2986452: Database reserved keywords need to be quoted as per the ANSI standard:

+++ b/core/tests/Drupal/KernelTests/Core/Entity/EntityQueryTest.php
@@ -1228,9 +1228,9 @@ public function testToString() {
     $expected = $connection->select("entity_test_mulrev", "base_table");
     $expected->addField("base_table", "revision_id", "revision_id");
     $expected->addField("base_table", "id", "id");
-    $expected->join("entity_test_mulrev__$figures", "entity_test_mulrev__$figures", "entity_test_mulrev__$figures.entity_id = base_table.id");
-    $expected->join("entity_test_mulrev__$figures", "entity_test_mulrev__{$figures}_2", "entity_test_mulrev__{$figures}_2.entity_id = base_table.id");
-    $expected->addJoin("LEFT", "entity_test_mulrev__$figures", "entity_test_mulrev__{$figures}_3", "entity_test_mulrev__{$figures}_3.entity_id = base_table.id");
+    $expected->join("entity_test_mulrev__$figures", "entity_test_mulrev__$figures", '"entity_test_mulrev__' . $figures . '"."entity_id" = "base_table"."id"');
+    $expected->join("entity_test_mulrev__$figures", "entity_test_mulrev__{$figures}_2", '"entity_test_mulrev__' . $figures . '_2"."entity_id" = "base_table"."id"');
+    $expected->addJoin("LEFT", "entity_test_mulrev__$figures", "entity_test_mulrev__{$figures}_3", '"entity_test_mulrev__' . $figures . '_3"."entity_id" = "base_table"."id"');
     $expected->condition("entity_test_mulrev__$figures.{$figures}_color", ["blue"], "IN");
     $expected->condition("entity_test_mulrev__{$figures}_2.{$figures}_color", ["red"], "IN");
     $expected->isNull("entity_test_mulrev__{$figures}_3.{$figures}_color");
diff --git a/core/tests/Drupal/Tests/Core/Database/ConnectionTest.php b/core/tests/Drupal/Tests/Core/Database/ConnectionTest.php

this has wrongly assumed that " would always be the character for quoting identifiers, which is the case in core, but not necessarily in contrib.

Proposed resolution

Change to new square brackets syntax.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Viewing all 298156 articles
Browse latest View live


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