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

Improve code documentation for \Drupal\update\ProjectSecurityData

$
0
0

Problem/Motivation

#2991207: [PP-3] Drupal core should inform the user of the security coverage for the site's installed minor version including final 8.x LTS releases added a new ProjectSecurityData class, with a method called getAdditionalSecurityCoveredMinors(). The function is somewhat confusing, and the doc block says:

/**
  * Gets the number of additional minor security covered releases.
  *
  * @param string $security_covered_version
  *   The version until which the existing version receives security coverage.
  *
  * @return int|null
  *   The number of additional minor releases that receive security coverage,
  *   or NULL if this cannot be determined.
  */

This is rather opaque, but we agreed to commit #2991207 (to 8.9.x) as is because it is a critical issue.

The docs for getSecurityCoverageUntilVersion() could also benefit from some examples to help clarify.

Finally, there are a few formatting bugs from @todo comments that were committed with the parent issue, and a few additional @todo comments that could be added to track future work.

Proposed resolution

Flesh out these comments in more detail to explain what's really going on, inlcuding specific examples to clarify the behavior.

Remaining tasks

  1. Commit parent issue.
  2. Update docs.
  3. Review.
  4. RTBC.
  5. Commit.

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A


BaseFieldOverride fails to take into account ContentEntityInterface::bundleFieldDefinitions() when invoking onFieldDefinitionUpdate()

$
0
0

Postponed on #2283977: Create a new ConfigEntity type for storing bundle-specific customizations of base fields, which is introducing the BaseFieldOverride class described in this issue.

Problem/Motivation

  • When a new 'base_field_override' config entity is created, BaseFieldOverride::preSave() calls the target entity type's storage handler's onFieldDefinitionUpdate() method, passing it the base field definition as the "previous" definition. And similarly, when the override config entity is deleted, BaseFieldOverride::postDelete() calls onFieldDefinitionUpdate, passing it the base field definition as the "new" definition.
  • However, if it happens that a base_field_override config entity is being added to or deleted from a site that also implements an override via ContentEntityInterface::bundleFieldDefinitions(), then the above behavior is incorrect, since the previous definition prior to base_field_override insertion and the new definition after base_field_override deletion is the one returned by ContentEntityInterface::bundleFieldDefinitions(), rather than the base definition.
  • The above might be an extreme edge case, because using ContentEntityInterface::bundleFieldDefinitions() rather than config to override base field definition is specifically intended for when you need you content entity type completely decoupled from config, in which case there shouldn't be code adding and removing base_field_override config entities for it.
  • Also, it's not really clear what FieldableEntityStorageDefinitionInterface::onFieldDefinitionUpdate() is even for. The only implementation of it in HEAD is a completely empty function, even after #1498720: [meta] Make the entity storage system handle changes in the entity and field schema definitions. Perhaps we should consider removing it? Do storage handlers need to be notified of non-storage-related changes to field definitions?

Proposed resolution

Discuss the above and figure out what to do.

Remaining tasks

User interface changes

API changes

Properly deprecate config.storage.staging service

$
0
0

Problem/Motivation

In #2487588: Move CMI import/export directory "staging" to "sync", as it is confused with staging environments the config.storage.staging service was deprecated and replaced with config.storage.sync, but some contrib still refers to the old service name.

Proposed resolution

Fully deprecate the config.storage.staging service. The final removal will have to wait until Drupal 10.

Remaining tasks

Patch, test, commit.

User interface changes

None

API changes

Using the config.storage.staging service will report a deprecation warning.

Data model changes

None

Release notes snippet

Defer running of hook_modules_installed() during updates

$
0
0

Problem/Motivation

#3098718: system_update_8804() fails if any path alias is created before it runs shows a continuing weakness in the update system.

hook_update_N() is for schema changes.

hook_post_update_NAME() is for content changes.

However module installation can be both of these things - the new module provides a schema, but it might also create content, or other modules might react to hook_modules_installed(), and that code isn't written to be run during updates.

Proposed resolution

Considering altering module installation during updates, so that it runs after all hook_update_N() have been run.

This would involve collecting which modules have been installed during the update process, then running hook_modules_installed() with a list at the end.

Remaining tasks

Decide if this would actually be an improvement, or potentially introduce yet more problems.

User interface changes

API changes

Data model changes

Release notes snippet

do something with the exception caught in DateTimeComputed::getValue()

$
0
0

DateTimeComputed::getValue() has this code:

    catch (\Exception $e) {
      // @todo Handle this.
    }

This swallows the exception thrown if the computed field property's value can't be derived.

For instance, if you have a date or date range field that you've given bad data to, and then try to get the computed value, you just get NULL, with no explanation why.

[policy, no patch] Update minimum supported Apache version to >= 2.4.7

$
0
0

Problem/Motivation

Over in #2854817: Duplicate X-Content-Type-Options headers both with the value nosniff, we are trying to fix the X-Content-Type-Options header from being duplicated. There are currently 2 approaches, one is rather hacky (unset + set), the other is more elegant (set the header only if empty). The second option relies on a directive that was added in Apache 2.4.7. Drupal currently does not specify a minimum version other than "2.x" on the requirements page.

Other than that, Apache 2.4.6 and below are ancient, unsupported, and those versions contain a number of known vulnerabilities. The 2.2.x branch was End-of-Lifed in January 2018.

Proposed resolution

Update the D8 (and D7) requirements to require at least Apache 2.4.7.

Remaining tasks

- Discuss if changing the requirement is acceptable;
- Update the documentation/requirements

User interface changes

None

API changes

None

Data model changes

None

Deleting an entity with revisions and file/image field does not release file usage of non-default revisions, causing files to linger

$
0
0

Problem/Motivation

Images/files uploaded to a file/image fields on entities with multiple revisions are never deleted, even when the entity is deleted. Because the file usage counts for the revisions is never released.

Steps to reproduce:

  1. create an article node with an image A uploaded to its image field
  2. verify that the uploaded file A has its status column in the file_managed table set to 1,
    and it has 1 usage in the file_usage table
  3. edit the node, check the "Create new revision" checkbox, remove the original image A and upload a new image B, save
  4. verify that the uploaded file B has its status column in the file_managed table set to 1,
    and it has 1 usage in the file_usage table. Verify that the rows for file A are unchanged in both tables.
  5. delete the article
  6. verify that the uploaded file B has its status column in the file_managed table set to 0, and it has no row anymore in the file_usage table
    • Expected result: file A has its status column in the file_managed table set to 0, and it has no row anymore in the file_usage table
    • Actual result: file A has its status column in the file_managed table still set to 1, and it still has n1 usage in the file_usage table
  7. run cron 6 hours later (this is the default value of the temporary_maximum_age setting in system.file)
  8. verify that uploaded file B is now removed (because usage = 0)
    • expected result: the uploaded file A is still present (because usage > 0)
    • actual result: the uploaded file A is absent (because usage = 0)
  9. Proposed resolution

    TBD, see #126 for an summary of comments #1–#125.

    Remaining tasks

    TBD

    User interface changes

    None.

    API changes

    TBD

    Data model changes

    TBD

Node bundle labels are shown in English after cache clear in the Dutch UI

$
0
0

Clearing cache via the Dutch UI resets translations on the content type view filter to default language (English).

Note that only the bundle lables are in English, the published state and other filters are translated.

As a workaround we need to clear cache in the default language (English).

This seems to be a regression of https://www.drupal.org/project/drupal/issues/2650434


Off canvas filling up localStorage's quota, causing errors

$
0
0

Problem/Motivation

In #2952390: Off-canvas styles override CKEditor's reset and theme, a patch was committed that uses localStorage to cache previously processed CSS files. The localStorage key is based on the full path to the CSS file, including the query param, i.e. Drupal.off-canvas.css.http://drupal.localhost/core/assets/vendor/ckeditor/skins/moono-lisa/editor.css?t=pv9p89http://drupal.localhost/core/assets/vendor/ckeditor/skins/moono-lisa/dialog.css?t=pv9p89. If a user visits a site enough times without clearing their browser's localStorage, their browser's localStorage limit (on mine it's 5MB) will have been met, which throws an error like:


Failed to set the [...] property on 'Storage': Setting the value of [...] exceeded the quota.

Proposed resolution

Expire older items from the localStorage cache, or stop using localStorage for this use case. The CSS file for CKEditor could be quite large so putting it all in localStorage doesn't seem efficient.

Remaining tasks

Determine a path forward and write a patch.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Remove duplicate test cases provider by dataProvider methods and prevent new ones.

$
0
0

Problem/Motivation

While working on #2990511: Add comprehensive test coverage for update status for security releases I realized how easy it is to provide duplicate test cases in a large @dataProvider method. Especially ones that use loops to create test cases.

This is problem because

  1. It wastes test resources
  2. More importantly the developer may think they providing more test coverage and for more logic paths then they actually are.

There are a few existing cases in core currently such as \Drupal\Tests\system\Unit\SystemRequirementsTest::providerTestPhpVersionWithPdoDisallowMultipleStatements
which simply has a hard-code array that has duplicate values:

$data = [];
    $data[] = ['5.4.2', FALSE];
    $data[] = ['5.4.21', FALSE];
    $data[] = ['5.5.9', FALSE];
    $data[] = ['5.5.20', FALSE];
    $data[] = ['5.5.21', TRUE]; // DUPLICATE
    $data[] = ['5.5.30', TRUE];
    $data[] = ['5.6.2', FALSE];
    $data[] = ['5.6.5', TRUE];
    $data[] = ['5.5.21', TRUE]; // DUPLICATE
    return $data;

There are other cases which will be harder to fix such as \Drupal\Tests\Core\EventSubscriber\ActiveLinkResponseFilterTest::providerTestSetLinkActiveClass()
which has complex logic to create the test cases(assuming my logic to find duplicates is correct).

Proposed resolution

  1. Override \PHPUnit\Framework\TestCase::assertPreConditions in \Drupal\Tests\UnitTestCase and ensure that the data set has not already be used with the current test method.

    There may be a better ways to test this but this is what I found.

  2. Remove current test duplicate cases in core.

You really can't do 1) without first doing 2).
Unless we had a way to not enforce it on know existing cases like I think we do with deprecation.

It would be great to get 1) to avoid new cases and ensure we are actually testing the cases we think we are.

To discuss

  1. Are there any situations where you would want duplicate test cases?
  2. What is the absolute most efficient solution? As the solution now runs before ever test case the most efficient code is very important

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

add the data set name to the HTML output filename

$
0
0

If you run a test method that has a data provider, then it's hard to distinguish where one test stops and another starts in the HTML output files.

The filenames look like this:

- browser_output/Drupal_Tests_mymodule_Functional_MyTest-331-68325304.html
- browser_output/Drupal_Tests_mymodule_Functional_MyTest-332-35704829.html

The only thing that marks these as being a different test is the long number at the end, and it's hard to make that out. Furthermore, if you have a lot of data sets, you can't tell which data set each one belong to.

Simple fix is to add the data set name to the filename.

Progress throbber position is incorrect

$
0
0

Problem/Motivation
Progress throbber position and styling are incorrect while viewing in table display as compared with other displays.

Steps to replicate
Example:
1. Go to admin/structure/block and click on place block to check the throbber effect.
2. After that click on the place block button from place block modal popup form and check the throbber effect.

See the below screenshots
progress throbber
progress throbber

ViewsEntitySchemaSubscriber does not update views base table when making an entity type translatable

$
0
0

Problem/Motivation

I'm currently in the process of making an entity type translatable through an update. That entity type has views. I noticed that the view does a very nice job of updating the table of all the field, sort, relationship, ... handlers but it doesn't update the base table, so the result is a completely broken view.

Proposed resolution

Similar to baes table rename, update the base_table in the view.

Remaining tasks

Pretty sure that this won't work for revision views and the logic there in general might not work, as it would need to use different table mappings. I think that could be a separate issue.

User interface changes

API changes

Data model changes

Migrate D6 and D7 node revision translations to D8

$
0
0

Follow-up to #2225775: Migrate Drupal 6 core node translation to Drupal 8

Problem/Motivation

In D8, a node revision has data for all languages. In D6 and D7, each node revision has data for just one language. This means currently D6 -> D8 and D7 -> D8 migrations yield a revision history where each node revision has only one language present, even if previous revisions had translations. This is strange and likely to confuse users.

Priority is given to the D7 migration because the D6 one might be effected by the term node migrations.

This is for migrating core translation revisions, migrating revisions for entity translation is now being done in #3076447: Migrate D7 entity translation revision translations to D8. It is intended that this issue is completed first and then the approach used here is also used for entity translations.

The following notes use the term 'master' which was the original term what is now the 'complete' node migration.

Meeting notes

Things to consider, taken from notes of meeting with alexpott, Gábor Hojtsy, heddn, mikelutz and quiteone

  1. Migration dependencies
    • Possible: easy to do
    • BC concerns: none
    • BC what about contrib? Commerce / metatag
      • Possible incompatible
  2. How do we figure out you need the new complex master migration?
    • Possible: moderate to do
    • BC concerns: none
    • Don’t effect expose new d*_node_master unless explicitly enabled to existing sites
    • This handles incremental, no UI option available to enable
    • For new installs, give an option to upgraders to enable disable the new d*_node_master migration and use the old method.
  3. What about migration lookups on dn_node etc.
    • Possible: easy to do
    • BC concerns: none
  4. What about incremental migrations that have already begun
    • Not allowed. You can only use the new approach on a site that has not run migrations. So we need some of flag where existing installs use the old migrations.
  5. Contrib/Custom
  6. Does it make sense to use d*_node_master instead of d*_node migrations?

Proposed resolution

The current focus is to get the D7 version working and then move those changes to D6.

Using the existing method where the final revision is migrated first doesn't work instead the revisions need to be migrated in order. The first proof of concept patch to show this is in #121, thanks to mikelutz. This new approach is called the Complete node migration and the migrations and files use that name.

"Removing it [the classic node migrations] will break the whole ecosystem. Deprecating it means that it’s not used anymore which in and of itself will break the eco system, and for what benefit? To remove it in Drupal 10, a year after D7 is EOL? At that point we are looking at deprecating the entire D7 upgrade path anyway (Probably for removal in 11, not 10) We really don’t want to break the migration ecosystem right now at this critical time when we are trying to get everyone off of D7 in the next 18-20 months". by mikelutz in #migration on Drupal Slack). See #3109819: [PP-2] Deprecate classic node migration plugin in Drupal 9 for removal in Drupal 10 for discussion of when deprecation of classic node migrations would happen.

Run Complete or classic node migrations
However, the Complete approach doesn't integrate with the current migrations, now being called Classic, that is the one either runs the existing node migrations or the new complete one, not both. Choosing between the two methods is done at run time by checking the node migration map tables in MigrationConfigurationTrait() and migrate_drupal_migration_plugins_alter(). In the trait the classic method is selected if any of the classic node migrate_map tables has data (using processedCount) and in the plugins_alter it is selected if any classic node migrate_map exists and there are no complete node migrate_maps.

The selection of node migration method also allows tests to decide which method to use. The test does this by adding either 'node_migrate_classic' or 'node_migrate_complete' to $modules.

Altered migrations
There are several migrations that use migration_lookup on the node migration. The processes and dependencies for these are altered when the complete node migration is being run. The changes include new processes to convert the 3 destination IDs returned by complete node to the correct destination ID expected when using the classic migration.
The migrations altered are: d6_term_node, d6_term_node_revision, d6_term_node_translation, d6_comment, d6_url_alias,d7_comment, d7_url_alias, statistics_node_counter, node_translation_menu_links.

Incremental migrations
For the core UI, if map tables for the classic mode migrations exist and at least one has a row then the classic migrations will run and not the complete node migrations. This is determined at run time. Therefor, existing incremental migration should continue to function.

From the original IS
D6 and D7 node revisions do not directly indicate which other translated node revisions they are associated with. But we can attempt to guess this, based on the order of revisions.

Remaining tasks

Fix tests, add comments
Review

For Reviewers

  • All level of code reviews welcome.
  • There are BC issues raised in meeting notes, above

For Testers

  1. Use the lastest patch patch in this issue.
  2. There are instructions in the Issue summary of the META issue #2208401: [META] Stabilise Migrate Drupal Multilingual module

From #55

For developers

  1. Make this work with a multilingual source and a non multilingual source
  2. Discuss and document implications for drush, especially drush migrate-upgrade --all
  3. Make sure the d6 and d7 tests includes testing a fields on each revision
  4. Handle the case where the vid of the first revision is higher the vid of a later revision. This is true for both d6 and d7.
  5. Make sure that the use of migration_tag 'translation' is documented. It is used in
    • d6_node_translation.yml
    • d7_node_entity_translation.yml
    • d7_node_translation.yml
    • d7_node_revision_translation.yml
    • d7_user_entity_translation.yml
    • d7_taxonomy_term_entity_translation.yml/li>
    • d7_comment_entity_translation.yml
    • d6_node_revision_translation.yml
  6. Make sure that the source plugin 'translation' property is documented
  7. Make sure that the destination plugin 'translations' property is documented

Re-schedule removal of deprecated JavaScript code to Drupal 10

$
0
0

Problem/Motivation

Late in Drupal 8.8.x cycle, we provided tools for deprecating JavaScript code. Unfortunately, we didn't manage to properly deprecate any of the JavaScript code so that they could be removed before Drupal 9.0.0.

Proposed resolution

Update documentation on deprecated JavaScript code to make it clear that the removals will happen before Drupal 10.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet


Plugin Lazy loading can cause usort warning

$
0
0

Problem/Motivation

Sporadically we get the following warning:
Warning: uasort(): Array was modified by the user comparison function in Drupal\Core\Plugin\DefaultLazyPluginCollection->sort() (line 100 of core/lib/Drupal/Core/Plugin/DefaultLazyPluginCollection.php).

A 100% repo is to use the "Entity Browser Module" when using a file field (in our case inside a field collection) with the File Browser widget.

Proposed resolution

According to this link:
http://shout.setfive.com/2013/06/14/symfony2-usort-array-was-modified-by...

The problem lies in the lazy loading of the plugin collection. So the fix is simple. In the sort() function (DefaultLazyLoadingPluginCollection) iterate through the array like this:

  public function sort() {
    // iterate to populatae the array
    foreach($this->instanceIDs as $id){
      $pluginId = $this->get($id)->getPluginId();
    }
    // original code
    uasort($this->instanceIDs, array($this, 'sortHelper'));
    return $this;
  }

Remaining tasks

reviews needed, tests to be written and run

User interface changes

none

API changes

none

Data model changes

none

Original report by [username]

none

Fix Ajax #state on IE11

Fix punctuation in link.schema.yml label

$
0
0

link.schema.yml uses the following labels.

        absolute:
          type: boolean
          label: 'Is this URL absolute'
        https:
          type: boolean
          label: 'If the URL should use a secure protocol'

Both the labels should be rewritten to be questions (with a question mark).

Convert RDF mapping migration to derived migrations

$
0
0

Problem/Motivation

Right now, d7_rdf_mapping is a monolithic migration. It would be nice to derive these migrations per entity type and per bundle, and skip those rdf mappings whose destination entity (type) is missing.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

t() calls should be avoided , use $this->t() instead in System module

$
0
0

t() calls should be avoided in classes, use dependency injection and $this->t() instead in DateFormatFormBase.php , SiteInformationForm.php , SiteMaintenanceModeForm.php files.

Viewing all 298718 articles
Browse latest View live


Latest Images

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