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

Replace usages of the at() matcher, which is deprecated

$
0
0

Problem/Motivation

The at() matcher has been deprecated. It will be removed in PHPUnit 10. Please refactor your test to not rely on the order in which methods are invoked.

Steps to reproduce

Proposed resolution

Convert PHPUnit stub setup calls to $this->at() to $this->once(), $this->exactly() or $this->any() depending on the intent of the test.

Convert multiple calls to $this->at() on the same stub method to use either ->willReturnMap() or ->withConsecutive() and/or ->willReturnOnConsecutiveCalls() depending on the test requirements.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet


Add allTranslations() and allTranslations()->count to entity query

$
0
0

Problem/Motivation

I think what we need to do here is enhance the entity query builder to have first-class support for translations. Just like you can do ->allRevisions()->count() to get an accurate count of all revisions that satisfy certain conditions you should be able to do ->allTranslations()->count() or something similar. This is going to be pretty tricky, but a) I think it's the only way to *properly* support this (we could of course, just write manual DB queries to achieve the same, but...) b) that is useful anyway for a lot of use-cases where you currently still have to do things in PHP or actually do resort to manual DB queries in contrib/custom code...

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Don't call mb_strtolower() when generating machine names in Taxonomy tests

$
0
0

Problem/Motivation

Taxonomy's test suite is littered with this sort of thing when creating vocabularies:

$vid = mb_strtolower($this->randomMachineName());

This isn't necessary. The calls to mb_strtolower() aren't really needed, because even though $this->randomMachineName() can return upper-case letters, those are allowed in machine names.

Steps to reproduce

N/A

Proposed resolution

When creating vocabularies in tests, don't call mb_strtolower($this->randomMachineName()) to generate vocabulary IDs. Either rely directly on $this->randomMachineName(), or use TaxonomyTestTrait::createVocabulary().

Remaining tasks

Implement the proposed resolution across Taxonomy's test suite, then commit the changes. No additional test coverage should be necessary.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

Remove $op from hook_node_grant and hook_node_grant_alter

Tests for $term->parent in Term::save()

$
0
0

Problem/Motivation

taxonomy_term_save() used to accept an array of arrays of Term IDs for $term->parent, but, as stated by @Berdir in #9, support was removed in the taxonomy entity class conversion patch, but there aren't any tests. We should write tests.

See the Change Record Entities are now classed objects using a defined interface for more information about what happened to taxonomy_term_save().

Proposed resolution

Write tests if they do not exist already.

Remaining tasks

  1. Determine if there are already tests to cover this
  2. If not, write them

User interface changes

None.

API changes

None.

Original report by @mr.baileys

While working on #1162226: taxonomy_term_save should document what is in a $term object, I noticed that taxonomy_term_save() currently supports the following values for $term->parent:

  1. A single tid
  2. An array of tids
  3. An array of arrays of tids

I briefly talked to catch on IRC and couldn't really figure out why we should accept an array of arrays of tids. The tests run fine just supporting 1. and 2., and so does devel generate-terms.

My guess is that this is a left-over from how taxonomy_save_terms() used to be fed input straight form the form API (see #17955: Remove use of form_item() in taxonomy where this array of arrays support was introduced), so I suggest removing it.

Remove dead code in Taxonomy's Views handlers

$
0
0

Problem/Motivation

There is "legacy code" in three Views handlers that was removed from core in #1552396: Convert vocabularies into configuration but immediately and accidentally reintroduced in #1850792-26: Make init() method consistent across all views plugins. Because of the isset() check, it has been dead code this entire time, and the whole init() method can be removed in both cases.

The init() code was to handle the conversion of legacy Vocabulary IDs to the newer Vocabulary machine names.
While that init() patch was being worked on, the larger conversion was committed.
Due to a bad rebase, the legacy workaround was reintroduced.

Steps to reproduce

N/A

Proposed resolution

Remove the init() code

Remaining tasks

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Problem with function _field_invoke when used on a content type with no field instance

$
0
0

I'm using Drupal 7.0

I have created a custom module that have 2 major responsabilities:

- Create a custom content type by code (that is not using the field api)
- Import content for that specified content type from a csv file.

This module used the function: drupal_form_submit($form_id, $form_state)
to import the content.

When I use my module to import content, I have the following errors:

Invalid offset supplied in field.attach.inc at line 198.

After doing a lot of investigation, I found some interesting stuff in the function:

function _field_invoke($op, $entity_type, $entity, &$a = NULL, &$b = NULL, $options = array())

The above function is calling _field_invoke_get_instances($entity_type, $bundle, $options) (line 184)

This function return an array with all content type with all fields instance.

In my case, the Array returned for my content type is empty (no field instance in the array).

So, at line 189 of the _field_invoke function ($field_name = $instance['field_name']) :
The instruction is not valid because the offset 'field_name' doesn't exist.

I suggest that the function _field_invoke should be modified as follow:

Insert an if statement between line 188 and line 189 to verify the validity of the 'field_name' offset.

line 188 foreach ($instances as $instance) {
if (isset($instance['field_name'])) {
line 189 $field_name = $instance['field_name'];

Thanks in advance !

Test path alias changes after node preview followed by save


Implement an API and/or UI for more manageable per-bundle permissions

$
0
0

Problem/Motivation

This is spun off from #2862422: Add per-media type creation permissions for media.

That issue added per-bundle permissions to the Media module, which raised a number of UX concerns, specifically around #2862422-61: Add per-media type creation permissions for media and #2862422-62: Add per-media type creation permissions for media. Anytime any module wants to add per-bundle permissions, the already intimidatingly large permissions table swells to an even greater size, like a large, poisonous bullfrog. Something must be done!

Proposed resolution

We need to figure out a way for modules to provide bundle-specific permissions in a way that won't scare administrators, confuse site builders, or crash browsers with a million-row table. One possible proposal surfaced in #2862422-61: Add per-media type creation permissions for media, and other discussion has taken place in #1765576: Redesign Permissions Page and #2919636: Design a better model for the permissions UI.

Proposal 1: On the bundle forms

Proposal 2: Permissions page/route

Remaining tasks

Figure out what to do, then write a patch and commit it. Standard operating procedure.

User interface changes

Hopefully!

API changes

Maybe?

Data model changes

Hopefully not!

[META] Several problems in search_update_totals()

$
0
0

Problem/Motivation

There are currently several open issues reporting problems in the function search_update_totals() in search.module. This function runs at the end of Search cron, and updates the overall word scores for each word that has been indexed, so that when search queries run, this overall word score can be used to rank results. I am making a meta issue here to clarify what is going on, and possibly we can fix them all at the same time.

The underlying problem is that if you have a site with lots of nodes, depending on your search settings, you can run out of memory or have database exceptions when this code is run. And even if you don't, the calculation is not very optimal.

The current Drupal 8 code for this function is:

function search_update_totals() {
  // Update word IDF (Inverse Document Frequency) counts for new/changed words.
  foreach (search_dirty() as $word => $dummy) {
    // Get total count
    $total = db_query("SELECT SUM(score) FROM {search_index} WHERE word = :word", array(':word' => $word), array('target' => 'replica'))->fetchField();
    // Apply Zipf's law to equalize the probability distribution.
    $total = log10(1 + 1/(max(1, $total)));
    db_merge('search_total')
      ->key('word', $word)
      ->fields(array('count' => $total))
      ->execute();
  }
  // Find words that were deleted from search_index, but are still in
  // search_total. We use a LEFT JOIN between the two tables and keep only the
  // rows which fail to join.
  $result = db_query("SELECT t.word AS realword, i.word FROM {search_total} t LEFT JOIN {search_index} i ON t.word = i.word WHERE i.word IS NULL", array(), array('target' => 'replica'));
  $or = db_or();
  foreach ($result as $word) {
    $or->condition('word', $word->realword);
  }
  if (count($or) > 0) {
    db_delete('search_total')
      ->condition($or)
      ->execute();
  }
}

Here are the currently-reported problems with this code:

  1. #1189484: ER_TOO_BIG_SELECT in search_update_totals() is about the join in the "SELECT t.word as realword..." query. This join on a site with too many nodes can be too big and trigger a ER_TOO_BIG_SELECT exception in MySQL.
  2. #1365786: Fatal error: Allowed memory size exhausted in modules/search/search.module is about the creation of the db_or() in the loop running out of memory when adding all the words to be deleted to the condition object.
  3. #1763914: Uncaught exception thrown in shutdown function due to SQL Server max of 2100 parameters is about the db_delete('search_total') query running out of parameters in SQL Server and triggering a database exception if it has a lot of words to delete. Although this issue is reported against SQL Server, it could occur in other databases as well, since all databases have parameter limits on DELETE queries.
  4. #257916: Improve performance of search totals calculation is about optimizing the calculation of totals at the top so that it processes a chunk of words together instead of doing each word separately. This one is not so much of a bug as a "could be more optimal" task.

Proposed resolution

Fix the three bugs, and probably the "could be more optimal" task as well.

Remaining tasks

All issues still need resolution. Some have patches, but probably the approaches on the 3 bugs should be combined.

User interface changes

None.

API changes

None.

Add explicit $options documentation for Connection::insert()

statistics is not real

$
0
0

Is the statistics data accurate? I am positive it is not. I have content with 20k hits, which is impossible, because I track my site and it does not get so much traffic. So 20k view or more cant be true. I suspect it counts bots....

Bring Back Partial Entity CRUD API

$
0
0

Per developer thread :
How load only some node fields?
http://drupal.stackexchange.com/questions/199268/how-load-only-some-node...

An entity load or node_load is too slow and memory intensive. For long running batch operations node api is unusable.

Quote :
Why do think it violates anything? I'm trying to work around performance issues. It doesn't make sense to load 100 fully blown node objects just check values of one field for each of those nodes. And I do want to use API for that. If I wouldn't, I would write SQL queries to get that data, but that defeats the purpose of using drupal in the first place.
Quote :
Unfortunately what you want doesn't exist in the API @SiliconMind, I just spent a little bit checking. All field data is loaded in bulk via ContentEntityStorageBase::doLoadRevisionFieldItems, and the standard SqlContentEntityStorage doesn't contain any methods for extracting individual fields. If you haven't already done so, it might be worth benchmarking this to see if there's a real problem. A lot of work was done on the cache system for D8, things might not be as slow as you think

Lets provide relief to D8 Devs by providing this important DX api.

Replace usages of AssertLegacyTrait::assertNoText, which is deprecated

$
0
0

Problem/Motivation

AssertLegacyTrait::assertNoText() is deprecated in drupal:8.2.0 and is removed from drupal:10.0.0. Use $this->assertSession()->responseNotContains() or $this->assertSession()->pageTextNotContains() instead. See https://www.drupal.org/node/3129738

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

"Run cron every" setting (cron_safe_threshold) is not an interval but a Boolean

$
0
0

The first thing we found in XHProf during the D7 upgrade, once we were able to convert enough of our code to actually load a page, was a call graph with aggregator_cron() taking up some ridiculous proportion of the request. And because that cron run failed, it kept doing this over and over and over again. This was due to the poormanscron functionality that we added in D7. I had to ask chx how to disable this because I was looking for a boolean and it's actually a cron_safe_threshold variable that, when set to 0, disables the functionality.

I think given the ability for this feature to completely kill a high-performance site like Drupal.org, we should document it in settings.php, along with how to disable it. For now I've updated http://drupal.org/cron to have this information.


Write integration tests for ImportStorageTransformer and ExportStorageManager

$
0
0

Problem/Motivation

#3085604: Protect against concurrent config transformations added these two classes and it included unit tests.
Those unit tests made use of the at() matcher, which has been deprecated by PHPUnit and is being removed by #3217717: Replace usages of the at() matcher, which is deprecated.

Proposed resolution

Write integration tests to also prove the system is actually working, instead of relying on hyper-specific and brittle unit tests.

Remaining tasks

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Add more granular block permissions

$
0
0

Problem/Motivation

The block system has but one permission: "Administer blocks", creating an all-or-none situation where granting a user any permission to the subsystem entails giving them god powers there. Especially now that we have custom blocks, I expect people will want more of the flexibility they currently have with nodes to restrict access to different operations by bundle. I know I have for a long time!

Proposed resolution

I propose adding more granular permissions. Update block's permissions as compared to node's:

NodeBlock
Bypass content access controlx
Administer content typesAdminister block types
Administer contentAdminister blocks
Access the Content overview pageAccess the Custom block library page
View published contentx
View own unpublished contentx
View all revisionsx
Revert all revisionsx
Delete all revisionsx
Per type: Create new contentPer type: Create new blocks
Per type: Edit own contentx
Per type: Edit any contentPer type: Edit any blocks
Per type: Delete own contentx
Per type: Delete any contentPer type: Delete any blocks
Per type: View revisionsx
Per type: Revert revisionsx
Per type: Delete revisionsx

Marking the above items as 'x' (or deferred to separate issue) because:

Remaining tasks

  • Decide if and what permissions to add.
  • Write a patch.
  • Add tests.
  • Review and commit.
  • Write a change notice.

User interface changes

TBD.

API changes

TBD.

Add eslint rules to check for jQuery usage

$
0
0

Problem/Motivation

Inspired by Github's approach to removing jQuery from the front-end, add the eslint jquery plugin to Drupal core's eslint config. This will help identify and prevent new jQuery usages and make it easier to inventory existing ones.

Steps to reproduce

Proposed resolution

  • Install the eslint jquery plugin that Github used for their jQuery removal efforts.
  • Add rule-specific /* eslint-disable */ declarations to files still using jQuery, so they can still pass tests
  • Determine if additional eslint checks are needed beyond those provided by the eslint jquery plugin, and add those as well.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

In an effort to curtail new uses of jQuery in core, the eslint core-js-passing config now includes the eslint-plugin-jquery plugin. Currently, only a small number of the available rules in eslint-plugin-jquery are enabled; these are the rules that check for jQuery features not used by core. As core eliminates uses of a given jQuery feature, additional eslint-plugin-jquery rules can be enabled to prevent those jQuery features from being reintroduced.

Text item sample generation fails if max length < 3

$
0
0

Problem/Motivation

When the maximum length of a text field is set to less than 3 the generateSampleValue() function will throw an error:
mt_rand(): max(0) is smaller than min(1)

This is because the max value is the max_length divided by three, implicitly cast to an int.

Proposed resolution

Use the ceil() function to ensure the division provides a max of at least 1 on max_lengths greater than 0.

Remaining tasks

Patch needs review.

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Layout Builder View Node Revisions Throwing Error

$
0
0

Problem/Motivation

Steps to reproduce

1. Create a page with layout builder and save the page.
2. Edit the page and change something and save it, which will create a new revision as expected.
3. Click on the revisions tab and click on a previous revision.
4. Page throws an error saying "The website encountered an unexpected error. Please try again later."

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Viewing all 298156 articles
Browse latest View live


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