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

\Drupal\Core\Render\Renderer::doRender() could be lazier about calling Element::children()

$
0
0

I noticed this as part of the patch I rolled at #2005970: In renderable arrays, #type should provide a #theme suggestion, similar to how drupal_prepare_form() works.

@Cottser suggested that I could spin it off into its own issue and get it profiled and possibly committed independently.

Basically drupal_render() does this:

// Get the children of the element, sorted by weight.
  $children = element_children($elements, TRUE);

  // Initialize this element's #children, unless a #pre_render callback already
  // preset #children.
  if (!isset($elements['#children'])) {
    $elements['#children'] = '';
  }
  // Call the element's #theme function if it is set. Then any children of the
  // element have to be rendered there. If the internal #render_children
  // property is set, do not call the #theme function to prevent infinite
  // recursion.
  if (isset($elements['#theme']) && !isset($elements['#render_children'])) {
    $elements['#children'] = theme($elements['#theme'], $elements);
  }
  // If #theme was not set and the element has children, render them now.
  // This is the same process as drupal_render_children() but is inlined
  // for speed.
  if ($elements['#children'] === '') {
    foreach ($children as $key) {
      $elements['#children'] .= drupal_render($elements[$key]);
    }
  }

And doesn't use $children anywhere else. Calling element_children() like this is a waste of CPU for #theme renderable arrays.


drupal_check_profile() does not invoke the profile's hook_requirements()

$
0
0

Problem/Motivation

Currently, installation profiles cannot implement hook_requirements(). Well, technically, they can, but it's not invoked during an install - it is only invoked after an install during updates or visiting the status report. This can be problematic for distributions, which may want to specify requirements that transcend the scope of any one module or feature of the distribution.

Proposed resolution

drupal_check_profile(), which verifies the requirements of all modules listed by an install profile, should also verify the requirements of the profile itself.

Remaining tasks

User interface changes

None.

API changes

Installation profiles support hook_requirements().

Data model changes

None.

Deprecate simpletest within DrupalKernel (DRUPAL_TEST_IN_CHILD_SITE)

$
0
0

Problem/Motivation

Bet you didn't know DrupalKernel has Simpletest in it.

DrupalKernel::bootEnvironment() says this:

    // Indicate that code is operating in a test child site.
    if (!defined('DRUPAL_TEST_IN_CHILD_SITE')) {
      if ($test_prefix = drupal_valid_test_ua()) {
        $test_db = new TestDatabase($test_prefix);
        // Only code that interfaces directly with tests should rely on this
        // constant; e.g., the error/exception handler conditionally adds further
        // error information into HTTP response headers that are consumed by
        // Simpletest's internal browser.
        define('DRUPAL_TEST_IN_CHILD_SITE', TRUE);

        // Web tests are to be conducted with runtime assertions active.
        assert_options(ASSERT_ACTIVE, TRUE);
        // Now synchronize PHP 5 and 7's handling of assertions as much as
        // possible.
        Handle::register();

        // Log fatal errors to the test site directory.
        ini_set('log_errors', 1);
        ini_set('error_log', $app_root . '/' . $test_db->getTestSitePath() . '/error.log');

        // Ensure that a rewritten settings.php is used if opcache is on.
        ini_set('opcache.validate_timestamps', 'on');
        ini_set('opcache.revalidate_freq', 0);
      }
      else {
        // Ensure that no other code defines this.
        define('DRUPAL_TEST_IN_CHILD_SITE', FALSE);
      }
    }

This code fragment exists so that we can test WebTestBase.

When we eventually deprecate TestBase/WebTestBase, we won't be able to deprecate DrupalKernel::bootEnvironment().

Proposed resolution

Factor this code out of bootEnvironment() and into a separate static method which can be deprecated.

Deprecate the new method.

Somehow formally deprecate usages of DRUPAL_TEST_IN_CHILD_SITE which exists solely to isolate TestBase and WebTestBase from themselves during testing.

Remaining tasks

Figure out how to deprecate drupal_valid_test_ua() and friends.

User interface changes

API changes

Data model changes

[PP-1] Convert taxonomy terms to be revisionable

$
0
0

Problem/Motivation

As decided in #2745619: [policy, no patch] Which core entities get revisions?, taxonomy terms should be converted to be revisionable and publishable.

Proposed resolution

Do it.

Remaining tasks

Decide how we want to deal with term hierarchies, see #2705389-48: Selected content entities should extend EditorialContentEntityBase or RevisionableContentEntityBase.

User interface changes

In the vocabulary overview page, the drag-and-drop interaction will be disabled if the vocabulary has at least one term with a pending revision:

API changes

Nope.

Data model changes

Taxonomy terms are now revisionable and publishable.

Image field broken ?

$
0
0

Is the field image broken ???

Step 1:
- Fresh drupal 8.6.1 installation (default presets, language: german)
- Fresh database

Step 2:
Create new content type
Create new field -> image
Go to display settings -> press config icon beside field_image

Solved ?
Deleted the old image field.
Created a new image field and error disappeared.
I cannot retrace the issue.

Nothing happens - warning in console:
AjaxError (ajax.js:98:32)
HTTP:200
path: .../display?ajax_form=1
Status:OK
Answer:GIF89a

Step 3:
Try to upload picture.
File gets uploaded on server.
Html src "/sites/default/files/2018-10/image.jpg" seems to be ok

Display of the image doesn't work.
domain.com/sites/default/files/2018-10/image.jpg gets 1x1px sized.

Addition:
Guess: Caching or image processing problem
Image get not rendered directly.
Opened other browser with the image url.
First 1x1px white dot - after reload -> image appears.
Closed all browsers.
Cleared cache of site and browsers.
Some pictures are displayed, others are not. The behavior is very arbitrary.

Link error "The internal path component is invalid"

$
0
0

I have 500 error "The internal path component is invalid. Its path component must have a leading slash" with field widget type "Link".
This error generates from \Drupal\Core\Url::fromInternalUri

It happens from \Drupal\link\Plugin\Field\FieldWidget\LinkWidget::formElement
in code
$item->getUrl()->access() (core/modules/link/src/Plugin/Field/FieldWidget/LinkWidget.php:175)

For avoidance of this error we have next element validator where check input values
\Drupal\link\Plugin\Field\FieldWidget\LinkWidget::validateUriElement

So we can't catch this error on common entity save operation.
But we can catch it with any additional ajax buttons, which skip validation with #limit_validation_errors

So for catching you can:
1) Add Link field with Link widget to entity.
2) Add some fields with Ajax interface buttons to entity. Let it be File field.
3) On entity edit page put "foo" value to Link field.
4) Select file to File field.

You will get next Ajax error
↵An AJAX HTTP error occurred.↵HTTP Result Code: 500↵Debugging information follows.↵Path: /fr/node/6/edit?element_parents=field_test/widget/0&destination=/admin/content&ajax_form=1↵StatusText: 500 Service unavailable (with message)↵ResponseText: The website encountered an unexpected error. Please try again later.InvalidArgumentException: The internal path component 'test' is invalid. Its path component must have a leading slash, e.g. internal:/foo.

It appears on all browsers.

In my example "foo" value is incorrect for Link field. We can avoid this error by putting only correct values. But customer can be confused. He doesn't know what values are correct, and he doesn't know why all his AJAX buttons don't work. So we should avoid 500 error with ajax buttons.

I have investigated this issue and found, that we need to add additional check in \Drupal\link\Plugin\Field\FieldWidget\LinkWidget::formElement
I have prepaired patch and I will apply it in comment.

Document #pattern property for email, password, tel, textfield, and url form elements

$
0
0

This #pattern property was added in #1174766: Support the #pattern FAPI property for native HTML5 pattern attribute and there's a change record here https://www.drupal.org/node/1953036. However, there's no way to really discover the existence of this property without reading the code.

The following form elements all need to have documentation for the "#pattern" property added:

  • \Drupal\Core\Render\Element\Textfield
  • \Drupal\Core\Render\Element\Email
  • \Drupal\Core\Render\Element\Tel
  • \Drupal\Core\Render\Element\Password
  • \Drupal\Core\Render\Element\Url

The current standard is to document element specific properties in the @docblock for the plugin that implements the element in question. This allows those properties to be discoverable via https://api.drupal.org/api/drupal/elements.

All of the above listed elements can use the #pattern property, but none of them document it. This property is a little bit interesting in that there is some related code in \Drupal\Core\Render\Element\FormElement::processPattern, and \Drupal\Core\Render\Element\FormElement::validatePattern, however that code isn't automatically invoked. An element needs to add the ::processPattern method to it's list of #process callbacks. See \Drupal\Core\Render\Element\Textfield::getInfo.

Since this isn't a generic property that can be used on any element that extends FormElement, I'm personally leaning towards documenting this for each individual element that can use it. But, we could alternatively add it to the FormElement docblock with a note about the fact that it can only be used by textfield, tel, email, password, and url elements by default. Thoughts?

For anyone working on this you can see examples of the #pattern property in use in \Drupal\form_test\Form\FormTestPatternForm

i18n Variable to config: site offline message [d7]

$
0
0

Problem/Motivation

i18n site offline message is not migrated.

This is blocking
#2970849: i18n Variable to config: user settings and user.mail
#2970847: i18n Variable to config: system site settings [d7]

Proposed resolution

Migrate i18n variable, site offline message to config.

This is the first of the i18n variable migrations for Drupal 7 and includes a new source plugin because in D7 the variables are stored in the variable_store table, not variable, where the data may or may not be serialized. There is still much in common with the Drupal 6 VariableTranslation source plugin so a base class is added.

Remaining tasks

Write migration.
Write tests, includes updating the drupal7 test fixture.

User interface changes

N/A

API changes

N/A

Data model changes

N/A


WI: Phase A: Use the revision API in more places

$
0
0

Note: This is issue is part of #2721129: Workflow Initiative and is only meant for planning and governance sign-offs. Work will happen in child issues of this plan.

The idea of this phase it to implement and use our great revision API for all content entities in core, except users. This will provide a necessary foundation for any moderation, workflow and staging capability. No new features or functionality is being added to the Entity API in this phase.

The issues below needs to happen somewhat sequentially:

  1. #2490136: Enable revisions by default
  2. #2707255: All content entities should inherit baseFieldDefinitions
  3. #2705433: Node should implement RevisionLogInterface
  4. #2716081: BlockContent should have revision_user and revision_created fields and implement RevisionLogInterface
  5. #2721313: Upgrade path between revisionable / non-revisionable entities
  6. #2745619: [policy, no patch] Which core entities get revisions?
  7. #2705389: Selected content entities should extend EditorialContentEntityBase or RevisionableContentEntityBase

These additional issues should happen by the end of phase A:

Must

Should

Could

These issues will not be blockers, but could be good issues for sprints or contributors wishing to assist with the initiative.

Sign-offs needed

Product manager

A product manager needs to sign-off on this plan because the revisioning user experience is not as polished as the non-revisioned user experience, so the planned work significantly affects the out-of-the-box experience of the product.

Framework manager

A framework manager needs to sign-off on this plan as the above phases introduces a small, but very significant, API addition (parent revisions).

Release manager

A release manager needs to sign off because the scope and impact of the work are significant for core, and because existing issues with revisions may impact the stability and technical debt of the developmental minor version.

Sub-system maintainers

The sub-system maintainers for the Entity API needs to sign-off on this plan as it significantly impacts the Entity API.

Sign-offs given

  • Product manager - Pending completion of the issues listed above
  • Framework manager - Pending specific implementation in phase A; not yet given for phase B
  • Release manager - Pending completion of the issues listed above
  • Sub-system maintainers - pending

Orphan term hierarchy records can cause taxonomy_update_8502 to enter an infinite loop

$
0
0

Problem/Motivation

While updating from 8.5.6 to 8.6.0/8.6.1, taxonomy_update_8502 entered an infinite loop and was never completed. On aborting the update and re-running, an integrity constraint violation error was thrown as the first term had already been migrated.

[notice] Update started: taxonomy_update_8502
[error]  SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1-0-0-nl' for key 'PRIMARY': INSERT INTO {taxonomy_term__parent}

The infinite loop occurs when the taxonomy_term_hierarchy table refers to records that no longer exist in taxonomy_term_data for some reason.

Proposed resolution

Ensure that orphan records are excluded from the total count, thus allowing the update function to correctly determine that all taxonomy_term_hierarchy valid records were migrated.

User interface changes

None

API changes

None

Data model changes

None

Original report

While updating from 8.5.6 to 8.6.0 the following error was raised during the database update:

[notice] Update started: taxonomy_update_8502
[error]  SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1-0-0-nl' for key 'PRIMARY': INSERT INTO {taxonomy_term__parent}

The website where the update was run is fairly simple: only 2 custom taxonomies, each with about 5 terms, no hierarchy.
The codebase was updated with composer, then db updates were run with drush, but the same issue happens with update.php.

Add hook_post_config_import_NAME after config import

$
0
0

Problem/Motivation

Drupal core has a hook_update_N() mechanism with which developers can fix the database. But often we also want to abuse it to deploy other changes. This can lead to the situation that we would like to import the configuration before running the update hooks. But this is a very bad idea and will not be possible in the future.

See #2762235: Ensure that ConfigImport is taking place without outstanding updates and #2628144: Ensure that ConfigImport is taking place against the same code base.

The use case for this is for example adding a new field and dynamically populating it during a particular deployment.

Proposed resolution

Add a hook_post_config_import_NAME called after a config import so that developers can easily write one-off hooks for deployments and still always run the update hooks before the config import.

Remaining tasks

User interface changes

none

API changes

new hooks.

Data model changes

none

Frontpage with query parameter results in "Page not found"

$
0
0

Problem/Motivation

How to reproduce:
* Go to admin/config/system/site-information
* Into "Default front page" enter a path with querystring, e.g. "/admin/people?status=2"
* Submit
* Go to Frontpage

Expected: See the configured page (here users filtered by "blocked")

Result: "Page not found"

Proposed resolution

Fix this.

Remaining tasks

Codeit.

User interface changes

None.

API changes

None.

Data model changes

None.

LanguageNegotiationUserAdmin requires 'access administration pages' which is too strict

$
0
0

Problem/Motivation

Not quite sure if this is a feature, bug or task :)

The preferred admin language feature currently requires users to have the 'access administration pages' permission. We'd like to use this also for regular editors that are basically just managing content.

Proposed resolution

Use a different permission, either a new one (possibly additional to the existing check for BC) or maybe use "view the administration theme" for this instead.

Remaining tasks

User interface changes

API changes

Data model changes

Use READ COMMITTED for MySQL transactions

$
0
0

I've run into an issue as a part of #937284: DEADLOCK errors on MergeQuery INSERT due to InnoDB gap locking when condition in SELECT ... FOR UPDATE results in 0 rows. If for some reason the db_merge() query fails, the current transaction is rolled back. This makes sense during most parts of a node save call, but makes no sense if a cache set fails. It also means that node save has a reference to a node that appears to be saved in code, but doesn't actually exist anymore in the database.

Since we ignore any exceptions that occur during the cache set, we may as well keep any transactions in progress alive as well. The attached patch starts a transaction right before we merge into the cache table.

Compiling the container from outside the application root fails

$
0
0

Problem/Motivation

When the container is being compiled during a command-line operation and the current working directory happens to be not the Drupal root, the compilation fatals with the following error:

Symfony\Component\DependencyInjection\Exception\InvalidArgumentException : The service file "core/core.services.yml" is not valid.

  1. /srv/www/htdocs/drupal/core/8-7/core/lib/Drupal/Core/DependencyInjection/YamlFileLoader.php:329
  2. /srv/www/htdocs/drupal/core/8-7/core/lib/Drupal/Core/DependencyInjection/YamlFileLoader.php:63
  3. /srv/www/htdocs/drupal/core/8-7/core/lib/Drupal/Core/DrupalKernel.php:1289
  4. /srv/www/htdocs/drupal/core/8-7/core/lib/Drupal/Core/DrupalKernel.php:893
  5. /srv/www/htdocs/drupal/core/8-7/core/lib/Drupal/Core/DrupalKernel.php:468
  6. /srv/www/htdocs/drupal/core/8-7/core/tests/Drupal/KernelTests/Core/DrupalKernel/DrupalKernelTest.php:53
  7. /srv/www/htdocs/drupal/core/8-7/core/tests/Drupal/KernelTests/Core/DrupalKernel/DrupalKernelTest.php:147

This is because the service YAML file paths are not absolute and, thus, assumed to be relative to the current working directory.

Proposed resolution

Prepend the application root when building the list of service YAML file paths to make them absolute.


Cannot load entity by uuid after rename

$
0
0

Problem/Motivation

If a config entity is being renamed through \Drupal\Core\Config\ConfigFactoryInterface::rename() then it becomes impossible to load the entity by its uuid through \Drupal\Core\Entity\EntityRepositoryInterface::loadEntityByUuid().

Proposed resolution

When config is saved or deleted we listen to the corresponding events in \Drupal\Core\Config\Entity\Query\QueryFactory and update the config key store for fast lookups so that a config entity could be loaded by its lookup keys.

In order to cover renaming config entities through the config factory we should additionally listen to config renaming events and update the config key store for fast lookups accordingly. Additionally we should remove delete the old values from the config key store for fast lookups.

Remaining tasks

User interface changes

API changes

Data model changes

Views doesn't parse twig when there are no tokens to replace

[META] Release Drupal 9 in 2020

$
0
0

Problem/Motivation

Drupal 8 uses Symfony 3 which goes end of life in November 2021. Therefore Drupal 8 will also need to go end of life then as we don't intend to support a fork of Symfony 3 for our purposes. There are other dependencies affected.

For people to have a reasonable upgrade time from Drupal 8 to Drupal 9, we plan to release Drupal 9 no later than a year before Drupal 8 goes end of life, that is in 2020.

Read more about the dates at https://www.drupal.org/core/release-cycle-overview and even more context at https://dri.es/drupal-7-8-and-9

Proposed resolution

Identify all blockers to Drupal 9's release. For now, most blockers pertain to branching Drupal 9 itself and starting to work on it. See #2608062: [policy, no patch] Pre-requisites for branching Drupal 9 from Drupal 8.

Most changes needed should be doable in Drupal 8 and the swapping of dependencies as well as removal of depreciated items are planned to be done directly in Drupal 9's initial release.

Remaining tasks

First blocked on branching Drupal 9, so see #2608062: [policy, no patch] Pre-requisites for branching Drupal 9 from Drupal 8. Second identify further tasks that need to be done.

User interface changes

TBD.

API changes

TBD.

Data model changes

TBD.

Contextual Filters with Has Taxonomy Term ID no longer working

$
0
0

Steps to recreate;

  1. Created a new view
  2. Filtered to 1 content type
  3. Add a contextual filter "Has Taxonomy Term ID"
  4. Added validation criteria by restricting to specific vocabularies

At this point it appeared to be fine, upon reopening the contextual settings modal we discover none of the settings have been saved and the UI now appears broken.

We now have around 50 fieldsets for Access operation checks, none of which will retain the values when saving the view.

This was first discovered on a new build running 8.6. To confirm the issue we've installed 2 fresh copies of 8.6 and the problem persists.

The modal throws the following error in the JS console;

drupal.js?v=8.6.1:13 Uncaught TypeError: Cannot read property 'checked' of undefined
    at states.Dependent.compare (states.js?v=8.6.1:101)
    at states.Dependent.checkConstraints (states.js?v=8.6.1:165)
    at states.js?v=8.6.1:148
    at Array.every (<anonymous>)
    at states.Dependent.verifyConstraints (states.js?v=8.6.1:147)
    at states.Dependent.checkConstraints (states.js?v=8.6.1:168)
    at states.js?v=8.6.1:148
    at Array.every (<anonymous>)
    at states.Dependent.verifyConstraints (states.js?v=8.6.1:147)
    at states.Dependent.checkConstraints (states.js?v=8.6.1:168)

The attached images shown the initial error on screen along with a GIF demoing "Has Taxonomy Term ID" modal being scrolled after this issue appears.

Error 404 when upload image in profile installation

$
0
0

I am installing a custom distribution, I have created a form:

my_distribution.install:

/**
 * Implements hook_install_tasks().
 */
function my_distribution_install_tasks(&$install_state) {
  $tasks = [
    "extra_configs" => [
      "display_name" => t("Extra configurations"),
      "type" => "form",
      "function" => "Drupal\my_distribution\Form\ExtraConfigsForm",
    ]
  ];

  return $tasks;
}

Drupal\my_distribution\Form\ExtraConfigsForm.php:

// more code ...

/**
 * {@inheritdoc}
 */
public function buildForm(array $form, FormStateInterface $form_state) {
    $form['#title'] = $this->t('Extra configurations');

    $form['logo'] = [
        '#type' => 'managed_file',
        '#title' => t('Load logo'),
        '#upload_location' => 'public://logo/',
        '#upload_validators' => [
          'file_validate_extensions' => [
            'png jpg jpeg',
          ],
        ],
        '#required' => TRUE,
      ];

    $form['actions'] = ['#type' => 'actions'];
    $form['actions']['submit'] = [
      '#type' => 'submit',
      '#value' => $this->t('Save and continue'),
      '#button_type' => 'primary',
    ];

    return $form;
}

// more code ...

Everything works fine but, when I get to that form and load an image I get an error in the javascript console, and i can't continue:

AjaxError: 
An AJAX HTTP error occurred.
HTTP Result Code: 404
Debugging information follows.
Path: /core/install.php/%3Cnone%3E?element_parents=logo&langcode=es&profile=my_distribution&ajax_form=1
StatusText: Not Found
ResponseText: {"message":"No route found for \u0022POST \/core\/install.php\/%3Cnone%3E\u0022 (from \u0022http:\/\/my-distribution.local\/core\/install.php?langcode=es\u0026profile=my_distribution\u0022)"}

In watchdog i only see:

ID  Date          Type      Severity  Message                                                                                                                                             
79  08/Oct 13:15  page not  warning   /core/install.php/%3Cnone%3E?element_parents=logo&langcode=es&profile=my_distribution&ajax_form=1&_wrapper_format=drupal_ajax 

Drupal version: 8.5.7

What could be the issue?

Viewing all 298718 articles
Browse latest View live


Latest Images

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