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

Backport Drupal\Component\EventDispatcher from 9.1x to 8

January 21, 2021, 6:42 am
$
0
0

Problem/Motivation

When working on contrib modules I want to make them forward compatible with drupal 9. This is not possible due to Symfony 4.4 EventDispatcher.

This way as mainainer of a module, I can prepare the module for drupal 9.
As site owner/developer I can then prepare the project and don't need to patch every module when upgrading to drupal 9

Steps to reproduce

For instance on the search api module:
Line search_api/src/Event/MappingViewsHandlersEvent.php

 ------ ---------------------------------------------------------------------------------------------------------------------------
  10     Class Drupal\search_api\Event\MappingViewsHandlersEvent extends deprecated class Symfony\Component\EventDispatcher\Event:
         since Symfony 4.3, use "Symfony\Contracts\EventDispatcher\Event" instead
 ------ ---------------------------------------------------------------------------------------------------------------------------

Proposed resolution

Add the Drupal\Component\EventDispatcher\Event to drupal8.
See: https://www.drupal.org/node/3159012

Also see where we tried to solve this for one of the contrib modules #3137602: Drupal 9 compatibility description
The solution is not elegant, and if I understand correctly disables the autoloader :(

Maybe this is already on the roadmap and will be backported to drupal 8, but I could not find an issue about this.
Close this issue if it is, but this way other people can find how to update their contrib modules.

Also I don't know which component this issue is about, so I selected "other" please correct me if you know which component this is.

Thanks

Jack

↧
Search

Umami demo: label in quick edit is not visible

July 23, 2021, 12:38 am
$
0
0

Umami demo: label in quick edit is not visible.
Label color is white, same as the background color. so the label is not visible.

Adding screen recording for same.

↧
↧

Improve Claro styles for core compatibility details on available updates report

February 20, 2020, 9:05 am
$
0
0

Problem/Motivation

#3102724: Improve usability of core compatibility ranges on available updates report is critical and blocking all sorts of things.
The Claro styles aren't terrible, but not good.
But Claro is experimental, and getting this perfect for Claro isn't a critical blocker.
Moving to a follow-up.

Initial state

Before screenshot of Available updates Claro styles

Proposed resolution

Quoting @ckrina from #3102724-100: Improve usability of core compatibility ranges on available updates report:

Here's the definition of details in Claro: https://www.figma.com/file/OqWgzAluHtsOd5uwm1lubFeH/Drupal-Design-system..., and here an screenshot of the defined styles including hover.

Anyway, I'm afraid adding a box inside a box here might me too much visual noise, so I'd try to implement the details without the wrapper. Which is actually following the styles for action-link component (https://www.figma.com/file/OqWgzAluHtsOd5uwm1lubFeH/Drupal-Design-system...). Specifically, I'd use the Action link component on its small size (not sure if it's been implemented yet). You can see here all the defined states:

Remaining tasks

  1. Consider / confirm design.
  2. Implement.
  3. Review.
  4. ...

User interface changes

TBD.

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

↧

migration_lookup process plugin can't use multiple or specific source keys to use for lookup

April 16, 2018, 6:27 am
$
0
0

The migration lookup plugin can be used in two ways:

  uid:
    plugin: migration_lookup
    migration: users
    source: author

There's a single source key, and its value is taken from the 'author' value in the row.

  uid:
    plugin: migration_lookup
      migration:
        - users
        - members
      source_ids:
        users:
          - author
        members:
          - id

The plugin will try multiple migrations in turn, and for each migration to lookup, the source is specified for each one.

In both cases, this is a single source key.

However, migrations often have more than one source key.

Because of how lookupDestinationIds() works, the key used by the lookup plugin is assumed to be the first one:

   * @param array $source_id_values
   *   The source identifier keyed values of the records, e.g. ['nid' => 5].
   *   If unkeyed, the first count($source_id_values) keys will be assumed.

What's missing is:

1. The ability to specify multiple source keys
2. The ability to specify specific source keys. E.g. the migration to use as a lookup might have keys alpha, beta, gamma, and in migration needs to look up using the beta key.

↧

SqlBase::prepareQuery() should be called also on count

December 5, 2016, 2:53 am
$
0
0

Problem/Motivation

Suppose that in a source plugin, extending from SqlBase, you want to override SqlBase::prepareQuery() and use that to add additional tags or meta-data to the query. You don't do that in ::query() method for some good reasons (for example you want to apply tags & meta-data only after the query was defined). If a hook_query_TAG_alter() that uses those tags adds a new condition then SqlBase::count() is lying.

Proposed resolution

Make SqlBase::count() aware of SqlBase::preapreQuery()

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

↧
↧

Make it possible to add relationships to layout builder

September 20, 2018, 5:45 am
$
0
0

Problem/Motivation

Panelizer (at least in D7) allowed you to override a view mode for an entity and add relationships to pull in fields from additional entities (an obvious example being a User view which pulls in data from a profile attached to the user). Panelizer appears to be winding down now so much of what it did is in core, but this relationship aspect is not currently supported by core and is not easily possible in contrib either without swapping out large parts of core.

Proposed resolution

Make it possible for contrib to provide additional context for the layout builder. There are probably a few ways to do this, but the two obvious options to me seem to be one of:

  1. An event that can be subscribed to: Pro - OO with subscribers able to inject services and possibly better 'applies' logic
  2. A hook that modules can implement: Pro - quick and easy to implement!

The places I have identified which would need to invoke whatever process are:

  1. \Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplay::buildMultiple after adding the layout_builder.entity context: Implementers would need to provide real (potentially empty) context.
  2. \Drupal\layout_builder\Plugin\SectionStorage\DefaultsSectionStorage::getContexts: Implementors would need to provide sample context.
  3. \Drupal\layout_builder\Plugin\SectionStorage\OverridesSectionStorage::getContexts: Implementors would need to provide real or sample context.

Remaining tasks

  • Decide what mechanism we want to use (events, hooks or other).
  • Trigger implementations in the identified locations.
  • Make sure there aren't other places that also need to trigger implementations.
  • Test coverage!

User interface changes

None - it would be down to contrib to implement any UI to configure relationships, or to provide them programatically.

API changes

Addition of a mechanism to add additional context.

Data model changes

None - it would be down to contrib to deal with any additional storage requirements.

↧

Simplify ResourceTypeRepository control flow for returning cached data

July 23, 2021, 2:29 am
$
0
0

Refactor ResourceTypeRepository code "return $cached ? $cached->data : $xxx;" calls to ismplified flow as in parent issue using an early return as done in parent issue.

@see ResourceTypeRepository::get

    if ($cached) {
      return $cached->data;
    }
↧

Add a public API for aliasing resource type names

January 9, 2020, 2:50 am
$
0
0

Problem/Motivation

JSON:API has \Drupal\jsonapi\ResourceType\ResourceTypeBuildEvent to allow fields to be aliased, fields to be disabled and resource types to be disabled. Those were the three first public PHP APIs for the jsonapi module.

A logical next one would be to allow resource types to be aliased.

Related: @bojanz in #3032787-21: [META] Start creating the public PHP API of the JSON:API module.

Proposed resolution

  1. Allow entity types to declare a JSON:API resource type name using a jsonapi_resource_type_name entity type annotation key.
  2. Add a new method to \Drupal\jsonapi\ResourceType\ResourceTypeBuildEvent.

(Option 2 is preferred by @e0ipso, @gabesullice and @Wim Leers because it solved more problems: it allows any module to override it. So: more power, more consistency, smaller API surface.)

Remaining tasks

User interface changes

None.

API changes

A new method on \Drupal\jsonapi\ResourceType\ResourceTypeBuildEvent.

Data model changes

None.

Release notes snippet

TBD

↧
Search

Expand unit testing for Drupal/Core/Entity/Sql/SqlContentEntityStorageSchema::performFieldSchemaOperation()

November 18, 2014, 1:30 pm
$
0
0

Problem/Motivation

This is a follow-up on this comment: https://www.drupal.org/node/2364555#comment-9336771

SqlContentEntityStorageSchema::performFieldSchemaOperation() has no unit test coverage, though its wrapper method does: onFieldStorageDefinitionCreate().

There should be wider unit coverage of performFieldSchemaOperation(), since it's the main dependency of a number of wrapper methods for various combination of operations and underlying table mappings.

Proposed resolution

Write a thorough unit test of performFieldSchemaOperation().

Remaining tasks

Review the patch.
Commit the patch.
Rejoice.

User interface changes

API changes

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Unfrozen changesUnfrozen because it only improves automated tests.
↧
↧

Drupal 7 and PHP 8.1

July 19, 2021, 9:45 am
↧

Add jsonapi-specific tag to EntityResource::getCollectionQuery() generated queries

July 19, 2021, 10:55 pm
$
0
0

Problem/Motivation

I am working on a highly access-controlled project and while the requisite entity API access controls are in place, I would like to further restrict by default the entities shown on collections pages by filtering. This is in line with the recommendations at https://www.drupal.org/docs/core-modules-and-themes/core-modules/jsonapi... .

However, I don't want to require this be done on the client side, but rather alter the query programmatically if no filters are passed in the URL. This is easy enough to do with hook_query_TAG_alter(), except there's no tag to indicate the query is for the purposes of satisfying a json:api request.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

↧

[PP-1] Implement a generic revision UI

October 5, 2014, 8:47 am
$
0
0

Problem/Motivation

At the moment there is no generic revision UI, this means that every module with revisionable entities will need to create their own UI similar to the Node revision overview page (node/{node_id}/revisions. This means quite a bit of boilerplate code, especially for modules with multiply revisionable entities.

Proposed resolution

Create a route provider for generating revision list, revision revert form, revision delete form based derived from link templates.

Remaining tasks

  • Decide if we want to improve this in core
  • Create a plan
  • Implement the plan

    • Direction/decisions

    Items needing discussion

    • ✅Whether to continue blocking this issue on #3043321: Use generic access API for node and media revision UI, an access checker will be added and immediately deprecated.
    • ❌Whether Node should use this in this issue.
    • ✅Whether we should generate local tasks, or if entities should add their own.
    • Revert terminology updated to be agnostic of target revision' time.
    • Should we adopt Version terminology (per patch)?

    Blockers

    Patch to date for this issue relies on patches in these.

    User interface changes

    New opt-in UI based on features already established by Node.

    API changes

    None

    Data model changes

    None.

    Release notes snippet

    ↧

    Can't filter user by status

    January 27, 2021, 10:37 am
    $
    0
    0

    Problem/Motivation

    I want for certain role to be able list all active users. I added permission for given role "View user information". Now it if call

    /jsonapi/user/user

    I get list of all users which is expected behaviour. But if I call

    /jsonapi/user/user?filter[status][value]=1

    I get error:

    {
    "errors": [
        {
            "detail": "The current user is not authorized to filter by the `status` field, given in the path `status`.",
            "links": {
                "info": {
                    "href": "http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.4"
                },
                "via": {
                    "href": "https://XXX/jsonapi/user/user?filter%5Bstatus%5D%5Bvalue%5D=1"
                }
            },
            "status": "403",
            "title": "Forbidden"
        }
    ],
    "jsonapi": {
        "meta": {
            "links": {
                "self": {
                    "href": "http://jsonapi.org/format/1.0/"
                }
            }
        },
        "version": "1.0"
    }
}

    For admin user it works so syntax should be ok. I did little research and i was able to get it work for given role only if I assigned permission "Administer users". It doest make sense to me. I can view all users (active and blocked) but I can't filter only active or blocked? And assinging permission "Administer users" seems to be too much.

    Steps to reproduce

    1. enable json api module
    2. add permission "View user information" to role that you want to test it
    3. in browser go to /jsonapi/user/user?filter[status][value]=1

    Proposed resolution

    Allow user status for user with permission "View user information" or if its on purpose for some reason we could add new permission just for user status?

    ↧
    ↧

    Fix 'Drupal.Commenting.ClassComment.Missing' coding standard

    January 12, 2020, 2:45 pm
    $
    0
    0

    Problem/Motivation

    This sniff relates to Drupal API documentation standards for classes and namespaces.

    Hello this fixes the Drupal.Commenting.ClassComment.Missing standard listed in this parent, #2571965: [meta] Fix coding standards in core.

    In the pull request two classes are skipped:
    - one is being fixed via the https://www.drupal.org/project/drupal/issues/3105880
    - and another one intentionally doesn't include the class doc block due to testing the empty plugin annotations (therefore the adjusted phpcs.xml.dist).

    Steps to reproduce

    Proposed resolution

    Remaining tasks

    Review
    Commit

    User interface changes

    API changes

    Data model changes

    Release notes snippet

    ↧

    When filter value is an array of values use IN as default instead of =

    July 23, 2021, 4:16 am
    $
    0
    0

    Problem/Motivation

    As mentioned in the parent issue. When a filter is requested without an operator and the value is an array of values the = operator is used. This could be IN since that is semanticly more correct and would make filtering a little more verbose :)

    ↧
    Search

    Assume IN operator, or return friendlier error, when provided multiple values without a specified operator

    June 20, 2019, 2:59 pm
    $
    0
    0

    Current behavior

    Ran into some unexpected behavior when trying to use filters with multiple values:

    filter[ids][condition][path]=id&filter[ids][condition][value][]=UUID1&filter[ids][condition][value][]=UUID2&page[offset]=0&page[limit]=50

    If you use these filter parameters JSON:API returns a 500 response telling you that the query failed.

    Talked with @gabesullice and seems like making the default operator IN when multiple values are provided makes the most sense:

    I think that if we detect multiple values we should assume `IN`

    Expected behavior

    JSON:API should assume the `IN` operator when provided multiple filter values.

    At the very least, that should be a 400 error, not a 500 for sure

    ↧

    Add exposed filters and sorts to field list report

    April 6, 2018, 2:13 pm
    $
    0
    0

    Problem/Motivation

    While it appears as though the Administer -> Reports -> Field list hasn't turned into a view yet (I'm assuming this is non-trivial given that there's no native support for creating a view of fields), we should still find a way to make it more usable, whether we do this through Views or not.

    For example, I'd like to be able to do the following:

    • Sort by field type.
    • Filter by field type.
    • Increase the number of items on each page.

    I found a contrib module that looks like it handles the filtering: Filter Field List

    Proposed resolution

    Creating a form with two filters by entity_type and field_type.

    Remaining tasks

    Write patch
    Code review
    A11Y review
    UX Review
    Commit

    User interface changes

    Added two select lists, Entity type and Field type on the admin/reports/fields page
    Screenshot of fields

    API changes

    None

    Data model changes

    None

    ↧
    ↧

    Olivero comment form should have title

    March 25, 2021, 6:11 am
    ↧

    Update dependencies for Drupal 9.3

    July 16, 2021, 8:22 am
    $
    0
    0

    Problem/Motivation

    PHP 8.1 support will require some updates to our dependencies: #3220021: [meta] Ensure compatibility of Drupal 9 with PHP 8.1 (as it evolves)

    Not all dependencies are fully updated yet, but at least Symfony, masterminds/html5 and mikey179/vfsstream have recent point releases that include PHP 8.1 compatibility fixes.

    Steps to reproduce

    Proposed resolution

    $ composer update --with=phpunit/phpunit:^8

    Remaining tasks

    User interface changes

    API changes

    Data model changes

    Release notes snippet

    ↧

    Provide a Layout Overview dialog that allows performing all actions in a text/form based method

    December 10, 2018, 1:35 pm
    $
    0
    0

    Problem/Motivation

    From @andrewmacpherson's original extensive issue summary which can be seen here

    We're in deeply experimental territory here - there isn't a well-established, reliable pattern we can just copy to make the current layout builder accessible. Essentially, we're making stuff up in a hurry, for a novel UI, with limited opportunity for design validation. There's no guarantee that users are going to understand it, or find it easy to use.

    Proposed resolution

    Provide a "Layout Overview"(better wording?) link at the top of the Layout Builder
    This link would open up an overview in the off-canvas dialog that would allow the user to perform all the operations they can in the current live preview version.
    Layout overview in off-canvas dialog

    All of the actions currently in the Layout Builder are performed in the off-canvas dialog either through selecting items in a list(adding blocks and sections) or interacting with a form. The only exception to this is dragging and dropping blocks but #2995689: Allow reordering blocks without a pointer device would provide a way to do this via a form.

    The overview in the off-canvas would allow all users to share most of the UI's for taking actions on the Layout but provide a more standard way to access those actions than the current live preview.

    After each action the users take via the overview they be would shown the overview again at the end of the action. This would allow a user to take multiple actions via the overview without having to open the overview for each action.

    Remaining tasks

    User interface changes

    A new layout overview in the off-canvas dialog

    API changes

    None

    Data model changes

    None

    Release notes snippet

    @todo

    ↧
    Viewing all 292913 articles
    Browse latest View live
    Search
    <script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>