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

Remove SchemaCache and CacheArray

$
0
0

Updated: Comment #N

Problem/Motivation

CacheArray has been deprecated. The only left-over use is SchemaCache, which was added in 7.x because the list of tables could get very long, especially due to configurable fields.

Proposed resolution

As field storage tables are no longer exposed in hook_schema() and a lot of tables have been dropped due to conversion to config entities, caches tables are created on-demand as well and are no longer in there. The expected amount of tables defined in hook_schema() will be much much smaller in 8.x. Maybe even the content entity storage tables will be removed. So the schema cache is small enough so that we won't have to worry about it anymore.

Therefore, drop SchemaCache without replacement, together with CacheArray.

Remaining tasks

User interface changes

API changes

CacheArray is removed, has been deprecated for a long time already.

Original report by @cosmicdreams

As a follow up to #1858616: Extract generic CacheCollector implementation and interface from CacheArray we should remove the deprecated CacheArray class and convert the final pieces of Drupal to use CacheCollector instead of CacheArray. Only two uses remain and two places within code comments.

Then we can put the parent issue to bed by writing a change notice.


[meta] Review API to ensure all obsolete functions are marked @deprecated

$
0
0

Updated: Comment #0

Problem/Motivation

We want to minimise any API changes made after beta, so where possible API functions should not be removed unless they have already been marked as @deprecated. Therefore, if we want to remove an API function before 9.0, then it needs to be marked @deprecated now.

Proposed resolution

Review all functions not already marked as @deprecated, check for existing change notices and/or removal issues, review the contents of the function and decide if it should be included in Drupal 8.0. Ask module owners to advise on the status of the APIs in their modules.

Remaining tasks

- Review common functions, and identify the most efficient way of spotting obsolete API functions.
- If practical, attempt to identify the most likely obsolete API functions in core modules.
- Once we've made some progress, open issues for each module, asking the module owner to review their API to identify any obsolete functions and/or state that they do not want to remove any further functions.

User interface changes

None

API changes

A number of functions will be marked @deprecated.

simpletest_phpunit_get_available_tests scans into contrib vendor dirs

$
0
0

Updated: Comment #N

Problem/Motivation

Having installed the vendor dir for a contrib module the vendor components tests are included by simpletest_phpunit_get_available_tests.

Visiting http://drupal.d8/admin/config/development/testing gives

PHP Fatal error:  Class 'TestCase' not found in /.../modules/graphapi/vendor/clue/graph-uml/tests/Graph/Uml/ClassDiagramBuilderTest.php

Removing the graphapi/vendor makes http://drupal.d8/admin/config/development/testing appear but is a DX #fail IMHO as that stop contrib module development.

Running

cd modules/graphapi
composer install --no-dev

installs the FATAL classes.

Proposed resolution

Simpletest should not include tests for 'alien' vendor dirs.

Remaining tasks

Update https://drupal.org/node/2116043 to reflects the directories modules/*/tests and sites/*/*/tests

User interface changes

API changes

Convert theme_checkboxes() to Twig

$
0
0

Issue #2152201 by steveoliver, joelpittet, burgerboydaddy, katy5289, hussainweb, shanethehat, jenlampton, kpa, AnythonyR, EVIIILJ, kgoel, Cottser, dsdeiz, hanpersand: Convert theme_checkboxes() to Twig

Task

Convert theme_checkboxes() to a Twig template.

Remaining tasks

  • Patch
  • Patch review
  • Manual testing
  • Profiling

Steps to test

@todo

Convert system theme tables to table #type

$
0
0

Task

Convert the following theme functions to use the new table #type:

Module Theme function name Where in Code What is it really?
systemtheme_status_reportfunctiontable
systemtheme_system_date_format_localize_formfunctionform table
system theme_system_modules_uninstall functionform table
system theme_system_modules_details functionform table

Related issues

Should widgets / formatters enforce #access / field_access checks ?

$
0
0

Currently the field_access checks on entity form / entity view are done by WidgetBase::form() / FormatterBase::view().

- There are cases when you might want to use a widget even if the current user has no permissions to edit the field - e.g in a exposed view filter. (less sure about use cases for using a formatter while you have no permissions to view the field...)
- This being done in base methods, there is no guarantee that some widgets / formatters don't override it - possible holes.

In Vienna, @fago argued that #access should be the responsibility of the caller, not of widgets / formatters themselves.

Thoughts ?

Require settings.php to exist in the root folder and to explicitly opt-in for multi-site functionality

$
0
0

Problem

  • With the changes to the directory layout in Drupal 8 some parts of the multi-site feature are hidden away from those that don't use it, which is a good thing: Top-level /modules, /themes and /profiles directories can be used for the site modules.
  • However, the settings file for sites must still be places into sites/default/settings.php. This is unnecessary and forces the multi-site concept onto users that shouldn't need to care about it.
  • Moreover, since the multi-site set-up is still supported code cannot simply assume that the sites/default/settings.php file exists. This increases the number of file_exists() checks and makes code paths more complex.

Goal

  • Simplify the Drupal bootstrap by requiring /settings.php to exist and an explicit opt-in for the multi-site functionality.

Proposed solution

  1. Require a top-level, global /settings.php to exist in any case (set up by the installer).
  2. Merge /sites/sites.php into the top-level /settings.php, and turn the $sites variable into that explicit flag for enabling the multi-site functionality.

    This means:

    • If /settings.php does not define the $sites variable at all, then there is no multi-site functionality and no site directory discovery process.
    • If /settings.php defines a bare $sites = array();, then the multi-site functionality is enabled and the site directory is discovered on every request (no change).
    • If /settings.php defines site aliases in the form of $sites['localhost.example'] = 'example.com';, then aliases are applied and resolved before the site directory discovery happens (no change).

    This also means:

    • When the multi-site functionality is enabled, then the top-level/global /settings.php acts as if it was a /sites/all/settings.php, which is a concept that does not exist thus far.
    • The top-level /settings.php is always loaded first. The site-specific settings.php has access to all of the global variables and is able to override them in a granular way. (Big difference to today: Common settings can be shared between sites, only overrides and additions need to be specified.)
  3. Move /sites/default/default.settings.php into /core/default.settings.php, so it is updated when Drupal core is updated.

    This last step could possibly mean that there may not be a /sites/default directory when downloading and extracting Drupal core. The Drupal installer would create /sites/default directory though. It is out of scope and not the intention of this issue to change or remove the /sites/default directory.

Related issues


Original summary by @naxoc

This is a split-out from #760992: Where should site specific modules, themes and settings be kept? to move the settings file to the root folder where modules/ themes/ and profiles/ are also going at some point.

It would go for "default" - but not multisite settings files that would still go in the sites folder.

The existence of a sites.php can trigger trying to find multisite settings as suggested in #1055862: Require sites.php to opt-in for multi-site support/functionality

Update jQuery to 2.1.0

$
0
0

Updated: Comment #8

Problem/Motivation

Our shipped jQuery version is not up to date.

Proposed resolution

Update jQuery!

Remaining tasks

Review the patch.

User interface changes

-

API changes

-


Rename Views method get_field_value() to getFieldValue()

Convert Drupal\system\Tests\InstallerTest into a new Drupal\simpletest\InstallerTestBase

$
0
0

Background

Proposed solution

  • The gist of the InstallerTest class should be moved into a new InstallerTestBase class provided by Simpletest, so as to make it a formal base class for all interactive installer tests + advance on it.
  • The resulting minimal Drupal\system\Tests\InstallerTest class should be moved into the Drupal\system\Tests\Installer\ namespace.

Node preview title "link" goes to home page and user loses their content

$
0
0

Steps to reproduce:
1. create any new item of content e.g. /node/add/page
2. fill in your content
3. scroll to bottom and click "preview"
4. you get "preview trimmed version" and "preview full version"
5. both versions have the "node title" at the top as a link
6. click this link - you are taken to /node
7. you've now lost your content

Equally if you're making changes to an existing node, the same thing happens from step 3, except instead of losing the entire node you just lose the changes you've made.

There doesn't seem to me any point to the node title in preview being a link. I have editors who have lost content and updates because of this. Can this feature be removed in a future update of Drupal, and is there a way to remove the link in the meantime?

Convert theme_radios() to Twig

$
0
0

Issue #2152221 by steveoliver, joelpittet, hussainweb, shanethehat, jenlampton, kpa, AnythonyR, EVIIILJ, kgoel, Cottser, dsdeiz, hanpersand: Convert theme_radios() to Twig

Task

Convert theme_radios() to a Twig template.

Remaining tasks

  • Patch
  • Patch review
  • Manual testing
  • Profiling

Steps to test

@todo

Sticky headers are not calculating the column widths properly.

$
0
0

The sticky headers are not aligning properly with the rest of the table causing the columns to be out of alignment. The issue is that the width of the columns is not being calculated properly which causing the bad alignment. This obviously could be caused by the theme we are using, but considering tableheader.js is a 'core' javascript file, it should work for all themes. Using jQuery's outerWidth() method fixes this and should work universally for all themes.

Attached are two images 'bad' and 'good' to show what this looks like.

Patch to follow

Display which vocabulary the taxonomy belongs when editing a term

$
0
0

Problem/Motivation

In large sites with thousands of terms across different vocabularies it is not possible to know which vocabulary the terms belong to when editing it.
I have a situation where the term 'apple' appears in two different vocabularies ending up with one URL for /apple and another for /apple-0.
Then I visit the two term pages and click edit. At this point, there is no information regarding which vocabulary that term belongs to.

Proposed resolution

Display a text field above Name (see example screenshot). i.e. Vocabulary Fruits

Remaining tasks

  • Get the vocabulary name when editing the term
  • Display the information on the form

User interface changes

(new or changed features/functionality in the user interface, modules added or removed, changes to URL paths, changes to user interface text)

Remove ckeditor.languages cache bin

$
0
0

Updated: Comment #N

Problem/Motivation

CKEditor module provides a ckeditor.languages cache bin (name does not conform to all other bin either :p). This seems overkill to have a bin to store one cache entry, which is a language list. This is not even a large cache entry.

Proposed resolution

Remove this cache bin. This one cache item can happily live in the standard 'cache' bin (Same as ckeditor_plugins cache etc...).

Remaining tasks

Review

User interface changes

None

API changes

None


Add string context to "Weight"

$
0
0

Problem/Motivation

There is the string 'Weight' used in two different context in Drupal;

- Used as "Ordering indicator" in sortable Tables, Node, etc.
- Used as "Measuring quantities" in e-cart's shopping system.

In Chinese, and other languages, different translations are required for each.

Proposed resolution

- Add a context to the string.

Use plugin system for MailInterface classes

$
0
0

MailFactory is now a swappable service thanks to #1889644: Convert drupal_mail_system() to a MailFactory service to allow more flexible replacements. However, alternative implementations are hobbled by the lack of any kind of discovery mechanism for MailInterface classes.

For example, a contrib module like Mailsystem has no way of building a user interface for selecting mail methods, because it has no way of knowing what mail classes are available.

A simple and low-impact solution would be turn existing mail classes into annotated plugins and create a simple plugin manager for them. This would open up options for contrib.

Proposed change notice

Mail backends are now annotated plugins, and can be discovered and implemented via the new plugin.manager.mail service.

The earlier mail.factory service has been removed, and its functionality has been merged into plugin.manager.mail.

Furthermore, the config setting system.mail.interface, which identifies the mail plugin used for a particular message, now takes plugin IDs as values rather than class names.

Creating a mail plugin

To provide a new mail backend in a custom module named mymodule, you must implement Drupal\Core\Mail\MailInterface within the \Drupal\mymodule\Plugin\Mail namespace, and annotate the class:

<?php
namespace Drupal\mymodule\Plugin\Mail;
use
Drupal\Core\Mail\MailInterface;
/**
* A custom mail backend.
*
* @Mail(
*   id = "mymodule_mailer",
*   label = @Translation("My custom mailer"),
*   description = @Translation("An example mail plugin implementation.")
* )
*/
class MymoduleMailer implements MailInterface {
  public function
format(array $message) {
   
// ...
 
}
  public function
mail(array $message) {
   
// ...
 
}
}
?>

See the API documentation for MailInterface for implementation details.

Retrieving mail plugins

Previously in Drupal 8, there was no way to retrieve a list of MailInterface classes. Now, you can use the plugin.manager.mail service:

<?php
// Get a keyed array of mail plugin definitions.
$definitions = \Drupal::service('plugin.manager.mail')->getDefinitions();
// Get a single definition by plugin ID.
$plugin_id = 'php_mail';
$definition = \Drupal::service('plugin.manager.mail')->getDefinition($plugin_id);
// Create an instance of a specific mail plugin.
$plugin_id = 'php_mail';
$mailer = \Drupal::service('plugin.manager.mail')->createInstance($plugin_id);
?>

Mail plugin selection

The Drupal 8 config setting system.mail.interface is a keyed array that maps the message ID to the mail plugin it should use. The values used in this array are now plugin IDs.

Before in Drupal 8

<?php
\Drupal::config('system.mail')->set('interface.default', 'Drupal\Core\Mail\Plugin\Mail\PhpMail')->save();
?>

After

<?php
\Drupal::config('system.mail')->set('interface.default', 'php_mail')->save();
?>

Remove global $databases

$
0
0

Problem

  • global $databases is a legacy global state that leaks into all code.

Proposed solution

  1. Database connection info is read from settings.php exactly once in drupal_settings_initialize().

    → Replace global $databases with Database::setConnectionInfo().

  2. Remove global $databases.

Configuration file name and file-content are not validated on accordance

$
0
0

Problem
A module has a config file with naming bb. another installed module has a config file named aa. The installation don't identify a naming-collision and installs the bb file. That's like aspected, ... but both files could containing the same id bb.

Example
For example you can have a file field.field.node.myfield_bb.yml file in a module but the file contains the id:node.myfield_aa.
This could be in collision with an existing file field.field.node.myfield_aa.yml wich has correctly declared the id:node.myfield_aa.

Proposed solution

  • Validate the accordance between file naming and id definition in the file on the module-installation process
  • Reject the installation if validation fails
  • Show a warning

API changes
Probaply not

Cleanup the container in UnitTestCase::tearDown

$
0
0

Problem

  • \Drupal is a static global state construct, which can leak into unit test environments, in case a previous test could not be completed successfully.

Proposed solution

  1. Allow testing frameworks to explicitly unset any possibly existing container in \Drupal by calling \Drupal::setContainer(NULL).
Viewing all 298090 articles
Browse latest View live


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