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

Use drupalci.yml for composer dependency min/max testing

May 30, 2018, 11:58 am
$
0
0

Problem/Motivation

Eventually, DrupalCI will give us a way to tie different build processes to different needs, using the idea of 'triggers.'

One such build trigger will likely be a dependency min/max test. This could be run all the time, or it could be run once a week, or what-have-you.

This issue discusses how to address a dependency min/max test.

Currently, since we don't have that build trigger available, we'll have to discuss how to implement this type of test by running the testbot in this issue.

Proposed resolution

Use a drupalci.yml to perform these steps:

  • composer update --prefer-lowest
  • composer run-script drupal-phpunit-upgrade
  • run-tests.sh
  • composer update
  • run-tests.sh

Remaining tasks

User interface changes

API changes

Data model changes

↧
Search

Add the Media Library module to Drupal core

April 18, 2018, 7:52 am
$
0
0

Problem/Motivation

The current Media administration experience is not very visual, and does not look like what most people expect from a CMS.

Proposed resolution

We should update the view at /admin/content/media to look more modern - displaying a grid of media cards that show a preview of the media and metadata (attributes/fields) that make sense for each media item.

To give more flexibility to site builders and themers, each media item in the library is rendered in a new view mode called "Media Library", which is customizable like any other view mode.

This updated view will also be the basis for a new Field Widget, to allow visual selection of Media while editing/creating content. This widget will be added in another issue, but part of why this is being added in a new experimental module is to have a place for us to iterate on the widget and other code related to the Media Library experience.

Review the current patch. Discuss UX feedback.

Note for committers - on commit, please ensure that "jan.stoeckler, webflo, seanB, chr.fritsch, DyanneNova, yoroy, dennis-cohn, rfmarcelino, andrewmacpherson, benjifisher" is added to the issue credits. This is ported over from #2834729: [META] Create an MVP for adding and re-using Media.

User interface changes

The view at /admin/content/media looks different, but is functionally the same.

API changes

None.

Data model changes

None.

↧
↧

Option for 'Transform dashes in URL to spaces in term name filter values' on term arguments doesn't affect the query

April 20, 2016, 2:03 pm
$
0
0

The term name argument validator has an option to convert dashes to spaces in the argument value, which means that you can have a URL like 'myview/term-name-with-spaces'.

The argument validator handles this correctly, but the query that is run with this by the term name argument is incorrect. With a simple view of article nodes and the tags field that comes OOTB with core, I get this clause in the query:

WHERE (( (taxonomy_term_field_data_node__field_tags.name = 'has-spaces') )AND(( (node_field_data.status = '1') )))
ORDER BY node_field_data_created DESC

Argument validator plugins only return a boolean from validateArgument(), but on D7 the equivalent function views_plugin_argument_validate_taxonomy_term::validate_argument() doctored the argument value on the argument handler like this:

        if ($term && (empty($vocabularies) || !empty($vocabularies[$term->machine_name]))) {
          if ($type == 'convert') {
            $this->argument->argument = $term->tid;
          }

There doesn't seem to be any provision for this in D8 -- argument validator plugins don't seem to be able to influence the argument value that the rest of the view uses.

↧

Managed file form element duplicated id attribute

October 17, 2016, 4:07 am
$
0
0

There is a duplicated id attribute when displaying the managed file form element using the default template implementation. The file upload field seems to get in focus when the title label is clicked. Also this bug is related to issue #2705471.

The wrapping div container and the file upload input element have the same id attribute.

A Bug in the implementation - trying to synchronize the file input element "id" and the "for" attribute in it's title tag results a duplicated id attribute.

The template files:

core/themes/classy/templates/content-edit/file-managed-file.html.twig
core/modules/file/templates/file-managed-file.html.twig

 20 <div{{ attributes.addClass(classes) }}>
 21 {{ element }}
 22 </div>

The file core module file:

core/modules/file/src/Element/ManagedFile.php

347 
348     // Let #id point to the file element, so the field label's 'for' corresponds
349     // with it.
350     $element['#id'] = &$element['upload']['#id'];
351

I am trying to find the best solution for the both issues with a single patch.

↧

Deleting User will cause WSOD on migrated comments

May 30, 2018, 7:08 am
$
0
0

I couldn't find another issue related to this, but as the title states, there is an issue. We migrated a site from D7 to D8 and a month or so later, removed some older users. Some of these users left comments on nodes and when we try to visit those nodes, we get a WSOD.

The error that generates from that is this:

Error: Call to a member function label() on null in Drupal\comment\Entity\Comment->getAuthorName() (line 408 of /app/web/core/modules/comment/src/Entity/Comment.php)

The code surrounding this is checking for target_id first then grabbing entity->label() from the object. That doesn't seem correct and I am attaching a patch to address this.

↧
↧

badly formatted sample code in core.api.php for hook_config_import_steps_alter

May 25, 2018, 8:19 am
↧

Warn users of what features are not available on a given entity type

February 9, 2017, 9:19 am
$
0
0

Problem/Motivation

Content Moderation adds two options to Workflow states; "Published" and "Default revision". Default revisions are ok for all entity types that use Content Moderation because we currently require revisions, however not all revisionable entity types (even in core) are publishable.

(The publish we are talking about here is related to the 'status' field, not a workflow state called 'Published'.)

See also:
#2830581: Fix ContentModeration workflow type to calculate correct dependencies
#2850627: Do not require a revisionable entity type when using content_moderation.
#2825973: Introduce a EditorialContentEntityBase class for revisionable and publishable entity types
#2812811: Use EntityPublishedInterface during moderation of entities to add support beyond nodes
#2850353: Test content_moderation with a non-bundleable content entity
#2842692: Warn users before enabling moderation on an entity type that can't be (un)published

Proposed resolution

Show a warning in the entity type selection modal in the workflows settings, if an entity type isn't publishable.

Remaining tasks

User interface changes

API changes

Data model changes

↧

User email should not be case sensitive

May 17, 2015, 11:07 am
$
0
0

Problem/Motivation

If a user registers an account using capital letters in their email address, to be able to reset their password later they need to enter email with exact same capitalization. If they enter email as all lowercase or a different capitalization from original, they aren't able to reset their password.

(I suspect there should be a duplicate issue, but wasn't able to find it).

Proposed resolution

User email should not be case sensitive

Remaining tasks

Contributor tasks needed
TaskNovice task?Contributor instructionsComplete?
Try to reproduce the issue in Drupal 8NoviceInstructions

User interface changes

API changes

↧
Search

Install profile in settings.php and mismatch check makes re-installs of Drupal hard

May 25, 2018, 6:11 am
$
0
0

Problem/Motivation

#2156401: Write install_profile value to configuration and only to settings.php if it is writeable changed from always writing the install profile to configuration, and only to settings.php if settings.php is writable.

Change record is here: https://www.drupal.org/node/2538996

However this leaves a relatively annoying issue when re-installing Drupal.

Steps to reproduce:

1. Install minimal profile
2. Drop the database, try to reinstall with Standard (doesn't matter if this is via drush or the UI)
3. You'll see an error message about the install profile in settings.php not matching the chosen profile.

Proposed resolution

Completely stop writing the install profile to settings.php regardless of whether it's writable or not.

Remaining tasks

User interface changes

API changes

We'e already deprecated getting the install profile from settings.php and accepted it won't always be available there for new sites where settings.php is read-only. Given this change will also only affect new sites, it should not in practice break bc that anyone is relying on at this point.

Data model changes

↧
↧

An illegal choice has been detected. on exposed multiple checkboxes form submit

November 15, 2017, 6:05 am
$
0
0

I just fix a problem about "An illegal choice has been detected..." with module "better_exposed_filters"

Configuration :
- Module "better_exposed_filters" installed
- Create a view
- Expose a filter as collapsible checkbox with better exposed filter
- Check the filter option remember

Then go to your view
- Check one checkbox on the collapsible list and then submit (it work perfectly)
- Go to another page and come back to your view (or actualize the page)
- Then an error appear with message "An illegal choice has been detected..."
- As you can see, all checkboxes are checked

The bug came from the class "Drupal\views\Plugin\views\filter\FilterPluginBase"
To fix it, open the file and replace last line from the method : "storeExposedInput"
=> you must remove integer values : 0

$session[$this->options['expose']['identifier']] = $input[$this->options['expose']['identifier']];

TO

// Fix multiple checkbox (Illegal Choice has been detected)
$value = $input[$this->options['expose']['identifier']];
if($this->options['expose']['multiple'] && is_array($value)){
  $value = array_filter($value, function($value) {
    return $value !== 0;
  });
}

$session[$this->options['expose']['identifier']] = $value;

Sorry, but I can't make a pull request right now, but I hope it will help

↧

Convert taxonomy terms to be revisionable and publishable

May 21, 2017, 7:42 am
$
0
0

Problem/Motivation

As decided in #2745619: [policy, no patch] Which core entities get revisions?, taxonomy terms should be converted to be revisionable and publishable.

Proposed resolution

Do it.

Remaining tasks

Decide how we want to deal with term hierarchies, see #2705389-48: Selected content entities should extend EditorialContentEntityBase or RevisionableContentEntityBase.

User interface changes

In the vocabulary overview page, the drag-and-drop interaction will be disabled if the vocabulary has at least one term with a pending revision:

API changes

Nope.

Data model changes

Taxonomy terms are now revisionable and publishable.

↧

Entity query condition count seems off

April 15, 2018, 10:41 pm
$
0
0

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21...

The documentation here says that "The size of the conditional is the size of its conditional array minus one, because one element is the conjunction." After getting some unexpected results though I stepped through the code and found that the conjunction is not in the conditions array that the count function is going through (please see screenshot).

As such to get the expected results we had to use the conditions() function to get the array of conditions and pass them through count() ourselves.

↧

Remove deprecated AllowedTagsXssTrait from ListItemBase

September 30, 2016, 5:05 am
$
0
0

The AllowedTagsXssTrait is deprecated in favor of FieldFilteredMarkup and will be removed in Drupal 9.

We need to:

  1. Remove the Use statements for the trait from core code. (see #6 and #13)
  2. Replace calls to AllowedTagsXssTrait::fieldFilterXss() with FieldFilteredMarkup::create()
  3. Replace calls to AllowedTagsXssTrait::allowedTags() with FieldFilteredMarkup::allowedTags()
  4. Replace calls to AllowedTagsXssTrait::displayAllowedTags() with FieldFilteredMarkup::displayAllowedTags()

#17 takes care of the above and solves the test failures. dmitryl is re-rolling a patch that removes the trait's php file.

↧
↧

Add hooks to acton on a new revision being created

May 28, 2018, 3:13 am
$
0
0

Problem/Motivation

This is a part of #2960253: [meta] Allow Paragraphs widget/field and similar use cases to to be considered translatable which is being split into 3 separate issues and converted to a meta issue.

* While we don't want the paragraph field values to be replaced, we basically need to be able to apply the same/similar logic to our referenced entities. So when a new "merge-revision" of the node is created, we want to do the same to the paragraphs, so that they too merge their translatable/untranslatable fields together. And later on when we have fancy conflict resolution that will replace this special case, we'll need to be able to apply that recursively as well.

Proposed resolution

Add hook_entity_revision_create() and hook_ENTITY_TYPE_revision_create()

Remaining tasks

User interface changes

None

API changes

Two new hooks, no changes.

Data model changes

None.

↧

Make TestServiceProvider more readable (cleanup)

September 25, 2017, 7:13 am
↧
Search

Provide a relationship from the revision table to the main table

January 19, 2016, 2:38 am
$
0
0

Problem/Motivation

Views currently doesn't provide a relationship from the revision table back to the base table by default.
There are though workarounds in both block_content and node module for that.

Proposed resolution

Let's add it.

Remaining tasks

User interface changes

API changes

Data model changes

↧

REST views: double encoding of apostrophes in REST Export display

December 5, 2017, 6:34 pm
$
0
0

In the below sample of a REST export view output in JSON format, you can see that an apostrophe character (ASCII code 39) is double encoded in the form of "\u0026#039;".

[{"book_background_pattern":"\/sites\/default\/files\/a_visit_to\/background_images\/avt_s18_background_pattern.jpg","cover":"\/sites\/default\/files\/a_visit_to\/background_images\/avt_doc_S18_cover.jpg","dark_color":"0073b9","accent_color":"a92825","light_color":"c7d5ee","header_background":"\/sites\/default\/files\/a_visit_to\/background_images\/avt_s18_header.png","title":"The Doctor\u0026#039;s Office: A 4D Book","vuforia_device_database":"\/sites\/default\/files\/a_visit_to\/doctors_office\/targets\/a_visit_to_doctors_office.zip","id":"8799","author":"Blake A. Hoena","illustrator":"","series":"A Visit to...","series_id":"268"}]

Steps to reproduce:

  1. Create a node with a title containing an apostrophe character.
  2. Create a view containing a REST Export display.
  3. Set the view format to "Fields."
  4. Add the "Content:Title" field to the field list.
  5. Preview the results of the view.
  6. Observe that the apostrophe character is double encoded.
↧
↧

JavaScript tests shouldn't exit 0 if they fail

May 24, 2018, 9:59 am
↧

FieldItemList::equals is sufficient from the storage perspective but not from the perspective of ContentEntityBase::hasTranslationChanges

November 9, 2016, 4:29 am
$
0
0

Problem/Motivation

There are might be use cases in custom/contrib where we have to take a different decision depending on if we are comparing a field item list from within ContentEntityStorageBase::hasFieldValueChanged, ContentEntityStorageBase::populateAffectedRevisionTranslations or from within ContentEntityBase::hasTranslationChanges.

ContentEntityStorageBase::hasFieldValueChanged needs to compare only the values that are saved to the storage that would be target_id only in case of entity references.

ContentEntityStorageBase::populateAffectedRevisionTranslations and ContentEntityBase::hasTranslationChanges on the other side might need much more complicated decisions to be made e.g. in our system we have translation changes on a entity reference field if the referenced entities have been changed which we are mainly using for inline editing. In this case FieldItemList::equals is not sufficient because of two reasons:
1. We are not able differentiate wherefrom the function is called.
2. We do not know the language for which it is called in case of not-translatable field but ContentEntityBase::hasTranslationChanges might still wanna compute differences only for entities of a specific language as when the parent is rendered its references are retrieved in the current language of parent.

Proposed resolution

To solve the problem we introduce a new method FieldItemListInterface::hasTranslationChanges which has two parameters - one for the list to compare against and one for the language to consider. This new method will by default just call ::equals, but to give more developer possibilities the new method will be called to compare the lists from within ContentEntityBase::hasTranslationChanges instead the equals.

Remaining tasks

Review, Change Record, Commit.

User interface changes

None.

API changes

New method FieldItemListInterface::hasTranslationChanges.

Data model changes

None.

↧

Make it possible to retrieve all the last installed entity type definitions at once from the update manager

May 29, 2018, 8:53 am
$
0
0

Problem/Motivation

In many update functions we need a way to get a list of all entity type definitions and then filter them by some criteria (e.g. only revisionable entity type).

At the moment, we can only do this by going through the entity manager, which holds the "live" definitions, and then retrieve the last installed definition manually from the entity definition update manager. However, accessing the live definitions has resulted in many bugs in the past, and sometimes we even forget that we only need to work with the last installed definition, not the live one.

Proposed resolution

To make writing generic update functions easier, add a method to EntityDefinitionUpdateManager which retrieves all the last installed entity type definitions at once.

Remaining tasks

Discuss, review.

User interface changes

Nope.

API changes

API addition.

Data model changes

Nope.

↧
Viewing all 295311 articles
Browse latest View live
Search