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

add an entity Links handler, to provide menu links/tasks/actions for entity types

June 1, 2018, 8:17 am
$
0
0

Menu plugins are an area where entity types that wish to provide a UI have a lot of boilerplate code. Three YML files have to be provided:

- MODULE.links.menu.yml
- MODULE.links.task.yml
- MODULE.links.action.yml

These contain repetitive boilerplate code, where furthermore it's very easy to make a mistake and match up the route names incorrectly.

Proposed solution:

- add a new handler type for entities, 'link_provider'
- add two new handler classes to the Entity component:
-- DefaultContentEntityLinkProvider
-- DefaultConfigEntityLinkProvider
- add plugin derivers for menu, task, and action plugins. These each loop over all entity types, and invoke the link_provider handler on any entity type that has one.

Core's default link provider handler classes would expect to find the route names created by core's route_provider classes. Entity types that customize their route provider to change or add routes would need to use their own link_provider handler (or keep using hardcoded link plugins of course).

↧
Search

Create a generic way to decorate Entity classes

November 19, 2017, 2:14 pm
$
0
0

Problem/Motivation

The Decorator pattern can be used to add additional functionality to a class at runtime.

It is currently used by the Views UI to add functionality to a View entity that is only relevant for use by the UI.

A large majority of the code is pass-through implementations of methods to satisfy the interface.

Due to EntityInterface being very large, this boilerplate makes the decorator very large.

Proposed resolution

Introduce a generic EntityDecorator to satisfy EntityInterface, allowing the actual needs of the class to be separate from the majority of the boilerplate.

This will also be used by the Layout Initiative.

Remaining tasks

User interface changes

API changes

Data model changes

↧
↧

Improve Composer update workflow in UPDATE.txt

September 17, 2018, 12:07 pm
$
0
0

Problem/Motivation

#2867757: Improve instructions for updating composer.json and /vendor gets the docs out the door so people don't break their sites.

This issue discusses some finer points, such as whether or not to add --no-dev.

See #2867757-41: Improve instructions for updating composer.json and /vendor:

+++ b/core/UPDATE.txt
@@ -64,15 +64,51 @@ following the instructions in the INTRODUCTION section at the top of this file:
+   Note, if you want to only update drupal/core the following command will
+   probably work:
+
+     /PATH/TO/composer update drupal/core symfony/* --with-all-dependencies

Are we sure that symfony/* is needed here? #36 explains the initial rationale for that, but are we sure those problems weren't a consequence of https://github.com/composer/composer/issues/4795, which is now fixed with --with-all-dependencies as per https://github.com/composer/composer/issues/6661?

and #2867757-42: Improve instructions for updating composer.json and /vendor:

+++ b/core/UPDATE.txt
@@ -64,15 +64,51 @@ following the instructions in the INTRODUCTION section at the top of this file:
+1. On a typical Unix/Linux command line, run the following command from the root
+   directory (replace /PATH/TO/composer with the appropriate location for your
+   system):
+
+     /PATH/TO/composer update

Maybe say --no-dev, or add a comment that it's a good idea to add --no-dev to production for security reasons.

Proposed resolution

Remaining tasks

- Hash out a list of "finer points" to be in scope for the issue.
- Come up with good answers to the points.
- Patch UPDATE.txt
- Review / churn / RTBC
- Commit

User interface changes

API changes

Data model changes

↧

Follow-up for #2752961: automatically deleting compiled Twig templates across multiple webheads

June 14, 2018, 9:27 am
$
0
0

Problem/Motivation

#2752961: No reliable method exists for clearing the Twig cache solved a big problem. See the CR at https://www.drupal.org/node/2908461.

The remaining problem is now the deletion of stale (unused, irrelevant) compiled Twig templates on multi-webhead setups where each web server has its own compiled Twig template cache (because most shared file systems are slow).

The change record (https://www.drupal.org/node/2908461) says:

Note: the new approach invalidates files but doesn't delete files across multiple webheads. If you are running Drupal in a multi webhead environment, you might want to delete stale files from the storage manually. To read more about a potential solution read comments #102–#123 at #2752961-102: No reliable method exists for clearing the Twig cache, which contains a couple of suggestions for potential strategies.
In other words: newly deployed Twig templates will be picked up as expected across all webheads (as long as \Drupal::service('twig')->invalidate(); is called after code deployment). But if each webhead is doing its own (local) caching, then stale compiled Twig templates will remain there. So over time, this could accumulate to a significant size.

(Emphasis added.)

Proposed resolution

@greg.1.anderson wrote at #2752961-121: No reliable method exists for clearing the Twig cache:

If I am not mistaken, then the purpose of #112 is to implement the solution proposed in #7. In terms of converting a single-head solution into a double-head solution, what hosting providers need is:

1. The ability to put the twig cache files in a completely different directory each time they are cleared.
- When our scavenger deletes stale cache files, it can just delete entire directories at a time.
2. The ability to know which directory the current cache files are stored in.
- When scavenging stale cache files, we want to skip the directory that is active.
- We currently do this by forcing the directory calculation used in 1 so that we do not need to query Drupal.
- We could also potentially do this simply by examining the creation date of the cache folder, and presume that the newest is the active one.
3. The ability to stop Drupal from deleting the files in the twig cache
- If we have a scavenger, then we don't need to spend time during the web request to delete large directories.

Remaining tasks

TBD

User interface changes

None.

API changes

TBD

Data model changes

TBD

↧

Send notifications to an external systems when modifying content!

November 8, 2018, 5:40 am
$
0
0

Hi,

I'm trying to let my Drupal site send notification of new created/modified specific content types to an external system API.

Is there anyway I can do this?

Best regards,

↧
↧

Add composer-based install instructions to the Drupal project page

November 7, 2018, 2:14 pm
$
0
0

Can we add the instructions for using composer to install Drupal8 to the Drupal project page?

More info can be found here.

I don't believe there are composer install instructions for Drupal 7.

↧

The Layout Builder block listing should be filterable

September 11, 2018, 11:42 am
$
0
0

Problem/Motivation

Layout Builder's block listing is not filterable, which makes it hard to quickly find the block you're looking for.

Proposed resolution

We should add a filter for the block listing similar to the core one at /admin/structure/block.

Remaining tasks

Write a patch.

User interface changes

A filter will be added to the Layout Builder block listing.

API changes

None.

Data model changes

None.

↧

[PHP 7.3] Fully support PHP 7.3 in Drupal 7

November 8, 2018, 6:00 am
↧
Search

Notice: Undefined index: value in Drupal\views\Plugin\views\filter\NumericFilter->acceptExposedInput()

November 8, 2016, 11:12 am
$
0
0

To reproduce:

Make a site that has Content Type A with an entity reference field to Content Type B
Make some content that has this reference as a sample
Make a view that shows content of Type A
Add an exposed grouped filter on Content Type A's ER field to Content Type B
Fill in a few examples of Content type B as options for the grouped filter. Use the Type B nid as the value.
Save and look at the view on a page. You should see the following:

"Notice: Undefined index: value in Drupal\views\Plugin\views\filter\NumericFilter->acceptExposedInput()"

↧
↧

user_schema() uses the wrong structure for foreign_keys

November 3, 2018, 8:36 pm
$
0
0

Problem/Motivation

The definition of the {users_data} table in user_schema() includes this for the foreign_keys key:

'foreign keys' => [
  'uid' => ['users' => 'uid'],
]

This is not consistent with the structure of that key as described in the Schema API page in the API docs.

Proposed resolution

Change those lines to be consistent with the API docs. Several other modules define foreign_keys correctly. The {node_access} table, defined in node_schema() is a good model.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

↧

Merge TypedDataManager and TypedConfigManager

November 2, 2018, 2:05 pm
↧

Convert query('SELECT COUNT(*) FROM ...') to select('...')->countQuery() in tests

August 24, 2018, 7:29 am
$
0
0

Problem/Motivation

There are a lot of calls to db_query('SELECT COUNT(*) ...');.

Find for example just those in test code with find . -type f -name '*Test.php' -exec grep -Ei "QUERY.*COUNT.*\(\*\)" {} \+.

There's a better and more db abstract way to achieve the same with $injected_database->select(...)->countQuery()

Proposed resolution

Convert those to $injected_database->select(...)->countQuery() in test code. Start here with DatabaseTestBase kernel tests.

Remaining tasks

User interface changes

API changes

Data model changes

↧

Calling StatusMessages::renderMessages() with a $type returns a faulty render array

September 26, 2018, 7:25 am
$
0
0

Problem/Motivation

If you specify a $type when calling StatusMessages::renderMessages(), the messages in #message_list aren't grouped by message type as expected during rendering.

Proposed resolution

Wrap the result of deleteByType in the type.

Remaining tasks

Write tests

User interface changes

TBD?

API changes

N/A

Data model changes

N/A

↧
↧

Muted attribute not working for Video file

May 4, 2018, 1:08 pm
$
0
0

Fresh Drupal 8.5.x install. I've added a Media Video and I try to mute it in its display mode.
Unfortunately, the video is rendered without the attribute therefore, it's not muted.

How to reproduce
- Install Drupal 8.6.x
- Enable the Media module
- Create a Media Video type
- Edit the Display Mode and select the "Muted" attribute to YES.
- Create a new video and see it on front end.

Expected result
- On front, the video is muted.

Actual result
- On front, the video is NOT muted - muted attribute is not printed in the HTML markup.

I've attached a patch.
This is a quick fix.

↧

Fatal error on config form with translation enabled when config is missing

November 21, 2017, 7:37 am
$
0
0

Steps to reproduce:
* Create a new config form that modifies an custom configuration
* Create a route for the config form
* Make sure the custom_config doesn't exist in the active configuration
* Create a *.config_translation.yml for the custom configuration
* Go to the route for the config form

A fatal error occurs:
TypeError: Argument 2 passed to Drupal\Core\Config\TypedConfigManager::createFromNameAndData() must be of the type array, boolean given, called in /core/lib/Drupal/Core/Config/TypedConfigManager.php on line 78 in Drupal\Core\Config\TypedConfigManager->createFromNameAndData() (line 391 of core/lib/Drupal/Core/Config/TypedConfigManager.php).

This happens with Drupal 8.4.2 because the system tries to read the configuration, but since the data doesn't exist it returns FALSE, hence the error.

↧
Search

Allow section storage plugins to control their own requirements and ordering, especially for delegation during rendering

May 29, 2018, 12:52 pm
$
0
0

Problem/Motivation

While working on the Layout Library module, I discovered that Layout Builder is basically incompatible with any layout storage strategy except for its two built-in ones, which are "defaults" (storing a layout in an entity view display) and "overrides" (storing a layout in a field on a content entity).

The problem comes down to the getRuntimeSections() method of \Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplay:


  protected function getRuntimeSections(FieldableEntityInterface $entity) {
    if ($this->isOverridable() && !$entity->get('layout_builder__layout')->isEmpty()) {
      return $entity->get('layout_builder__layout')->getSections();
    }

    return $this->getSections();
  }

This code is rooting around in internal implementation details of both the defaults and overrides storage plugins. It is completely unaware of any other layout storage strategy -- which, as I understand it, was the entire point of making layout storage pluggable in the first place -- yet it pretty much controls how layout-able entities are rendered. This code kinda renders the entire idea of "section storage plugins" moot.

Proposed resolution

First, section storage plugins must declare their necessary contexts. No longer will a section list be determined externally and passed in.

Introduce SectionStorageManagerInterface::loadFromContext(array $contexts)
Passing in an array context, the manager will select the first section storage plugin whose context requirements are satisfied and which passes access checking.

Section storage plugins can now also specify their weight, which affects the order in which they are checked by ::loadFromContext().

Finally, LayoutBuilderEntityViewDisplay::getRuntimeSections() is adjusted to use this new API, removing all hardcoded runtime knowledge of $entity->get('layout_builder__layout')

Remaining tasks

Reviewin' and committin'.

User interface changes

N/A

API changes

Only within @internal classes.

Data model changes

N/A

↧

Hook entity_field_storage_info is broken

October 9, 2015, 1:54 am
$
0
0

If you attach fields to ContentEntityTypes using the hook 'entity_field_storage_info' SqlContentEntityStorage will ignore the changes and throw an error if one tries to save an entity with the new field.

What are the steps required to reproduce the bug?

  1. Create a custom ContentEntityTyoe.
  2. Attach at least on storage definition to this ContentEntityTyoe using the hook 'entity_field_storage_info'.
  3. Create required database fields accordingly to the attached storage definition.
  4. Create an instance of that entity and try to save it.

What behavior were you expecting?

The entity should be stored to the database.

What happened instead?

An exception is thrown by SqlContentEntityStorage saying "Table mapping contains invalid field @FIELD". It refers to the field created via 'entity_field_storage_info'.

Cause

SqlContentEntityStorage uses the method getFieldStorageDefinitions to fetch the field storage definitions from the entity type. For unknown reasons it fetches the data from EntityManager::getBaseFieldDefinitions wich does not include changes made by the hook 'entity_field_storage_info' instead of EntityManager::getFieldStorageDefinitions.

Workaround

Till this on is fixed in core one may create a custom subclass of SqlContentEntityStorage overwriting the getFieldStorageDefinitions method and attach at as storage handler to their entities.

↧
↧

Upgrade EmailValidator to 2.x

June 24, 2016, 8:21 pm
$
0
0

Problem/Motivation

Version 2 of the EmailValidator is out.
https://github.com/egulias/EmailValidator/releases

Version 2 has pluggable lexers fulfilling interface EmailLexer, which would unblock some contrib #2749873-5: "email.validator" core service cannot be easily replaced.

Proposed resolution

Upgrade it.

Remaining tasks

User interface changes

None

API changes

This will not break any usages in contrib. Existing injections of the service will still work because it extends from the same class.

If the service is overridden - which feels a little unlikely - then the service will now have to implement EmailValidatorInterface. Before there was no interface so this is a big improvement for swapping out this service.

Data model changes

None

↧

Add an input filter to display embedded Drupal entities

January 27, 2018, 6:59 am
$
0
0

Problem/Motivation

This issue is split off from #2801307: [META] Support WYSIWYG embedding of entities other than files.

The first part of WYSIWYG integration for Media is the ability to display an entity by embedding it in the textual content of another entity -- i.e., a media item displayed inline in the body of a node. To do this, we will need an input filter which can render entities referenced by some sort of embed code, similar to the way the contrib Entity Embed module works.

Proposed resolution

Create a generic text filter which can render an entity from an embed code.

Remaining tasks

Import the code from #2801307: [META] Support WYSIWYG embedding of entities other than files, iterate on it, review it until it is nice, and commit it.

User interface changes

None.

API changes

A new text filter will be added, which will support machine-readable Drupal embed codes.

Data model changes

No

Testing steps

  • Install latest 8.7.x
  • Apply the patch
  • Go to Administration => Configuration => Content authoring => Text formats and editors
  • Select a text editor (e.g. basic HTML)
  • Check "Display embedded entities" under embed filters
  • Add <drupal-entity data-entity-type data-entity-uuid data-entity-embed-display data-entity-embed-display-settings> in "Limit allowed HTML tags and correct faulty HTML" if the filter enabled and "save configuration"
  • Go to node add page (node/add/page)
  • Select body field's filter as "basic html"
  • Select "source" from the CKEditor
  • Add
    <drupal-entity data-entity-type="node" data-entity-uuid="[UUID]"  data-entity-embed-display="teaser"></drupal-entity>

    and save

↧

Route normalizer: Global Redirect in core

December 27, 2015, 5:49 am
$
0
0

Problem/Motivation

Originally, some work was started in #2430335: Browser language detection is not cache aware to resolve a caching issue. A language redirect was introduced, but the implementation was more general than just adding the language prefix. The target redirect URL was constructed from current route. This caused some test fails (especially, in case if this redirect is enabled always even if the language module is not installed, see 2430335#89). And this issue was created.

Current implementation

There is a new route_normalizer_request_subscriber service that perform redirects like the Global Redirect module. On a GET request, it construct a URL from the current route and the current route/query parameters, and redirects to that URL if it does not match the incoming URL. This causes:
- language redirect, for example from "/" to "/en", this resolves #2430335: Browser language detection is not cache aware
- path alias redirect, for example from "node/1" to "content/my-node"
- front page redirect, for example from "/node" to "/"
There can be more cases, but they are unknown at the moment.

Also, the patch contains some fixes for bugs caught during development, and some documentation changes.

Arguments for this feature:
- globalredirect has a lot of installations, people might need this feature in the core
- better SEO
- less cache entries
- it allows to catch bugs at early development stage (check the fixes provided in the patch)

Remaining tasks

- fix remaining test fails
+ write tests
- try to use CacheableRedirectResponse

User interface changes

The default Drupal installation will behave like the one having the Global Redirect module enabled.

API changes

The "disable_route_normalizer" request attribute can be set to disable the route normalization:

$request->attributes->set('disable_route_normalizer', TRUE);

Data model changes

none

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