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

SQLite driver should use COLLATE NOCASE instead of PDO custom collation (COLLATE NOCASE_UTF8)

$
0
0

I've spotted this issue while trying to vacuum sqlite3 database (it grew to over 440 Mb), while sqlite3_analyze reported only 20 Mb of data and over 95% of freelist. Upon vacum, sqlite3 reported `Error: no such collation sequence: NOCASE_UTF8`. Apparently NOCASE_UTF8 is custom collation for PDO driver, but it is invalid in sqlite3. Simple replacing NOCASE_UTF8 with NOCASE on db file solves the issue. This likely affects auto vacuum and in the result db file gets really huge with time.
More info here: https://bioinfoexpert.com/2019/02/28/investigate-reduce-the-size-of-drup...
Also reported in https://www.drupal.org/project/drupal/issues/2462175#comment-12991687


[meta] Priorities for 2022-06-01 release of Drupal 7

$
0
0

Assorted todo lists carried over from #3216978: [meta] Priorities for 2021-12-01 release of Drupal 7

PHP 8.1 compatibility fixes are top priority for the next release.

These are not necessarily in priority order.

For consideration

Issues which have had recent activity, and are RTBC.

Simple Fixes:

Important Fixes:

PostgreSQL performance improvements (backports from D8):

Unsorted Fixes:

Move language negotiation prefix logic update to ConfigurableLanguage

$
0
0

Follow-up to #2403229: language.negotiation configuration can have overrides bleed in

Problem/Motivation

We should move language_negotiation_url_prefixes_update() logic to a static method in ConfigurableLanguage so it can be reused and remove language_negotiation_url_prefixes_update().

Proposed resolution

Move logic to a static method in ConfigurableLanguage.
Remove language_negotiation_url_prefixes_update()

Remaining tasks

Create a patch

User interface changes

None.

API changes

The following global function is removed:

language_negotiation_url_prefixes_update()

Use ConfigurableLanguage::updateAllUrlPrefixes() instead.

Missing translations revisions

$
0
0

Since September in our site some nodes are disappearing. We had 8.5.X but now we have latest core version 8.6.2.
We have multilingual site and there are more than 10 persons adding and editing content and the same time.
Content that have problems: is translatable and working with revision system.

We have seen that node_field_data, node__body and other node field registers are deleted, but they are in revision tables.
No logs and no errors in watchdog, no deleting actions from editors, only disappear "node data" from database but not "node revision data".

What are the steps required to reproduce the bug?

We don't know why this happens and how to reproduce. Things to be in mind:
- Only happens in office hours, maybe problem is related with multiples access and same time.
- Only happens in content with a lot of editions, we have old content types with a lot of nodes with no problems.
- Only happens with translation entity, never happened with source translation.

We use following sql code to get orphans revisions:

SELECT distinct nfr.nid, nfr.langcode, nfr.vid
FROM node_field_data nfd
LEFT JOIN node_field_revision nfr ON nfd.nid = nfr.nid
where nfd.langcode != nfr.langcode
AND nfr.langcode NOT IN (
SELECT nfd2.langcode
FROM node_field_data nfd2
WHERE nfd2.nid = nfd.nid
)
AND nfr.vid = (
SELECT nfr2.vid
FROM node_field_revision nfr2
WHERE nfr2.nid = nfr.nid
AND nfr2.langcode = nfr.langcode
ORDER BY nfr2.vid DESC
LIMIT 0,1
)
ORDER BY nfr.nid DESC;

We have checked crons, code, a lot of process and we didn't get anything.

We have tried changing php max_input_vars to 3000 too but with no luck.

Any ideas?

Installer tests fail if contrib driver hides database credentials form fields

$
0
0

Problem/Motivation

If a contrib driver sets database credentials fields to 'hidden' in the installation form, Installer tests fail because Mink cannot find the fields to be set.

Proposed resolution

\Drupal\Core\Test\FunctionalTestSetupTrait::installParameters() should get the correct form fields used by the driver before passing these into submitForm.

Remaining tasks

Rework patch

User interface changes

none

API changes

none

Data model changes

none

Install profile is disabled for lots of different reasons and core doesn't allow for that

$
0
0

Problem:

Issue summary:

NOTE: if you are trying to solve this novice issue, the plan of attack is at http://drupal.org/node/1170362#comment-5050480. We need a simple patch that takes most of http://drupal.org/node/1170362#comment-5011400 but instead of hiding the warning when a profile is not found, it displays its label as "Unknown").

There are multiple issues with install profiles, both within Drupal 7 and on upgraded Drupal 6 sites, these all end up with the same symptom: "Undefined index: distribution_name" due to system_requirements().

Drush 3 and dependencies
When profiles were made into modules, the modules the profiles need were put in dependencies. Unlike other modules, however, these are not real dependencies: your system might still work if you disable some. Like, installing the standard profile then disabling overlay module.

This bug was discovered in #820054: Add support for recommends[] and fix install profile dependency special casing however fixing it would have required an API change for install profile developers, so that issue is only marked against Drupal 8, and workarounds were put into all code dealing with module dependencies to special case profiles instead.

Those workarounds were put into Drush 4/5 as well, but not Drush 3, which is still in use. So any site that runs drush updb with Drush 3 will have its install profile disabled by drush.

There's nothing that can be done about this in drush 3, and the bug is in core, so this issue tried to fix that.

update.php
sun's patches above demonstrate that just running update.php on D7 can disable your install profile, due to some weird things going on in _system_rebuild_module_data()
Sites upgrading from Drupal 6 to a different install profile
In Drupal 6, install profiles were 'run once', this meant that you could make a custom install profile for a site, install it, then never touch the install profile again (including when upgrading). When install profiles became required (half-)modules in Drupal 7, support for this was completely removed - if you install with a profile, we're currently requiring you to upgrade the specific profile you installed with through every possible future version of Drupal core. #1242956: Allow install profiles to be switched starts to discuss this, but since this blocks the upgrade path from D6 it's probably a legitimate bug here too

.

Proposed solution

There are a couple of ways to fix this, and they may be contradictory.

sun's patch started work on automatically ensuring the install profile is enabled every time _system_rebuild_module_data() is called. This would fix install profiles that have been disabled by drush 3 or update.php

However, there is no straight bug fix solution for the situation where a site is no longer using an install profile. For this we could either start allowing people to explicitly disable an install profile, or just make the system tolerant when none is found in the system (for example setting the site to use the 'minimal' profile which should never have any runtime code added to it).

To minimize the number of new comments asking for it, here's a work-around for current Drupal 7 users: You need to enable the profile used to install Drupal by updating the system table. For example: UPDATE system SET status=1 WHERE name='standard'; will enable the Standard profile. If you don't know which profile was used, just use 'standard'.

watchdog() does not type its array arguments

$
0
0

Problem/Motivation

If a third argument is passed to watchdog() that is not NULL or an array, the dblog page at admin/reports/dblog fails with a fatal error. This is because bad data is saved in the serialized 'variables' column in the watchdog table, and is not checked before passing to t() in dblog_overview()

Proposed resolution

Type hint the third argument to watchdog() as array.

Remaining tasks

None. Documentation has now been added, and a fix is committed to D8.

User interface changes

No UI changes.

API changes

Any calls to watchdog() that want to set a $severity level, but do not have $variables arguments for t() interpolation, have to pass array() instead of NULL as the third argument to watchdog().

No API changes. watchdog() will now throw an error if anything other than an array or NULL is given as the 3rd argument to the function.

Original report by cam8001

Recoverable fatal error: Argument 2 passed to t() must be an array, string given, called in /var/www/example.com/modules/dblog/dblog.admin.inc on line 265 and defined in t() (line 1451 of /var/www/example.com/includes/bootstrap.inc

A contrib module passed some bad arguments to watchdog(), the data was saved to the watchdog table, then passed to t() for display at admin/reports/dblog. t() fails on the bad data, and now I cannot view logs at admin/reports/dblog.

I can get around the issue and restore the page's functionality by deleting the offending rows from the watchdog table.

Blocks are created with a default weight of null, not 0

$
0
0

Problem/Motivation

Place a block, but don't submit the block admin form afterwards (or use the experimental Place block module to do it).

The weight of the block is NULL, not 0 in the config, such as:

uuid: d8055768-1043-4b42-9eab-92146e3cc38b
langcode: en
status: true
dependencies:
  config:
    - views.view.who_s_new
  module:
    - views
  theme:
    - bartik
id: views_block__who_s_new_block_1
theme: bartik
region: sidebar_second
weight: null
provider: null
plugin: 'views_block:who_s_new-block_1'
settings:
  id: 'views_block:who_s_new-block_1'
  label: ''
  provider: views
  label_display: visible
  views_label: ''
  items_per_page: none
visibility: {  }

Proposed resolution

Add a hidden (or value?) form input to BlockForm with a default of 0 for new blocks. Make sure block form validation checks that it's an integer.

Possibly, add support for query string to set the weight so it's possibly to position a new block relative to other blocks.

Remaining tasks

Write a patch and tests

User interface changes

none

API changes

none

Data model changes

none


Module uninstall validators are not run on config import

$
0
0

Problem

#2278017: When a content entity type providing module is uninstalled, the entities are not fully deleted, leaving broken reference introduced a new module install validator API, however configuration import does not yet check whether the validators pass. If they fail, module uninstall will throw exceptions.

Proposed resolution

  • Run module install validators from config import.
  • In order to avoid some checks like for configurable fields to be run twice, we want to extend the validator API to support running in two modes: excluding configuration-based checks or not.

Remaining tasks

Do.

User interface changes

-

API changes

- Extend the module uninstall validator by an optional parameter to exclude configuration-based validation checks. No BC break here (addition only).

EntityMalformedException: Missing bundle property on entity of type node in entity_extract_ids() line 7929

$
0
0

Hi.

I have a content type with a file field.

I have a custom module with a hook form alter.

With hook form alter I add a extra submit function to node form.

    $form['actions']['submit']['#submit'][] = 'anexar_aplicacion_submit'; 

In the submit:

function anexar_aplicacion_submit(&$form, &$form_state) {
  
  $reto_nid           = $form_state['values']['reto_nid'];
  $aplicacion_nid = $form_state['node']->nid;

  $reto = node_load($reto_nid);
  $reto->field_aplicaciones[LANGUAGE_NONE][]['target_id'] = $aplicacion_nid;
  field_attach_update('node', $reto);
  field_attach_presave('node', $reto);
  entity_get_controller('node')->resetCache(array($reto->nid));
}


Error is thrown when I create a node of this content type, with the file.
Error is not thrown when I create a node of this content type, without the file.

Error:
EntityMalformedException: Missing bundle property on entity of type node in entity_extract_ids() line 7929

Thank you.

Use CKEditor 5's native <ol type> and <ul type> UX

$
0
0

Problem/Motivation

We "solved" the problem of supporting <ol type> and <ul type> by using the SourceEditing functionality for that.

But in CKEditor 5 32.0.0, they've added a native UX for setting the list type:

Which means that rather than having to edit HTML by hand, the content creator can now do that through the UI! But unfortunately, it currently always generates <ol style="list-style-type:SOMETHING"> and <ul style="list-style-type:SOMETHING">, so we cannot use this.

This is blocked on https://github.com/ckeditor/ckeditor5/issues/11615.

It'd also improve the upgrade path because these attributes would no longer have to get set through the SourceEditing functionality.

Steps to reproduce

N/A

Proposed resolution

TBD

Remaining tasks

TBD

User interface changes

TBD

API changes

None.

Data model changes

None.

Release notes snippet

TBD

Fix a typo in Help message on ckeditor5.module

$
0
0

While checking the ckeditor5 core module, I noticed that in the ckeditor5.module the word "be" is repeated (46:381).

Changing this will have no effect on any code, just a simple typo fix in the help message displayed to the users.

Fix a comment typo in BlockTest

$
0
0

While checking the block core module, I noticed that in the core/modules/block/tests/src/Functional/BlockTest.php file the word "the" is repeated (166:46).

Changing this will have no effect on any code, just a simple typo in a comment.

Seven theme: Fix text alignment on form submit buttons

$
0
0

The buttons don't look consistent. I propose we apply either text-align: left or text-align: center for both buttons.

Fix typo in assertion on ConfigImportUITest

$
0
0

While checking the config core module, I noticed that in the core/modules/config/tests/src/Functional/ConfigImportUITest.php file the word "theme" is repeated.


Field Groups marked as required are missing red asterisk

$
0
0

Problem/Motivation

When using the field group module, groups that contain required fields are not styled to have the red asterisk to denote that group has required fields. The form-required class is in the mark, but no styles for it.

Steps to reproduce

  1. Added fields to a node that are required
  2. Create fields groups
  3. Ensure the Mark group as required if it contains required fields. option is selected for a group
  4. Observe when creating content that the red asterisk is missing

Proposed resolution

Update the styles to account for this. The core/themes/claro/css/components/form.pcss.css has some styles already for the form-required class, but they are too specific. I would think making this style selector less specific would fix it, but there could create issues if the after pseudo element is intended for other use.

Disable CKEditor 5's automatic link decorators (in Drupal filters should be used instead) + explicitly test manual link decorators

$
0
0

Problem/Motivation

Discovered in #3246169: Embedded media are not linkable through UI; already linked embedded media are unlinked (data loss!).
See https://ckeditor.com/docs/ckeditor5/latest/api/module_link_link-LinkConf... and https://ckeditor.com/docs/ckeditor5/latest/api/module_link_link-LinkDeco....

Try this by applying

diff --git a/ckeditor5.ckeditor5.yml b/ckeditor5.ckeditor5.yml
index f6eaf90..80467ef 100644
--- a/ckeditor5.ckeditor5.yml
+++ b/ckeditor5.ckeditor5.yml
@@ -224,6 +224,9 @@ ckeditor5_link:
   ckeditor5:
     plugins:
       - link.Link
+    config:
+      link:
+        addTargetToExternalLinks: true
   drupal:
     label: Link
     library: ckeditor5/ckeditor5.link

Now every link you create that matches ^(http|//) will get target="_blank" rel="noopener noreferrer" applied.

This feature makes a ton of sense in CKEditor 5, where the generated HTML is the served HTML. But it does not make sense in Drupal, where we prefer not storing (hardcoding) such decisions in the database, and instead filter it on output, using the filter system.

For this example, the Drupal equivalent is https://www.drupal.org/project/extlink.

Steps to reproduce

See above.

Proposed resolution

  1. Disable CKEditor 5's automatic decorators entirely, both on server (done) and client (TODO).
  2. Add explicit test coverage for manual link decorators, for the drupalImage (done) and drupalMedia plugins in particular (TODO).

Remaining tasks

  1. Discuss with CKEditor 5 team to determine best approach.Done. Conclusion: throwing an exception when automatic decorators are configured, both in PHP and in JS.
  2. Prevent automatic link decorators on server side.
  3. Prevent automatic link decorators on client side.
  4. Test coverage for automatic link decorators being prevented on server side.
  5. Test coverage for manual link decorators working with <img>.
  6. Manual link decorators working with <img>.
  7. Test coverage for manual link decorators working with <drupal-media>.
  8. Manual link decorators working with <drupal-media>.

User interface changes

None.

API changes

None.

Data model changes

None.

TermStorage::loadChildren returned elements are not sorted by weight, name

$
0
0

When I upgrade Drupal core from 8.4.6 to 8.6.16 I faced an issue in TermStorage::loadChildren.

I was using this function
:\Drupal::entityTypeManager()->getStorage('taxonomy_term')->loadChildren($parent_term->id());
for manging the website navigation by parent client relation . But after the upgrade the order was not by weight .

Adding the API page, someone else also faced the issue: https://api.drupal.org/api/drupal/core%21modules%21taxonomy%21src%21Term...

Adding a patch to fix this by adding :" ->sort('weight', 'ASC'); to the getChildren function.

Error on PHP8 during execution Database::closeConnection()

$
0
0

Problem/Motivation

After execution a batch operation on PHP8 we use Database::closeConnection() that should avoid the MySql gone away error after a long batch operation. But Drupal throw an error

WD php: Error: User-supplied statement does not accept constructor       [error]
arguments in PDO->prepare() (line 544 of  ../docroot/includes/database/database.inc). Error: User-supplied statement does not accept constructor arguments in PDO->prepare() (line 544 of ../docroot/includes/database/database.inc).

Steps to reproduce

Run some batch operation and then try to call Database::closeConnection() on PHP8

Proposed resolution

I would suggest to apply fix that check in __destruct() method if we have DB connection

  public function __destruct() {
    if ($this->needsCleanup) {
      if (get_object_vars($this->connection)){
        $this->nextIdDelete();
      }
    }
  }

Fix a comment typo in common.inc

$
0
0

I noticed that in the core/includes/common.inc file the word "it" is repeated (468:28).

Changing this will have no effect on any code, just a simple typo in a comment.

Viewing all 294759 articles
Browse latest View live


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