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

Views should not condition joins on the langcode of fields that are not translatable

$
0
0

Problem/Motivation

When creating a node view with both translatable and non translatable fields, the view filter on language adds a join condition on the langcode of all fields (even those that have not been translated). This causes no results to be found in the languages that are other than the default language the non translated field were saved in.

For the same reason sorting does not work on untranslated fields. Things are sorted as expected in on language, but not in another.

Proposed resolution

Before applying the join to langcode on the fields, check whether the field is translatable.

Remaining tasks

Add the watchdog error mentioned in #193.
Open a followup issue to Improve the query. See #157-#158

User interface changes

None.

API changes

None, I guess.

Original report by @vitalie


Migration process plugin not working with multiple source IDs

$
0
0

Providing multiple source IDs to a migration process results in the field being skipped every time because the passed value is always NULL.

Manage display return 500 when we have image fields

$
0
0

Hi,

when we added an image field for a content type on Manage display tab it returns "HTTP ERROR 500". When we deleted image field from content type it works normally. There is no message on "Recent log messages" and server error logs. How we can solve this problem? It's just for image fields.

Best

Use form element of type date instead textfield when selecting a date in an exposed filter

$
0
0

Problem/Motivation

When adding a datetime exposed filter I cannot simply select a date - I have to manually enter a date which is very bad UX.

Proposed resolution

Use a form element with '#type' => 'datetime' so it's easy for users to select the date.

Remaining tasks

None.

User interface changes

Exposed date filters will have input[type=date], and will leverage HTML5 handling if supported by the browser, or fall back to the polyfill if it doesn't.

API changes

None.

Data model changes

None.

Categorize migrations according to their type

$
0
0

Problem/Motivation

Why is this necessary? In the process of migrating content, it is normal to run a migration in 3 steps ( and one sub-step).

  1. Build the configuration for a migration. (--configure-only)
  2. Migrate the structure & configuration from the old site i.e. the variables, blocks, vocabularies, node types, etc.
  3. Override and modify the configuration pulled in from the migration. For example, most sites don't modify the wording of the welcome emails for new users, just revert that config to the default text in D8. Same applies to anonymous and authenticated roles.
  4. Lastly, suck in all the data from nodes, taxonomy terms, blocks, etc.

In a normal flow, #1 is run once at the beginning of a project to build out lots of migrations. The second step is run and tweaked a few times until the structure is all in place, but then those migrations can (should?) be deleted or ignored and the resulting configuration stored in configuration. The last step (#3) cannot be run until right before you want to make a site go live.

With the current state of affairs, its is nearly impossible to separate out what is configuration vs what is content. This issue here will probably eventually turn into a meta. And we will probably have to take a close look at what content is getting migrated in a single migration as there seem to be several migrations that currently modge together both content and configuration in a single migration.

Proposed resolution

Supplement the migration group (e.g. migrate_drupal_7) created for the migrations produced by Drupal upgrade (drush migrate-upgrade) with two tags, one for configuration migrations and one for content migrations.

Remaining tasks

User interface changes

API changes

Data model changes

InvalidArgumentException: Invalid translation language specified.

$
0
0

Problem/Motivation

I get this error when adding a translation. The URL may than node/2/translations/add/de/en:

InvalidArgumentException: Invalid translation language (en) specified. in Drupal\Core\Entity\ContentEntityBase->addTranslation() (line 691 of core\lib\Drupal\Core\Entity\ContentEntityBase.php).

I have created an English translation of a German article. I also get Article English article 2 has been updated. For repro you need to uncheck Create new revision in the node and translation.

Steps to reproduce

  1. Install standard in English
  2. Log in as a user with "translate any entity" permission - user 1 will do
  3. Create an english article node
  4. Install content translation
  5. Add german
  6. Enable content translation for article nodes with the default settings
  7. Go to de/node/1/translations/add/en/de and add a translation
  8. Go back to de/node/1/translations/add/en/de

Proposed resolution

Remaining tasks

User interface changes

API changes

Convert \Drupal\views\Tests\Plugin\StyleOpmlTest and \Drupal\views\Tests\Plugin\DisplayFeedTest to PHPUnit tests

$
0
0

Follow up to #2863267: Convert web tests of views

Convert \Drupal\views\Tests\Plugin\StyleOpmlTest and \Drupal\views\Tests\Plugin\DisplayFeedTest to PHPUnit tests. Both these tests use a non-HTML page, so special steps need to be taken to account for that.

add a method to AccessResult forbiddenIfLacksPermission

$
0
0

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Access%21... isn't useful in a lot of situations.

For example, consider the use case that I want to limit access to an entity field to only users with a certain permission.

If I implement hook_entity_field_access() and return AccessResult::allowedIfHasPermission(), then that has no effect, as it returns a neutral if the user doesn't have the permission.

What's needed is the opposite of allowedIfHasPermission() - a method that denies access if the permission is absent.


ViewExecutable might break serialization of its own and other data

$
0
0

I'm not exactly sure what is going on here but I've finally managed to find a way to reproduce this error consistently.

Set up

  1. Create a content type with an image field
  2. Add an entity reference field that references "Other > Configuration > Block"
  3. Ensure you have a View on the site with a block display (e.g. "Who's Online") and that it is placed in a region

Steps

  1. Create a node and in the block entity reference field, choose your Views block (e.g. "Who's Online")
  2. Save the node - the views block should render fine
  3. Open the node for editing
  4. Upload an image in the image field
  5. The ajax should fail and you should get the error below on screen in your inspector console, failing that it might appear on node save.

Fatal error: Call to a member function getFieldStorageDefinition() on array in core/lib/Drupal/Core/Field/TypedData/FieldItemDataDefinition.php on line 66

Line 66 is return $this->fieldDefinition->getFieldStorageDefinition()->getPropertyDefinitions();.

From a bit of debugging, I can see that $this->fieldDefinition is indeed an array and contains the following: Array ( [class] => Array ( [0] => node-page-edit-form [1] => node-form ) [data-drupal-selector] => node-page-edit-form )

The above steps reproduces the error consistently for me. I've noted the following however:

  • There's no issue editing fields which do not rely on AJAX (e.g. title field)
  • You can reference regular blocks or custom block types and you won't get the error. It only happens with Views blocks afaict
  • I've used the image uploader as a simple way to trigger it, but any ajax operation on the page should trigger it.

Verify peer on HTTPS if cURL available (but be careful of built-in cert bundles in the codebase)

$
0
0

Problem/Motivation

Drupal does not currently verify that SSL certificates use a trusted root cert. This affects any requests initiated with drupal_http_request. It also affects OpenID discovery and HTTPS redirects during that discovery.

Proposed resolution

This issue includes solutions for Drupal 8 and the Drupal 7 backport.

For Drupal 8

Given we use Guzzle now, utilize http://guzzle.readthedocs.org/en/latest/http-client/client.html#configur... to nominate the system certificate file as the default instead of that shipped with Guzzle. Anyone wanting to use their own can implement ServiceModifierInterface and nominate an absolute file path.

For Drupal 7

1) Verify SSL certificates using curl_verify_ssl_peer. This only works when PHP is compiled with cURL support.

One drawback to this approach is that cURL is not always available in shared host environments. Commenters indicated that cURL is a relatively standard feature, and this should not be as much of a factor when D8 is released.

2) Include in Drupal a bundle of X.509 certificates of public Certificate Authorities (CA) borrowed from the cURL library.

greggles mentioned in comment 24 that this might require rapid security advisories in the case of a compromised cert. Also, including certs in Drupal core would logically add a configuration requirement where admins could add new certs.

Remaining tasks

Get Drupal 8 patch in.
Backport to Drupal 7 - Comment #25 includes a patch using curl_verify_ssl_peer, but it requires testing.

Possibly backport to D6.

API changes

This could affect developers who use drupal_http_request to issue HTTPS requests against servers that do not have proper SSL certs. For example, HTTPS connections would fail when issued to an internal dev server that used a self-signed cert.

Original report by Heine

Wojtha just asked on IRC if certificates are verified. They are not.

Demo patch in a few mins.

Create/Update/Delete (POST/PATCH/DELETE) ConfigEntity via REST

$
0
0

Problem/Motivation

As an overall issue based on #2292707: GET on entity/taxonomy_vocabulary/{id} is not working it is weird we cannot POST/PATCH/DELETE for ConfigEntities.

Before #1928868: Typed config incorrectly implements Typed Data interfaces it was impossible for config entities to provide validation on the config level, so it was not possible to guarantee that the given input is valid.

Proposed resolution

  • Allow config entities to opt into rest support by adding a rest_support annotation to entity types
  • Leverage config validation to ensure the POSTed/PATCHED entities are valid
  • Implement config validation for the config_test config entity type, to prove that the approach works.

Remaining tasks

  • Review
  • Address feedback
  • RTBC
  • Commit

User interface changes

API changes

Allow BTB to test an existing, already installed Drupal site instead of installing from scratch.

$
0
0

Problem/Motivation

When writing tests it would be helpful to use the test classes to run against an installation of Drupal created by means other than the test setup. When writing functional tests and integration tests for whole-site builds and not specific features isolated to specific modules, the approach to writing tests has typically been:

  1. Set up a functioning version of the website on CI by either importing a database from another environment (or reinstalling and importing config).
  2. Create a base test class which overrides setup to halt the installation of Drupal.
  3. Write tests which all work against the same, single environment setup on CI that closely reflects the production environment.

Alternatives to this are writing the site as an installation profile that can be used for each test or importing the websites configuration folder during every test run. The issue with these two approaches is how slow they are and missing out on creating a test environment that exactly represents production, beyond just the configuration and code.

Examples of things which impact a site during runtime are the sites content, all configuration created/available for modification on production and the database schema (a site having gone through every updb as opposed to a fresh module installation). Once an environment is replicated on CI, tests of this kind are impacted by these factors, making them useful for determining the real status of a site.

Proposed resolution

Add a property to BrowserTestBase which forgoes the installation of Drupal, sets the test class up to run against the parent site and cleans up entities created during the test.

Remaining tasks

  1. Seek approval for this feature.
  2. Ensure the entities are cleaned up automatically.
  3. Make sure approach is compatible with and possibly blocked by #2796105: Move similar methods in BrowserTestBase / WebTestBase to a trait; untangle installDrupal().

User interface changes

None.

API changes

Additional properly on BTB that controls the Drupal installation status.

Data model changes

None.

Short term fix: Make ContentTranslationController recognize 'add' and 'edit' form handlers.

$
0
0

Problem/Motivation

Currently ContentTranslationController assumes all content entity types have a 'default' form handler, which is in no way standardized or documented. A good example of where it breaks is #2833054: InvalidPluginDefinitionException: The "group" entity type did not specify a "default" form class..

Proposed resolution

Make ContentTranslationController behave like DefaultHtmlRouteProvider and check for an 'add' or 'edit' form handler
This would be a short term fix with no BC break until we get a full solution in #2006348: Remove default/fallback entity form operation

Remaining tasks

User interface changes

API changes

Data model changes

Add documentation to EntityViewMode destination plugin

$
0
0

Add API documentation.

See the documentation in the process plugins for format examples.

Make anonymous 4xx REST responses cacheable by PageCache (or any other reverse proxy) — and ensure every tested REST resource response's cacheability behaves as expected

$
0
0

Problem/Motivation

In Drupal\rest\RequestHandler::handle() we are returning a Response. This prevents cache tags from being added to the response and it also sets the response as non-cacheable.

This becomes a problem if you have an entity with many entity reference values, the application consuming the entity must go through the references to get the referenced data, if some of these items are inaccessible (or unpublished) then it will return a 403. Since that 403 is not cached, it will have to read this data from the database every single time the initial entity is requested (even when the initial one is cached).

Proposed resolution

When we are faced with a client error, we should return a CacheableResponse. This should add the 4xx-response cache tag as well as a proper Cache-Control header.

This change makes the REST responses behave just like the html responses.

Remaining tasks

  1. Write Patch
  2. Write Tests

User interface changes

None.

API changes

4xx Responses from the REST module will now be cacheable.

Data model changes

None.


Change Dynamic Page Cache's response policy from "deny admin routes" to "deny html admin routes"

$
0
0

Problem/Motivation

  • #2827797: ResourceResponse(Subscriber) + Dynamic Page Cache: making authenticated ResourceResponses significantly faster surfaced that there are REST routes (such as GET requests for Shortcut and MenuLinkContent entities) that are marked as administrative routes (_admin_route) by virtue of starting with an /admin URL path, and that this excludes those resources from benefiting from Dynamic Page Cache due to the dynamic_page_cache_deny_admin_routes response policy.
  • #2874938: Decide which, if any, non-HTML routes should be administrative is the issue for deciding what we mean by "administrative" for non-HTML routes, and potentially not marking REST routes as administrative.
  • Regardless of that issue, it might make sense to change dynamic_page_cache_deny_admin_routes to a policy that's just scoped to denying caching HTML admin routes, since the reasons for that policy might not apply to non-HTML routes. This issue is for discussing and implementing such a change.

Background

  • The Dynamic Page Cache module was developed in #2429617: Make D8 2x as fast: Dynamic Page Cache: context-dependent page caching (for *all* users!). For most of that issue's lifetime, it included a policy to deny caching of admin routes due to a concern that throughout core and contrib, there would exist admin routes for which cacheability metadata was lacking due to developer omission, and that therefore caching such routes would result in stale content being served, which in some cases could also be a security bug. This concern, among others, was discussed in #2556889: [policy, no patch] Decide if SmartCache is still in scope for 8.0 and whether remaining risks require additional mitigation, where the policy of denying caching of administrative routes was included as one of several risk mitigation strategies.
  • On the day that Dynamic Page Cache was committed to core, the PHPDoc explaining the policy was changed from:
    This policy rule denies caching of responses generated for admin routes, because the cacheability metadata of most admin route responses is lacking, which would lead to stale content being shown and the site being perceived as broken.

    to

    This policy rule denies caching of responses generated for admin routes, because admin routes have very low cache hit ratios due to low traffic and form submissions."

    which remains the PHPDoc in the Drupal\dynamic_page_cache\PageCache\ResponsePolicy\DenyAdminRoutes class today.

  • If the reason for the policy is what is currently stated in the PHPDoc, then that reason does not automatically apply to non-HTML routes. URLs that might have low hit ratios for HTML usage might have high hit ratios for REST usage. For example, GET requests of MenuLinkContent entities.
  • If the reason for the policy is what was originally stated in the PHPDoc prior to that patch's commit, then that might also not apply to non-HTML routes. Creating non-HTML routes is less commonplace than creating HTML routes, so it might be reasonable to expect developers who do so to bear the responsibility of providing cacheability metadata.

Proposed resolution

Change the default policy of dynamic_page_cache module to be scoped to only denying HTML admin routes. For BC, in order to make it easy for sites to use the old policy, one possible implementation might be:

  • Create a new policy, DenyHtmlAdminRoutes, to sit alongside the existing DenyAdminRoutes class.
  • Mark DenyAdminRoutes as @deprecated.
  • Remove (or comment out) dynamic_page_cache_deny_admin_routes from dynamic_page_cache.services.yml and add a dynamic_page_cache_deny_html_admin_routes instead.
  • Provide a change record of this change and include instructions of how a site owner can modify their services.yml file to add back the old policy.

Remaining tasks

Discuss.

User interface changes

None.

API changes

No API change, but there is a behavior change per the proposed resolution.

Data model changes

None.

Decide which, if any, non-HTML routes should be administrative

$
0
0

Problem/Motivation

  • In Drupal, we have a concept of "administrative route", expressed via the _admin_route route option.
  • Certain things happen for administrative routes, such as AdminPathConfigEntityConverter and LanguageNegotiationUserAdmin.
  • Caching is also affected, though see #2877528: Change Dynamic Page Cache's response policy from "deny admin routes" to "deny html admin routes" about possibly changing that.
  • AdminRouteSubscriber automatically marks routes with a path that starts with /admin as administrative.
  • As a result, some REST module routes get marked as administrative, such as GET requests to MenuLinkContent and Shortcut entities, though it's not at all clear why we'd want any of the administrative route behaviors happening for those requests.
  • Outside of core's REST module, who knows what use cases contrib has for non-HTML routes and whether it's clear what "administrative"
    means for those use cases.

Proposed resolution

  1. Option 1: Keep core's current behavior of marking /admin/* routes as administrative, regardless of format. If it's undesirable for the canonical URL of an entity to be administrative, then move that URL out of /admin. See,
    for example, #2873529: BlockContent, MenuLinkContent, and Shortcut define incorrect canonical links.
  2. Option 2: Change AdminRouteSubscriber to only mark /admin/* routes as administrative if they're HTML routes. For non-HTML routes, require explicit opt-in to _admin_route, not magic based on URL path. This would be a potential BC break for contrib that was relying on the existing magic.
  3. Option 3: Change REST module to mark all its routes as non-administrative by default. That's implemented in the patch in comment #2.
  4. Option 4: Change REST module to only mark entity resources as non-administrative. This could be accomplished via EntityResource::getBaseRoute().
  5. Option 5: Change REST module to only mark GET requests of entity resources as non-administrative. This could be accomplished via EntityResource::getBaseRoute() and its $method parameter.

Remaining tasks

  • Decide on which option makes the most sense.
  • Implement that option and create a change record to communicate the corresponding BC break.

User interface changes

None.

API changes

None. But depending on the option chosen, a behavior change that would affect some contrib.

Data model changes

None.

ThemeRegistryLoader::findTemplate() breaks Twig_Loader_Filesystem signature

$
0
0

ThemeRegistryLoader::findTemplate() breaks \Twig_Loader_Filesystem signature by NOT returning a strict FALSE in case of errors when throwing exceptions is disabled.

Looking in the \Twig_Loader_Chain, you can see this code:

    public function exists($name)
    {
        $name = (string) $name;

        if (isset($this->hasSourceCache[$name])) {
            return $this->hasSourceCache[$name];
        }

        foreach ($this->loaders as $loader) {
            if ($loader instanceof Twig_ExistsLoaderInterface) {
                if ($loader->exists($name)) {
                    return $this->hasSourceCache[$name] = true;
                }

                continue;
            }

            try {
                if ($loader instanceof Twig_SourceContextLoaderInterface) {
                    $loader->getSourceContext($name);
                } else {
                    $loader->getSource($name);
                }

                return $this->hasSourceCache[$name] = true;
            } catch (Twig_Error_Loader $e) {
            }
        }

        return $this->hasSourceCache[$name] = false;
    }

And in \Twig_Loader_Filesystem this code:

    public function exists($name)
    {
        $name = $this->normalizeName($name);

        if (isset($this->cache[$name])) {
            return true;
        }

        try {
            return false !== $this->findTemplate($name, false);
        } catch (Twig_Error_Loader $exception) {
            @trigger_error(sprintf('In %s::findTemplate(), you must accept a second argument that when set to "false" returns "false" instead of throwing an exception. Not supporting this argument is deprecated since version 1.27.', get_class($this)), E_USER_DEPRECATED);

            return false;
        }
    }

As you can see, it tests for a strict FALSE boolean, but the custom Drupal load does return NULL (no return statement) instead. This as a serious side effect: it creates a false positive for the exists() method return.

I guess that no-one ever saw that coming because in core, there are no other loaders, but in my use case I do have a custom loader, and because we have a false positive here, it will always try to render via the theme registry instead of my custom loader.

I end up having exceptions were I should not. I'm doing the patch ASAP. Please note that it's a bug for both 8.3.x and 8.2.x but I'm going to solve this in 8.3.x.

Add documentation to Config destination plugin

$
0
0

Add API documentation. Make sure that configuration parameters and working with translations are included. Add suitable examples too.

See the documentation in the process plugins for format examples.

Permissions: View any unpublished content not working

$
0
0

This issue was reported for the Workbench Moderation module. It also exists in Content Moderation, so I'm adding it here.

I have a role (manager) with permission to view any unpublished content. That role can also view the latest version, can create and edit any content type X.

Webmaster (administrator role) creates a content type X node. It's in the Draft (unpublished) state.
User A with role "manager" cannot access that node.
Webmaster publishes that node, User A then has access to it.
Webmaster creates a new draft version of that node (has published version and unpublished version).
User A can view and moderate the unpublished version.

User A creates a content type X node. As soon as User A saves it, user gets message: "The website encountered an unexpected error. Please try again later.".
Webmaster can see and access that node (unpublished), but User A cannot - even though User A created it.

Problem: users other than administrator cannot view unpublished content that does not have a published version when they have the View any unpublished content permission.

This renders workflow useless.

Here 's a link to the issue reported for Workbench Moderation: ISSUE

Viewing all 296448 articles
Browse latest View live


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