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

Support serialization of private properties

$
0
0

Problem

Because DependencySerializationTrait uses get_object_vars() to collect serializable service properties, but that function cannot access private properties. Because of that, the code below fails, because $entityTypeManager becomes null when deserialization happens.

<?php

final class MyForm extends \Drupal\Core\Form\FormBase {

  private $entityTypeManager;

  public function __construct(\Drupal\Core\Entity\EntityTypeManagerInterface $entityTypeManager) {
    $this->entityTypeManager = $entityTypeManager;
  }

  public static function create(\Symfony\Component\DependencyInjection\ContainerInterface $container) {
    return new static(
      $container->get('entity_type.manager')
    );
  }
}

This seems to be a known limitation for 2 years or so: https://www.drupal.org/project/drupal/issues/2727011#comment-12619886

Proposed solution

Use Reflection or Clousers instead of get_object_vars().

TODOs

Monitor and measure performance changes: https://www.lambda-out-loud.com/posts/accessing-private-properties-php/


UX: Hide entity ID in autocomplete widget

$
0
0

When using an autocomplete widget, Drupal adds the entityID in brackets after the entity name. The entityID is unique, but the text label for that entity may not be, so adding the ID ensures the user will choose the "right" thing and that the "right" thing gets passed back to Drupal.

 Dutch (318), English (270), Yolnu (352)

People often ask why this number in brackets is here, or wonder what it means, or assume it's something else. Some people ask for it to be removed. This has happened to me on four different projects, and now I search for it, it would seem I'm not alone.

"users on my site have been asking me what the number in brackets mean and getting confused by it." - joachim 5 Oct 2012

"I would be very interested in this as I am worried the [nid: 34] style appendage might be unfriendly for some users, and it certainly seems like we need a different solution." - danielb 17 Oct 2008

"one problem for my users is that they are not in the habit of seeing node/entity ID's, so this number in parentheses is confusing when they see it in the autocomplete list of suggested matches." - lucyp 9 Dec 2014

Shall we see if we can fix it?

It seems like such a little thing but it adds up over time, and it's poor UX from core, with many contrib attempts to work around it.

Here are some of the suggested work arounds:

  1. Hide it with javascript
  2. Use views instead
  3. Use one of these modules:

Core issues

* #322383: Autocomplete nid/vid extraction. i.e. CCK Nodereference
* #365241: Add select event to autocomplete feature
* #2537512: uid in the user autocomplete is confusing

Support requests

* Alter Node Reference Autocomplete Output - https://www.drupal.org/node/364768
* Can I remove [nid:n] in node reference fields? - https://www.drupal.org/node/487554
* Best way to get the uid from user in ajax autocomplete - https://www.drupal.org/node/2845850

Stack overflow
* https://stackoverflow.com/questions/1515722/removing-nidn-in-nodereferen...

Stack exchange
* https://drupal.stackexchange.com/questions/200498/hide-the-term-id-on-au...
* https://drupal.stackexchange.com/questions/146983/how-can-i-hide-the-ent...
* https://drupal.stackexchange.com/questions/227954/how-to-remove-taxonomy...

Contrib

Entity Reference (https://www.drupal.org/project/entityreference)

* #1802916: Add option to autocomplete widget to hide entity ID
* #1743342: Remove brackets (id) from display?
* #1411304: Autocomplete hide id options for use with unique labels

Other contrib issues

* #2389317: UX: how to hide entity ID from autocomplete list
* #2400015: When editing an existing entity with entityreference autocomplete fields, load the views dropdowns in Select2 or remove the parenthesised numbers
* #640832: Remove [nid:n] in nodereference fields, so only title is shown
* #157545: Have [nid:n] hidden from user
* #2179861: How To Hide The Term ID After the Term
* #2291575: How the entity id is handled on submission?

(note: Should this be forms system or entity system? Going with forms for now. But entity seems equally likely)

Remove startup configuration for the built-in PHP server when core require PHP 8.0

$
0
0

Problem/Motivation

The file .ht.router.php added in #1543858: Add a startup configuration for the built-in PHP server that supports clean URLs to fix build-in web-server issue https://bugs.php.net/bug.php?id=61286 but since PHP 8.0 there's no such issue, so PR to fix it was closed.

Steps to reproduce

TBD

Proposed resolution

- Get rid of the file and add a test
- Update docs about new PHP_CLI_SERVER_WORKERS env variable (does not work on Windows) that allows more then one child worker in server - it's no longer single threaded

Remaining tasks

- add test and remove the file
- test the behavior on PHP 8.1/7.4
- commit and CR

User interface changes

no

API changes

no

Data model changes

no

Release notes snippet

Removed startup configuration for the built-in PHP server

[IGNORE] Testing

$
0
0

Please ignore this issue. It is only for testing.

Process translation config files for custom modules

$
0
0

Problem/Motivation

It's possible to define a custom content type by placing necessary files into a custom module's directory structure under config/[install | optional]. One might also want that content type to be translatable and may have even gone through the work to define some of the translations. If those translations are placed in config/[install | optional]/language/[language-code], then they should be pulled into the system when the module is enabled.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Arbitrary sizing of media - images for CKEditor

$
0
0

Problem/Motivation
When using "Insert from Media Library" from CKEditor if you could specify width/height of media either by entering values on edit modal or by dragging handle (like "Insert Image" works) would be nice.

How to on fresh install using Bartik theme:

  • Enable Media and Media Library core module
  • Edit text format (admin/config/content/formats) to include "media" to include "Insert from Media Library" icon to "Active toolbar" and enable filter "Embed media" with filter settings set to "Image" for "Media types selectable in the Media Library" and "Media library" for "View modes selectable in the 'Edit media' dialog".
  • Create new content using Article (default) and using new media icon upload and insert image to CKEditor.
  • Currently "Edit media" modal has fields for "Alternate text", "Align" and checkbox "Caption". Having fields for width and height here would be useful. See attached image.

Migrate UI tests should provide the complete log message on failure

$
0
0

Postponed on #3193189: Get only translations for localized vocabularies d6/TermLocalizedTranslation.php

Problem/Motivation

When running a migration with the UI, failures are logged to watchdog but that table is deleted as part of tearing down the test setup. That leaves the developer with no information to find the migration causing the failure, as seen in this screenshot at #2746541-153: Migrate D6 and D7 node revision translations to D8:

We need a way to save and report those errors.

Proposed resolution

Access all pages of /admin/reports/dblog in the test site so the results are saved in the BROWSERTEST_OUTPUT_DIRECTORY directory.

Remaining tasks

Patch
Review
Commit

Mark migration status from schemaorg and schemaorg_ui modules to rdf module as finished

$
0
0

Problem/Motivation

The D8/9 Core RDF module already migrates data from the D7 Core RDF module.

The D7 contrib Schema.org (schemaorg) module and it's Schema.org UI (schemaorg_ui) submodule extend D7 Core's RDF module by:

  1. Declaring the schema RDF namespace (i.e.: in the <html> tag)
  2. Adding the schema.org url to the entity content as RDF metadata
  3. Providing a way for Features to export RDF mappings
  4. Providing a UI to map Schema.org types to Drupal node types and fields

There is only one major version of the schemaorg project (7.x-1.x). As of the latest release (7.x-1.0-rc1), neither schemaorg nor schemaorg_ui declare their own database tables nor store their own data (they both use D7 Core's RDF module to load and store any data they handle). However, they do write variables; which \Drupal\migrate_drupal\MigrationState's plugins discover; so when the Drupal migration wizard gets to the "What will be upgraded?" step, it incorrectly lists both schemaorg and schemaorg_ui as "Modules that will not be upgraded".

Steps to reproduce

  1. Download and Install Drupal 7.84 with the Standard install profile
  2. Download the Schema.org module version 7.x-1.0-rc1 and install both the Schema.org (schemaorg) and Schema.org UI (schemaorg_ui) modules.
  3. Go to /admin/structure/types/manage/page and in the Schema.org settings vertical tab, set Type = WebPage. Click Save content type
  4. On the database, run SELECT * FROM variable WHERE name LIKE '%schemaorg%';. Note you see results like...
    +---------------------------------+----------------------+
    | name                            | value                |
    +---------------------------------+----------------------+
    | schemaorg_ui_type_article       | s:0:"";              |
    | schemaorg_ui_type_page          | s:7:"WebPage";       |
    +---------------------------------+----------------------+
    
  5. Download and install drupal-9.4.x with the Minimal install profile. Enable the RDF (rdf) and the Migrate Drupal UI (migrate_drupal_ui) modules.
  6. Go to /upgrade. Follow the installation process. Note that in the "What will be upgraded?" step, both the D7 "Schema.org" (schemaorg) and "Schema.org UI" (schemaorg_ui) modules are listed as "Modules that will not be upgraded".
  7. Perform the upgrade.
  8. Export config. Note rdf.mapping.node.page.yml shows that the schema:WebPage type was successfully mapped here (note, however, this was achieved by D8 core's \Drupal\rdf\Plugin\migrate\source\d7\RdfMapping migrate plugin looking at D7's rdf_mapping table.

Proposed resolution

Update core/modules/rdf/migrations/state/rdf.migrate_drupal.yml to declare that Core's rdf module migration from the schemaorg and schemaorg_ui modules is finished.

Remaining tasks

  1. Write a patch
  2. Review and feedback
  3. RTBC and feedback
  4. Commit

User interface changes

None

API changes

None.

Data model changes

None.

Release notes snippet

Mark migration status from schemaorg and schemaorg_ui modules to rdf module as finished


Views: AJAX pager doesn't work with exposed filter which has a default value

$
0
0

The original issue is here but for the Drupal7 Views module. Below is copy/paste from that issue. All credits to @uq

Currently when a view uses AJAX pager and exposed filter with a default value at the same time, the view is not providing an accurate result when navigating the page.

To reproduce the issue:
1) Create a content type with a date field
2) Create a number of nodes with above content type
3) Create a View using unformatted list and fields under Format
4) Add Content: [Your date field] under Filter Criteria
5) Select Year under Filter Granularity
6) Check the checkbox "Expose this filter to visitors, allow them to change it" in the Configure filter criterion popup
6) Select a year (e.g. 2014) under Operator
7) Click Apply (all displays)
8) Click Advanced > User AJAX and select Yes
9) Save the view and go to the view page
10) Select "-Year" in the exposed filter and click apply

At this point, you should see a list of nodes with that field and a pager underneath

11) Go to page 2 through the pager

The list of nodes are gone and the exposed filter is reset to the default value.

The issue here was within the javascript of views. If the parameter doesn't have a property or if it is null (in this case, the date value is null after you selected "-Year"), it removes the parameter in the request. If the parameter is removed, Views will set the filter to the default value.

The patch allows empty property to be passed within the query string parameter.

Hope this helps!

Fix spelling for 29 migrate translation related words

$
0
0

Problem/Motivation

Current proposal is to fix the following 29 words, related to migrate translations. Some of the words refer to to D6 modules names, or database column names. Tests with non-English language words have been changed to use English words.
-aimez
-cette
-chien
-chiens
-cnfi
-cochez
-faible
-gato
-heke
-huhuu
-ingoa
-j'aime
-leftjoin
-localizable
-ltlanguage
-maailma
-mlid
-mlids
-moyenne
-nodereference
-objectindex
-overwritable
-plid
-redirections
-sivun
-tnid
-tsid
-userreference
-vous

Steps to reproduce

Proposed resolution

Remaining tasks

Review
Commit
Smile

Split Database tests in 'core' ones and 'driver specific' ones

$
0
0

Problem/Motivation

Follow up to #3129043: Move core database drivers to modules of their own and to #3230714-11: ConnectionUnitTest should be skipped for any database not psql or mysql:

Once #3129043: Move core database drivers to modules of their own is complete, it would be good to split the Database tests in 'core' ones and 'driver specific' ones, with the 'driver specifc' ones running dependent on the db driver in use by the SUT.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Move email field below password field to avoid confusing password managers

$
0
0

When setting up the site information, I am required to enter an administrative user name, an email address and a password in that order.

Firefox interprets this combination as meaning that my email is my username as it immediately precedes the password field, and the password manager will store my email address instead of my username.

To make it easier for password managers to understand the form, this ordering should be changed to place the email field below the password field.

Use a random seed instead of the session_id for CSRF token generation

$
0
0

Problem/Motivation

Drupal implements the Synchronized Token Pattern in order to protect against Cross-site request forgery. OWASP provides a nice description of the mechanism on their CSRF wiki page:

In general, developers need only generate this token once for the current session. After initial generation of this token, the value is stored in the session and is utilized for each subsequent request until the session expires. When a request is issued by the end-user, the server-side component must verify the existence and validity of the token in the request as compared to the token found in the session.

The mechanism implemented in Drupal varies in two details:

  • By supplying the optional $value parameter to CsrfTokenGenerator::get, the token can be varied for different purposes, e.g. per form-id. This is a very reasonable security hardening measure.
  • Instead of randomly generating the token, Drupal uses the session id as the token seed.

The idea behind the second point likely was that in order to make the token per-session it is enough to generate it from the session-id. However, this assumption leads to various problems. First and foremost to #961508: Dual http/https session cookies interfere with drupal_valid_token(). But also to a unnecessary dependency of the CsrfTokenGenerator to the custom way we generate session ids (#2238561: Use the default PHP session ID instead of generating a custom one).

Proposed resolution

Instead of using session-id as the token seed, generate it on demand and store it in the session.

Remaining tasks

User interface changes

API changes

Blocking

Follow-ups

hook_install is invoked before the module's default config is installed during config import

$
0
0

Problem/Motivation

When my module is enabled I need some content to be created, so I'm using hook_install() to create it. As content belongs to specific entities bundles I'm adding the required config entities in /config/install.

When installing the module in a running instance all works as expected.

However when module is installed through a configuration import process - either from Config UI or drush ci or config_installer profile - the whole import process while installing the module.

The error - in my case - is "Field field_myfieldname is unknown", which is a field on one of the bundles I create instances for in my hook_install().

I can't find any similar issue in the queue, and this makes me nervous because creating-content-on-module-install looks to me like a common scenario. That let me thinks the system may work as expected and the problem here is hook_install() shouldn't be used for creating content.

Proposed resolution

If this is a real bug, investigate and fix the problem. It may be related to #2451365: ConfigInstaller has the source storage injected by config importer and module installer but it is done incorrectly, although the IS doesn't mention this error as consequence.
If developers shouldn't rely on config/install/* to be available on hook_install(), then this issue should become a Documentation task and we can update the docs about config/install (Include default configuration in your Drupal 8 module& Co.) as well as hook_install() api.

Remaining tasks

  • Confirming if this is a real issue or documentation should be updated
  • Work on a patch

User interface changes

None.

API changes

None(?)

Data model changes

None.

Allow an install hook in profiles installing from configuration

$
0
0

Problem/Motivation

In #2788777: Allow a site-specific profile to be installed from existing config we excluded profiles from being installed that contain hook_install implementations.

The reasons for this was to exclude complexity, limit the scope of the issue and getting it done.
The complexity can be summarized as:
Install hooks in profiles were so far only called when a site was installed and after all the listed modules were installed and all the configuration was imported. Thus hook_install implementations were able to make a lot of assumptions about the state of the site when the code was executed.
When installing from configuration the configuration is synchronized and the install hooks are called as the extensions are installed and then the configuration is imported. In addition a profile can list modules to install which are not dependencies and, therefore, these modules can be uninstalled. The install hook can therefore also not rely on all the modules being installed.
The canonical example being standard expecting the contact module to be installed.

Right now if a profile wants to be able to be installed from config and still do something extra it has to not implement hook_install and instead define a custom install step.

Proposed resolution

to be defined

Temporary Workaround

See @slucero's comment in #25. There are differences with hook_install, see hook_install_tasks for details. This is an example of how it can be used, replacing "PROFILE" with your profile's machine name:

/**
 * Implements hook_install_tasks().
 */
function PROFILE_install_tasks(&$install_state) {
  $tasks = [
    'PROFILE_install_content' => [
      'display_name' => t('Install default content'),
      'type' => 'normal',
    ]
  ];

  return $tasks;
}


/**
 * Callback function to install default profile content.
 *
 * @see PROFILE_install_tasks()
 */
function PROFILE_install_content() {
  ...
}

Remaining tasks

find solution
implement it
test it
commit it

User interface changes

none probably.

API changes

to be seen.

Data model changes

none.


Allow edit Media items from Media Library modal dialog in CKEditor

$
0
0

Problem/Motivation

At now there are no ways to edit media, that was inserted into content, using Media Library CKEditor widget. So, if user, for example, want to change name of media item, or replace image to other - he have only long way via searching this media item in library on separate page manually, and edit it.

Steps to reproduce

1. Enable Media Library module, and in CKEditor add Media Library button.
2. In node edit form upload and insert some document file (eg "Exomple one.pdf") in CKEditor via "Add Media from Library" button.
3. See, that file name is bad, then try to find way for edit this media to change name of this media - In "Edit media" modal window you will see only align and other widget settings, but not fields of current media.

Proposed resolution

Allow Media items to be edited from modal dialog in CKEditor.

Remaining tasks

Finish patch, discuss scope.

User interface changes

Add link to media edit page.

API changes

None.

Data model changes

None.

[Ignore] In space (and/or this issue), no one can hear patches scream

$
0
0

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Use color input type in the color.module

$
0
0

Problem/Motivation

Drupal has shipped with the Farbtastic library since Garland was added in 2006 to allow users to select colors from a color picker in themes.

Nowadays, the "color" HTML input type is widely supported in all major browsers except IE11 (https://caniuse.com/?search=color) and provides a preferred native UI/UX for this functionality.

Proposed resolution

Use the "color" input type in color.module.

Remaining tasks

  • Deprecate Farbtastic?

User interface changes

The color picker in color.module will be replaced with a native UI, except in IE11 where colors can only be entered by hex code.

API changes

Data model changes

Release notes snippet

The color picker used in theme settings has been replaced with the native browser widget.

Original report by @nod_

Works well on FF, Opera. Chrome implementation of the color widget is messed up, hopefully they will fix it.

Providing a patch to allow testing from other people and hopefully come up with a proper strategy for weird browsers. Color input type is kinda the bleeding edge, we'll get cut.

The js in itself needs quite some work, but outside the scope of this issue.

How to get views field in twig

$
0
0

I'm trying to get a field from a views display in a custom view field template. I've searched extensively and only found the following two approaches functional, however neither provide results that include rewriting configured in views.

{{ view.field.FIELD_NAME.original_value }}
{{ row._entity.FIELD_NAME.value }}

How can I get the field in twig including the rewriting configured in views?

Change the PROPERTY_SEPARATOR to something configurable

$
0
0

Problem/Motivation

CSV import with header containing strings with / are not imported

Steps to reproduce

Proposed resolution

For now change the separator to //
Better solution would be to make it configurable

Remaining tasks

Make the PROPERTY_SEPARATOR configurable in the ex: in migration.yml

User interface changes

API changes

Data model changes

Release notes snippet

Viewing all 296564 articles
Browse latest View live


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