Quantcast
Viewing all 296448 articles
Browse latest View live

ExtensionDiscovery rewrite, according to SOLID principles

It was suggested in #2503927: Convert ExtensionDiscovery to a service to turn ExtensionDiscovery into a service. I think it is not really suitable as such, and we should write something new instead.

The ExtensionDiscovery component has a number of issues. It is mutable (->setProfileDirectories()), it is big, it explicitly calls out to the environment for global state data, and it statically caches mutable objects.

Some of the problems can be fixed. E.g. adding the additional key [$this->root] to the static cache, as in #2605654-48: Modify Drupal\Core\Extension\ExtensionDiscovery to allow for scanning multiple file systems, enabling vfsStream testing.

But beyond this, we probably need to leave some of the crappy behavior in place for existing components that are already depending on it. One of the flaws is the existence of a setProfileDirectories() method, which makes this object mutable and thus not suitable as a service.

If a depending component already needs to be modified (to use a service instead of calling a constructor), it can as well use a different tool that does the job more reliably.

More details in the first comment, since this will change over time.


Optimize UrlHelper::buildQuery() to use http_build_query()

Problem/Motivation

In the code for UrlHelper::buildQuery() is the comment:

   * @todo Remove this function once PHP 5.4 is required as we can use just
   *   http_build_query() directly.

Since we now require PHP 5.4, we should proceed with this.

Proposed resolution

For now replace the guts of the method with the built-in functional call.

Remaining tasks

make patch, see if any tests fail

User interface changes

N/A

API changes

N/A

Move contact module footer link to standard install profile

Problem/Motivation

Contact module adds a link to the site-wide contact form in the footer menu
It has no right to do so, and means you cannot disable it later without killing the footer menu.
It belongs in the standard profile (product feature, not framework feature).

Proposed resolution

Move it

Remaining tasks

User interface changes

API changes

Data model changes

Log messages should be XSS filtered on display

This issue has been reported privately to the security team but it was decided to handle this as public security improvement since no direct vulnerability is involved.

Problem/Motivation

Watchdog messages should be inserted sanitized into the database, but it is easy for developers to make the mistake of inserting user provided text as log message.

Proposed resolution

We should add an additional safe guard and do Admin XSS filtering when the log message is displayed in the user interface.

Remaining tasks

Write a patch against dblog.module

User interface changes

none.

API changes

none.

Label (Title) not set for Views block (exposed filters in Block)

Problem/Motivation

When using a views exposed form as block. The block does not allow you to provide a title.

Proposed resolution

Patch provided

Remaining tasks

None

User interface changes

None

API changes

None

Data model changes

None

Original Summary

I have created a simple Views page with several exposed filters with Views option: Exposed form in block: Yes.
The block is configured to "Display title" in block config settings.
When the block is configured to display in a region, the Label/title is not displaying.
I have dumped the block variables out with template_preprocess_block() and label key is empty ('label' => string(0) "").
The result is the same when the block is configured to override title.
Is this a bug or have I missed something?

Re-order the 'place/configure block' form so it's focused on the task at hand.

Currently, the place/configure block form is ordered with the most frequently-accessed task (region to place into) at the very *bottom* of the form. This is a bit silly. Instead, we should put it near the top, so it's immediately visible.

Before:

Image may be NSFW.
Clik here to view.

After

Image may be NSFW.
Clik here to view.

In theory, this is pretty easy to do, and already has buy-in as a solution in #2269881: [meta] Unifying condition UIs, so tagging as Novice.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Empty Twig {% trans %} tag causes fatal exception

Attempting to render empty Twig "trans" tags (i.e., {% trans %}{% endtrans %} causes a fatal exception like the following:

An exception has been thrown during the compilation of a template ("Attribute "data" does not exist for Node "Twig_Node".") in "{# inline_template_start #}{% trans %}{% endtrans %}".

This is because of a call to \Twig_Node::getAttribute() for a "data" attribute that doesn't exist in the case of an empty tag. The simple solution is to test for the attribute before requesting it. Patch to follow.

Uncaught PHP Exception when selecting too many tests to be tested from UI

Steps to reproduce:

  1. Enable testing module (simpletest)
  2. Go to the UI and select 30 tests to be tested
  3. Press "Run tests"

Expected output

The tests will be executed and I see the results

Actual output

Uncaught PHP exception:

Uncaught PHP Exception Drupal\Core\Database\DatabaseExceptionWrapper:"SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'test_class' at row 1: INSERT INTO {simpletest} (test_id, test_class, status, message, message_group, function, line, file) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7); Array
(
    [:db_insert_placeholder_0] => 1
    [:db_insert_placeholder_1] => Drupal\Tests\commerce\Unit\Resolver\ChainCountryResolverTest,Drupal\Tests\commerce\Unit\Resolver\ChainLocaleResolverTest,Drupal\Tests\commerce\Unit\Resolver\DefaultCountryResolverTest,Drupal\Tests\commerce\Unit\Resolver\DefaultLocaleResolverTest,Drupal\Tests\commerce_store\Unit\Resolver\ChainStoreResolverTest,Drupal\Tests\commerce_store\Unit\Resolver\DefaultStoreResolverTest
    [:db_insert_placeholder_2] => fail
    [:db_insert_placeholder_3] => PHPunit Test failed to complete
    [:db_insert_placeholder_4] => Other
    [:db_insert_placeholder_5] => Drupal\Tests\commerce\Unit\Resolver\ChainCountryResolverTest,Drupal\Tests\commerce\Unit\Resolver\ChainLocaleResolverTest,Drupal\Tests\commerce\Unit\Resolver\DefaultCountryResolverTest,Drupal\Tests\commerce\Unit\Resolver\DefaultLocaleResolverTest,Drupal\Tests\commerce_store\Unit\Resolver\ChainStoreResolverTest,Drupal\Tests\commerce_store\Unit\Resolver\DefaultStoreResolverTest
    [:db_insert_placeholder_6] => 0
    [:db_insert_placeholder_7] => .../sites/default/files/simpletest/phpunit-3.xml
)" at .../core/lib/Drupal/Core/Database/Connection.php line 676, referer: http://localhost/admin/config/development/testing

Twig addClass and big_pipe not compatible

Hello there
When using .addClass() twig method within template and enabled big_pipe it won't work for anonymous users. Admin user works fine.

/**
 * @file
 * Sidebar navigation template.
 *
 * Available variables:
 * - attributes: Attributes.
 * - title_suffix: Title suffix. To place contextual links.
 * - content: Block content.
 *
 * @ingroup themeable
 */
{% set panel_classes = ['panel', 'panel-default', 'panel-subnav'] %}<div{{ attributes.addClass(panel_classes) }}>
  {{ title_suffix }}
  {{ content }}</div>

Resulting into

<div>
  ...
  ...</div>

add an arrow for the book up

Update CKEditor library to 4.5.9

[pp-2] Support ConfigEntity via REST

Problem/Motivation

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

Some use cases are

  • Get Vocabulary name to display for the current language.
  • Get Menu items for the headless app.
  • Get site name (is not a ConfigEntity!)

Proposed resolution

As rest already has a view permission why not just return ConfigEntities for GET ops?

Some examples

curl --user admin:admin --request GET http://drupal.d8/entity/taxonomy_vocabulary/tags?_format=json

{"uuid":"091cf3b1-de66-4dd8-8403-3d6d63de5d43","langcode":"en","status":true,"dependencies":[],"name":"Tags","vid":"tags","description":"Use tags to group articles on similar topics into categories.","hierarchy":0,"weight":0}

curl --user admin:admin --request GET http://drupal.d8/entity/menu/main?_format=json

Remaining tasks

  1. The anonymous call should not result in error. Is that related to #1916302: Serve REST errors as application/api-problem+json OR application/vnd.error+json ?


    curl --user "anonymous:" --request GET "http://drupal.d8/entity/taxonomy_vocabulary/tags?_format=json"
    
    {"error":""}

User interface changes

API changes

Contextual filters in view preview UI are not retained on preview navigation

coming from #2048309: Views UI Preview - navigation is broken, see comment #1 point 3 .

if a contextual filter is specified in the preview textbox, this input gets lost when navigating to a different page on the preview.

Steps to reproduce:

  1. Devel create 50 nodes of type 'article' and 'basic page'
  2. Clone the 'frontpage' view
  3. Change display format to e.g. table, selecting 'title' and 'type' fields as columns in the table
  4. Add a contextual filter to the cloned view, for the 'type' field
  5. Type 'page' in the textbox ifor the contextual filter preview
  6. Click 'Update preview'
  7. You get a table of only 'basic page' nodes
  8. Click any page link in the pager

Expected result:
A second page of 'basic page' nodes

Actual result:
A mix of 'basic page' and 'article' nodes, and the contextual filter textbox is void.

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue categoryBug because it is a regression in functionality from previous major versions or stable releases (Drupal 7.x)
Issue priorityMajor because has significant repercussions but does not render the whole system unusable

Add setting to disable logging of searches (7.x)

There is no way to set the watchdog messages ON/OFF for searched content, and which may lead to unnecessary database consumption.

Incorrect domain from url and session generator behind reverse proxy

When placing a Drupal 8 site behind a reverse proxy then the URL and session generator ignore the X-Forwarded-Host request header.

Url generator
Absolute URLs are being generated based upon the Host header instead of the X-Forwarded-Host header even when the settings.php is configured to allow reverse proxies. Invoking Drupal::request()->getHost() results in the correct host. The problem is caused by the url generator service being initialized before the ReverseProxySubscriber has a chance to assign trusted reverse proxies.

Session generator
Retrieving session cookie parameters from session_get_cookie_params() results in the domain matching the Host header instead of X-Forwarded-Host.

Proposed fix
This solution moves the trusted proxy logic from ReverseProxySubscriber to drupal_handle_request()

// Create a request object from the HttpFoundation.
$request = Request::createFromGlobals();
// Get the current settings.
$settings = \Drupal\Component\Utility\Settings::getSingleton();
// Check whether the reverse proxy settings should be used.
if ($settings->get('reverse_proxy', 0)) {
  // Allow the request to use the reverse proxy headers.
  $reverse_proxy_header = $settings->get('reverse_proxy_header', 'HTTP_X_FORWARDED_FOR');
  $request::setTrustedHeaderName($request::HEADER_CLIENT_IP, $reverse_proxy_header);
  $reverse_proxy_addresses = $settings->get('reverse_proxy_addresses', array());
  $request::setTrustedProxies($reverse_proxy_addresses);
  // Set the session cookie domain to the correct host.
  ini_set('session.cookie_domain', ".{$request->getHost()}");
}
// Attach the request to the dependency container.
\Drupal::getContainer()->set('request', $request);

Migrate content type language settings from Drupal 6 & 7

Problem/Motivation

In order to be able to identify a given migration as multilingual, we need to migrate the content type translation settings for the different content types.

Proposed resolution

Content type translation setting variables:

  • language_content_type_$type (one for each content type). Has 4 possible states:
    • No value: Means no translatable.
    • 0: Means no translatable.
    • 1: Means has language.
    • 2: Means has language, and it is translatable.
  • i18n_newnode_current_$type (one for each content type). A checkbox that indicates if the current language is the default for new content.
  • i18n_required_node_$type (one for each content type). A checkbox that makes language required (neutral not allowed).
  • i18n_lock_node_$type (one for each content type). A checkbox that makes the language locked, so it cannot be changed on edit.
  • i18n_node_$type (one for each content type). Has 4 possible states:
    • No value: not applicable, no translatable.
    • 1: All enabled languages allowed.
    • 2: All defined languages allowed.
    • 3: All defined languages allowed, but not displayed in links.
  • language_content_type_negotiation ?
  • language_content_type_default ?

Target: language.settings.yml

entities:
  node:
    article:
      language:
        default_configuration:
          langcode: current_interface
          language_show: true

Original report by Ryan Weal

Content type translation settings (D6/D7 core content translation and entity_translation contrib -> D8 content type config). This will bring what language settings are allowed for content authors of a particular content type. It will determine what the translation method was (content translation == 1 node per language, entity_translation = 1 und node with translatable fields). Config here specifies if it is possible to set langauge_none/undefined/language neutral/UND or if setting a language is mandatory.

file_unmanaged_save_data() doesn't clean up its temp files

In file_unmanaged_save_data() we create a temporary file, then move it into place. However, if the move fails, we end up with stale temp files. These are owned www-data:www-data and have mode 0600 by default, which can cause problems with backup scripts (i.e., Aegir) and such that won't be able to read them.

It's a pretty simple matter to check the return value of file_unmanaged_move(), and delete the temp file if the move failed. This function is identical in D7 and D8, but I'll post patches shortly for both.

key_value table is only used by a core service but it depends on system install

Problem/Motivation

We create the key_value table on the installation of the system module.
Let's make that lazy like for example the cache system.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Show which machine-readable must be unique.

Currently when I'm submitting some form, I've got this message:

The machine-readable name is already in use. It must be unique.

which is meaningless for me as a developer and it happens in edge cases on invalid form submission.

It would be great that the message would show which machine-name is failing.

Find the patch in attachment with proposed change.

Check the screenshots before applying the patch and after.

Mailing list page not found

Viewing all 296448 articles
Browse latest View live


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