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

Taxonomy Index for unpublished entities

$
0
0

Is there a reason hook_field_update doesn't update the taxonomy index for unpublished entities? I have a use case where editors can manipulate the taxonomy terms of unpublished nodes but these updates aren't inserted into the taxonomy index table. This makes it a challenge to create a view that searches unpublished nodes by taxonomy term name (as opposed to tid, which can be search by taxonomy_field_name_instance)

This would be trivial to patch as it is just an if statement in line 501 of field.api.php.


drupalimage CKEditor plugin should not require data-entity-uuid and data-entity-type when image upload is disabled

$
0
0

If you add an image with the URL field (without the upload widget) the next time you edit the content you can't edit the image with the image button because its data-entity-type and data-entity-uuid attributes are empty.

It should allow editing all images just like the default image plugin. (Or drupalimage should define its own image plugin instead of overriding the default one.)

Only add password strength indicator when attribute present

$
0
0

The PasswordReveal element adds an attribute, data-drupal-password-strength. However, when removing that attribute, the strength indicator still appears.

I have created a patch which looks for that attribute and only adds the indicator if it's present.

The string "Basic page" is not in translation database any more

$
0
0

In Drupal 8.5.8, if you go to localize.drupal.org and download a translation or attempt to translate Drupal Core, you will find that the string "Basic page" is in the POT/PO database.

However, this string is missing from 8.6.2, and actually all 8.6.x releases on localize.drupal.org. It should be there -- it is still the displayed name of the Standard install profile's 'page' content type.

I will try to investigate why this is... one of my tests for the User Guide caught the problem.

When I export the Spanish translation from localize.drupal.org, this is what I get for 8.5.8 in the .po file:

#: core/profiles/demo_umami/config/install/node.type.page.yml:0; core/profiles/standard/config/install/node.type.page.yml:0
msgid "Basic page"
msgstr "Página básica"

This is missing from 8.6.x exports. In fact, the text "core/profiles/standard/config/install/node" doesn't appear in the .po export at all, although there are other .yml files listed from core/profiles/standard/config/install. Just not node types. And they definitely have 2 translatable strings in them: the content type name, and the description. Both are in the 8.5.8 file, and both are missing in the 8.6.2 and other 8.6.x files.

Add #states builder and add documented states and conditions in the code

$
0
0

Problem/Motivation

Current #states DX is the same as it is with Renderable array - developer should remember all states and conditions, nesting of the arrays or every time reffers to the documentation how to build #states array.

Proposed resolution

Create State class that would be easy to convert into the correct array.
Multiple states and conditions also should be covered with new functionality.
States and conditions should be documented as constants.

Remaining tasks

Implement State class.
Add states and conditions documentation.
Add tests.
Update documentation to refer to the new API.

User interface changes

none

API changes

New class and interfaces.

Data model changes

none

CacheableHttpException must pass a $headers argument to HttpException

$
0
0

Not sure if rest.module is the right component for this issue.

Regardless, \Drupal\Core\Http\Exception\CacheableHttpException extends Symfony\Component\HttpKernel\Exception\HttpException. The fourth argument to HttpException must be an array of headers. CacheableHttpException instead passes its $code argument as the fourth value. It should be the fifth.

Patch soon.

Multiple warning messages when having untranslatable fields

$
0
0

Problem/Motivation

While working with content moderation and the paragraphs module. Having some paragraphs with untranslatable fields, and collapsing the paragraphs, after the ajax event we get a duplicated Fields that apply to all languages are hidden to avoid conflicting changes over the paragraph field.

After an ajax action:

This also happens with just Drupal Core after saving a node:

The problem is that drupal_set_message() should not be used in form builders/alters as it's unpredictable when it runs.. An initial submit without an ajax action first results in the form being built again as does every form rebuild, typically done on ajax actions.

Proposed resolution

Convert the message to a render array.

Remaining tasks

User interface changes

API changes

Data model changes

Displace.offsets not taken in account for initial offcanvas height calculation

$
0
0

In core/misc/dialog/off-canvas.js and beforeCreate, the displace offsets (top and botton) are not deducted as in resetSize.

For some themes overriding the dialog system, as Bootstrap for example, it resulting in a 100% window height with the impossibility to scroll down to the bottom of the off-canvas modal when the content is larger than the window height.
As an addition, I guess that the correct height should be setted from the start to cover any case. Plus it doesn't seems to break anything for the basic expected behaviour.


Performance issues with path alias generated queries on PostgreSQL

$
0
0

Problem/Motivation

Queries generated by AliasStorage::preloadPathAlias() taking huge amount of time to execute.
Example below:

2018-07-24 11:02:11 NZST [4923-1] drupal-site@drupal-site LOG:  duration: 10990.918 ms  statement: SELECT url_alias.source AS source, url_alias.alias AS alias, langcode AS langcode, pid AS pid
        FROM 
        url_alias url_alias
        WHERE ((source::text ILIKE '/node/28') OR (source::text ILIKE '/node/29') OR (source::text ILIKE '/node/30') OR (source::text ILIKE '/node/31') OR (source::text ILIKE '/node/24') OR (source::text ILIKE '/node/25') OR (source::text ILIKE '/node/26') OR (source::text ILIKE '/node/27') OR (source::text ILIKE '/node/23') OR (source::text ILIKE '/node/211996') OR (source::text ILIKE '/user/13') OR (source::text ILIKE '/node/87382') OR (source::text ILIKE '/node/134983') OR (source::text ILIKE '/user/25222') OR (source::text ILIKE '/node/216888') OR (source::text ILIKE '/node/149705') OR (source::text ILIKE '/node/216524') OR (source::text ILIKE '/node/209767') OR (source::text ILIKE '/user/24341') OR (source::text ILIKE '/node/216536') OR (source::text ILIKE '/node/135065') OR (source::text ILIKE '/user/53277') OR (source::text ILIKE '/node/173142') OR (source::text ILIKE '/user/30085') OR (source::text ILIKE '/node/188349') OR (source::text ILIKE '/user/69670') OR (source::text ILIKE '/node/147160') OR (source::text ILIKE '/node/147245') OR (source::text ILIKE '/node/174863') OR (source::text ILIKE '/user/59491') OR (source::text ILIKE '/node/216527') OR (source::text ILIKE '/node/174530') OR (source::text ILIKE '/node/178984') OR (source::text ILIKE '/node/154121') OR (source::text ILIKE '/node/172192') OR (source::text ILIKE '/node/216869') OR (source::text ILIKE '/user/93926') OR (source::text ILIKE '/node/216876') OR (source::text ILIKE '/node/216881') OR (source::text ILIKE '/user/93929') OR (source::text ILIKE '/node/215571') OR (source::text ILIKE '/user/58627') OR (source::text ILIKE '/taxonomy/term/50463') OR (source::text ILIKE '/node/202776') OR (source::text ILIKE '/user/47599') OR (source::text ILIKE '/node/210401') OR (source::text ILIKE '/node/215338') OR (source::text ILIKE '/node/87208') OR (source::text ILIKE '/node/190312') OR (source::text ILIKE '/node') OR (source::text ILIKE '/user/1')) AND (langcode IN ('en', 'und'))
        ORDER BY langcode ASC NULLS FIRST, pid ASC NULLS FIRST

Not sure what part of Drupal this issue is actually coming from path alias or PostgreSQL driver.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Migrating D7 body and summary fields to D8

$
0
0

What is the correct way to migrate Drupal 7 body fields (or other Drupal 7 long text with summary fields) to Drupal 8?

For a regular D7 content type being migrated to a D8 content type, for the body, I have tried:

body: body

and

'body/value':'body/value'
'body/summary':'body/summary'

and

body:
plugin: sub_process
source: body
process:
value: value
summary: summary

None of these seem to work. I also need to migrate body format, but wanted to get summary working first, so it is not in my examples above.

Thanks for you help!

ImageItem::generateSampleValue() and Random::image() should allow all extensions the current toolkit supports (instead of hardcoding a fixed set)

$
0
0

Problem/Motivation

After #1014816: Allow image fields to use any extensions the current image toolkit supports (instead of hard-coding jpg, png and gif only), it's possible to use all supported extensions in image fields. However, \Drupal\image\Plugin\Field\FieldType\ImageItem::generateSampleValue() and \Drupal\Component\Utility\Random::image() still assume jpg, png and gif are the only extensions that could exist.

One way of reproducing this issue is:
- Setup a site where Imagemagick is the active toolkit
- Create a media type called "Icon", with an image file that allows only SVG files to be uploaded
- Create a content type that has an entity reference to this media type
- Go to the "Manage Display" of this content type, enable layout builder
- Click "Manage Layout"

You will have a WSOD because it tries to create an SVG sample, and obviously fails.

Proposed resolution

I can see 2 possible approaches:

1) Add a new method to \Drupal\Core\ImageToolkit\ImageToolkitInterface (and implement it in ImageToolkitBase) so that the toolkit plugin is responsible for generating a sample image with given extension and dimensions. So \Drupal\Component\Utility\Random::image() would just call that, instead of assuming the extensions supported or how to generate images.

2) Modify \Drupal\Component\Utility\Random::image(), allowing for other extensions to be special-cased.

Remaining tasks

1) Decide on approach
2) Write patch + tests
3) Review
4) Commit

User interface changes

None

API changes

TBD

Data model changes

None

Users w/o access to content should still have configurable access to the content URL

$
0
0

Problem/Motivation

The \Drupal\views\Plugin\views\field\LinkBase::render() method is presuming too much by not rendering a link whose destination page is not accessible by the current user. The actual behaviour could cover most of the cases but there are still business scenarios when a role should be able to list content, including the URL, but still without the ability to access the content page. This is somehow similar to view label entity access introduced in https://www.drupal.org/node/2661092.

Not having access to a content item, doesn't mean automatically that the content's address cannot be read.

Proposed resolution

Add a new option "bypass_access" in \Drupal\views\Plugin\views\field\LinkBase that allows the site builder to bypass the access check when a link is rendered. The new option should default to FALSE, so the behavior of the actual will not be changed.

Remaining tasks

None.

User interface changes

New option as a checkbox the the Views link fields.

API changes

None.

Data model changes

Views config new option in fields.

Remove manual inclusion of twig.engine in Drupal\Core\Template\TwigEnvironment

Move twig_without() to the TwigExtension where all the other filters are and deprecate

$
0
0

Follow-up to #2568181: [META] Update to Twig 2.x in Drupal 9

Change Record

Problem/Motivation

We are currently using some deprecated code that will be removed or not workable in Twig 2.0.

To help move that along we would like to make the TwigExtension more UnitTestable.

Proposed resolution

  • Move twig_without() to the extension

Remaining tasks

User interface changes

n/a

API changes

n/a

Data model changes

n/a

Replace drupal_get_user_timezone with a service

$
0
0

Problem/Motivation

As part of removing procedural code in includes, we should move drupal_get_user_timezone() from bootstrap.inc to a service in system module.

This process has uncovered the following:

  1. There is a dependency of core on system module in Drupal\Core\EventSubscriber\AuthenticationSubscriber and Drupal\Core\Session\AccountProxy
  2. There is a circular dependency in 'current_user' service: AccountProxy::setAccount() -> drupal_get_user_timezone() -> \Drupal::currentUser();
  3. In AccountProxy::setAccount() we are calling date_default_timezone_set(drupal_get_user_timezone()) which relies on a kind of global state that other code relies on.

Proposed resolution

  • Split out getting timezone into 3 different services:
    1. System timezone
    2. Site configured timezone
    3. User preference timezone
  • Create a 'chained resolver' similar to breadcrumbs which returns the first successful resolution
  • Identify core code that is dependent on system module, and have it rely on system timezone only?
  • Remove date_default_timezone_set(drupal_get_user_timezone()) from AccountProxy::setAccount() and make it more explicit in calling code?

Remaining tasks

Do it

User interface changes

none

API changes

Deprecate drupal_get_user_timezone()

Data model changes

none


<front> _title not quoted in routing.yml

$
0
0

Hi,
is there a reason why to frontpage-title is not single-quoted in system.routing.yml?
If this should be like this, can someone explain why?

Thanks

Remove outdated custom functions for greatest() and concat()

$
0
0

Problem/Motivation

PostgreSQL supports GREATEST() since 8.1 and CONCAT() since 9.1, we don't need to provide user-space implementations for them anymore.

Proposed resolution

Remove them.

Remaining tasks

Review / commit.

User interface changes

Nope.

API changes

Nope.

Data model changes

Nope.

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue categoryTask because nothing is broken.
Prioritized changesThe main goal of this issue is removing dead code from the PostgreSQL driver.
DisruptionNone.

Use new Transliteration functionality in core for file names

$
0
0

Problem/Motivation

Follow-up to #1842718: Use new Transliteration functionality in core for machine names

As a follow-up to #567832: Transliteration in core, we now have a Transliteration class in Core.

@catch mentioned in #1314214: MySQL driver does not support full UTF-8 (emojis, asian symbols, mathematical symbols) we may want to transliterate filenames in core, so that we can have a database-level unique constraint on the URI field in the database. (However, this would presumably mean that transliteration of the field could not be optional).

Proposed resolution

Add a checkbox to the File system form to opt-in for filename transliteration. Transliteration for filenames will be disabled by default, because it's not useful for some languages like Japanese.

Create a smaller Drupal core download, removing tests, for production sites.

$
0
0

Problem/Motivation

This issue is raised for discussion.
Currently a single bare Drupal installation is around 41.3Mb, this includes a multitude of tests. For some people on cheaper shared hosting packages, this is a large part of their storage allowance. On a production site, do we really need all the tests that are normally used for module/theme or core development?

Proposed resolution

Create a new distribution of Drupal 8 core (before release) with all tests and Simpletest removed. This will reduce the installation size by around 15.4Mb and decrease upload time significantly. This should be clearly identified as for production sites, and should indicate the difference to the normal distribution.

Remaining tasks

Document the new distribution, making users aware of the advantage to using this for production.

User interface changes

SimpleTest module can be removed, and all functional tests.

API changes

None

Merge TypedDataManager and TypedConfigManager

Viewing all 295206 articles
Browse latest View live


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