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

PluginDependencyTrait::calculatePluginDependencies() does not handle theme provided plugins

$
0
0

Problem/Motivation

Layout Discovery allow themes to declare layouts and Field Layout allow display modes to use theme-defined layouts. The thing is that if you use a theme-defined layout then export the display mode configuration, the theme is going to be in the dependencies of the config object under the "module" key.

Steps to reproduce

  1. Install Drupal standard profile
  2. Enable Field Layout
  3. Copy core/modules/system/tests/modules/layout_test/layout_test.layouts.yml to core/themes/bartik/bartik.layouts.yml
  4. Copy core/modules/system/tests/modules/layout_test/templates to core/themes/bartik/templates
  5. Rebuild caches
  6. Go to admin/structure/types/manage/article/display and set the layout to one the those in the "Layout test" category
  7. Save and export configuration

Expected: the theme is in the dependencies.theme section of the core.entity_view_display.node.article.default.yml file
Current: the theme is in the dependencies.module section of the core.entity_view_display.node.article.default.yml file

Proposed resolution

TBD

Remaining tasks

Contributor tasks needed
TaskNovice task?Contributor instructionsComplete?
Create a patchInstructions
Add automated testsInstructions
Add steps to reproduce the issueNoviceInstructionsDone

User interface changes

None.

API changes

None.

Data model changes

None.


Inconsistent ordering of views of content in Umami

$
0
0

Problem/Motivation

I have set up the Umami demo on my local machine and on simplytest.me.

The order of articles/recipes on the home page is inconsistent.

Local:

Simplytest.me

This is because all the recipes/articles all have the same creation time, so the sort is undefined.

This in no ways impacts Umami when used as a demo, but does make it more difficult to A/B test changes, especially if we start using BackStop or similar to check for regressions.

Proposed resolution

Add creation dates to the content – either fixed or relative to the install date.

Improve ConfigEntityUpdater

$
0
0

Problem/Motivation

#2989256: Old post_update functions that ->save() config entities without calling ->trustData() first mask errors in other post_update functions shows that whilst the ConfigEntityUpdater is useful we can improve it.

Proposed resolution

@tim.plunkett suggests adding three new methods updateAll, updateDependencies, updateCallback and deprecating the old update method.

Remaining tasks

User interface changes

None

API changes

New methods:

  • ConfigEntityUpdater::updateAll()
  • ConfigEntityUpdater::updateDependencies()
  • ConfigEntityUpdater::updateCallback()

Deprecate:

  • ConfigEntityUpdater::update()

Data model changes

None

Update the Workflows module description

$
0
0

Problem/Motivation

The module description should only be one sentence that easy to understand for new users. It should also be so short that users don't need to scroll sideways.
See https://www.drupal.org/docs/develop/documenting-your-project/help-text-s...

Proposed resolution

Reword the description to something like "provides an interface to create workflows with transitions between different publication states."

Remaining tasks

None

User interface changes

This is a UI text change.

API changes

None.

Data model changes

None.

Show field/field-storage summary instead of field type on field listings

$
0
0

Problem/Motivation

From #1847596-266: Remove Taxonomy term reference field in favor of Entity reference

I noticed a minor labeling inconsistency while updating the hook_help(). When you add a field, you select Taxonomy term under References in the Add Field UI. However, once you've configured the field, it's listed simply as Entity reference with no indication that it has anything to do with taxonomy. I don't think that's worth blocking this patch on, but it might be worth a followup issue. (Really it'd actually be a followup to #2446511: Add a "preconfigured field options" concept in Field UI I think.)

Proposed resolution

TBD

Remaining tasks

  • Address the suggestions from Comment #28.
  • Usability review

User interface changes

TBD

API changes

TBD

Update the Content Moderation module description

$
0
0

Problem/Motivation

The module description could be extended a bit to give more detail to explain that other modules are needed to use this.

Proposed resolution

Reword the description to something like "Provides publication states that can be used by other modules to moderate content."

Remaining tasks

None.

User interface changes

This is a UI text change.

API changes

None.

Data model changes

None.

Deprecate Schema::fieldSetDefault and Schema::fieldSetNoDefault, they're not used

$
0
0

Problem/Motivation

Schema::fieldSetDefault and Schema::fieldSetNoDefault, and their legacy procedural counterparts db_field_set_default and db_set_no_default, are implemented in the core db drivers, and are tested in SchemaTest, but in fact are used nowhere in core.

IMHO all these methods should just be deprecated, in favor of Schema::changeField with a full field specification passed in.

Some db systems may not have the DDL specific for adding/removing only the default value of a field, forcing therefore to use changeField anyway. But in that case you would have to introspect the field spec from the actual field to be changed, and there are cases when this can be messy (for example to determine if a field is unsigned).

Proposed resolution

Deprecate Schema::fieldSetDefault, Schema::fieldSetNoDefault, as well as db_field_set_default and db_set_no_default.

Remaining tasks

1. Discuss/agree if this makes sense
2. Write patch
3. The rest

User interface changes

none

API changes

2 public methods in the Database API deprecated

Data model changes

none

Replace all calls to db_insert, which is deprecated


Route options for links.menu.yml

$
0
0

Problem/Motivation

What is the way to provide query parameters or other route options for entries in links.menu.yml?

my_module.csv_export:
  title: 'CSV Export'
  enabled: 1
  route_name: view.csv_export.rest_export_1
  options:
    query:
      '_format': csv

Proposed resolution

Document in menu.api.php, specificaly section on @section sec_links how to add options such as query strings.

Remaining tasks

Write a patch.

User interface changes

n/a

API changes

n/a

Data model changes

n/a

Add @internal to core classes, methods, properties to Controllers

$
0
0

Follow-up to #2873395: [meta] Add @internal to core classes, methods, properties

Problem/Motivation

https://www.drupal.org/core/d8-bc-policy#controllers
Core modules contain many route controllers that are bound to individual routes, as well as form classes. These controllers are not part of the API of the module unless specifically marked with an @api tag on the method or class.

Proposed resolution

Add @internal tag to the Test classes

How to fix thisissue

  1. Read the description for a category in its issue
  2. Identify and confirm an example. Ask in IRC if unclear.
  3. Search core for the relevant category.
  4. Add @internal per the backwards compatibility policy.
  5. Reviewers should confirm that each @internal mention is appropriate for that category according to the policy.

Remaining tasks

Make the Patch and post it

User interface changes

None.

API changes

There should be no implicit API changes.

Deprecate BC layer for #2670360

Problem with the moderation state filter in views with multilingual content

$
0
0

I have created a new translatable content type and associated a workflow with 3 states to it. I created a new instance of this type and also created it's translation. Also a view has been created where the filter criteria was set to the Final (published, default revision) moderation state. As I set the moderation state of the original item to this Final value, the translated one seemed to remain in it's previous state (Draft), but the view lists both of the records like both were in the Final state.

[meta] Replace calls to deprecated db_*() wrappers

$
0
0

Problem/Motivation

#1894396: Mark db_*() wrappers in database.inc as @deprecated for 9.x deprecated the db_* family of functions. Let's remove all usages in core.

Proposed resolution

For each function below:

  1. Find any usages. If there are none, mark that function as done in the list.
  2. If there are any sub-issues that are not RTBC, review them before proceeding to the next step.
  3. Open an issue (Category: Task, priority: Normal, make this issue the parent issue) to replace all usages of the function (except tests for the function itself) and link the issue below.
  4. Open follow-up issues to inject dependencies as appropriate.

Following functions have just been defined in Drupal Core but are not being used anywhere other than Tests.

Done:

Remaining tasks

User interface changes

API changes

Data model changes

Replace all calls to db_truncate, which is deprecated.

Custom callbacks doesn't work

$
0
0

Problem/Motivation

The date type element has #date_date_callback option which can be used to alter it.
But it doesn't work properly because of function_exists() function inside processDatetime method of Datetime element. It always returns FALSE for all callbacks added in the #date_date_callback option.

Proposed resolution

Repace function_exists() by call_user_func_array() to be able execute callback with context


Consider renaming "Access: None" to "Access: Unrestricted"

$
0
0

Problem/Motivation

When editing a View, the "None" access plugin (Drupal\views\Plugin\views\access\None) shows up in the "Page settings" section as "Access: None". I think this is misleading since it could be reasonably interpreted as "no access is allowed", whereas the exact opposite is true: unrestricted access is allowed.
 None" in the "Page settings" Views configuration section

Proposed resolution

I propose renaming "None" to "Unrestricted", so the "Page settings" text reads "Access: Unrestricted", which more accurately describes the situation.

Edit hook_help text and module description for Workflows module

$
0
0

Problem/Motivation

The help text of the Worksflow module does not follow the Help text standards as described in https://www.drupal.org/help-text-standards. It misses the Uses section.
Also the description on the Extend page is too long as this should only be one sentence.

Proposed resolution

Editing the help text and module description according to the standard.

Remaining tasks

  • Add the Uses section
  • Edit the module description used on the Extend page.
  • Replace Drupal::url()

User interface changes

This is a UI text change

GetResponseForExceptionEvent: Prepare for Drupal9

$
0
0

This is just a small quick fix issue which came to light in

#2976394: Investigate problems with Symfony4 now

Drupal9 will jump to Symfony 4.x -- and when we do a bug in CustomPageExceptionHtmlSubscriberTest
will become prominent.

Drupal\Tests\Core\EventSubscriber\CustomPageExceptionHtmlSubscriberTest::testHandleWithPostRequest
TypeError: Argument 3 passed to Symfony\Component\HttpKernel\Event\GetResponseForExceptionEvent::__construct() must be of the type integer, string given, called in /var/www/html/core/tests/Drupal/Tests/Core/EventSubscriber/CustomPageExceptionHtmlSubscriberTest.php on line 141

Style and show content moderation form in Umami

UnroutedUrlAssembler sorts Query params in buildExternalUrl()

$
0
0

Hi,

in UnroutedUrlAssembler::buildExternalUrl there is the following code:

$options['query'] = NestedArray::mergeDeep($parsed['query'], $options['query']);
ksort($options['query']);

This results in the follwoing issue:

I have a link field.
Editor ist inserts a link like this: http://www.example.com&c=1&a=1&b=1
Drupal outputs is as: http://www.example.com&a=1&b=1&c=1

I noticed that because services like affiliate.net need to have query paramters at specific places.
So the questions is what is the intention to sort these parameters?
Can this removed?

Viewing all 296634 articles
Browse latest View live


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