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

[Meta] Make Drupal 8 work with PostgreSQL or remove support from core before release

December 16, 2013, 4:36 am
$
0
0

Problem/Motivation

As of Drupal 8.0-alpha9 release (19. Feb. 2014) it's possible to install Drupal when running PostgreSQL as database backend. Now all remaining issues related to PG need fixing to make all tests pass (temporary) PostgreSQL TestBot.

Now that all major breaking PostgreSQL issues are fixed we can start working at the remaining ones.

Identified test groups with more than one fail or exception:

Identified single test fails:

Identified test fails caused by bot, e.g not PostgreSQL related

  • none, but random exceptions are possible (working on a fix)

Identified open remaining tasks and bugs required to make TestBot passing all tests

Nice to have

Fixed issues

User interface changes
None.

API changes
None.

↧
Search

Remove the UI for installing/updating modules from update module if it is not fixed in time for release

October 8, 2014, 3:45 am
$
0
0

We added this feature in Drupal 7 but it has fallen into disrepair.

The main reasons for this as I see it:

1. Core developers (and contrib developers too mostly) never use it.

2. It's not up front in the installer, which it would/could be if we'd added module browser in core.

#2311691: Updater UI for installation is broken is a critical bug with the functionality.

Because we could release Drupal 8 without this feature, then add it back later, I'm opening this issue for removal. We don't need to do that now, but should do so if we get to the last few critical issues against core and that one is still not fixed.

Postponed until

We will try to resolve #2042447: Install a module user interface does not install modules (or themes) first, but if that does not land before we get closer to RC.

↧
↧

Updating existing modules or themes with the Update Manager does nothing (files are downloaded but no next steps are provided)

February 15, 2015, 4:12 pm
$
0
0

To reproduce:

1. Set up your filesystem so the webserver owns the files (easiest way to test this).
2. Download the contrib theme release from https://www.drupal.org/node/2398343 and install it on a Drupal 8 site (use the patch from #2042447: Install a module user interface does not install modules (or themes) if you want to install it with the Update Manager).
2. Go to admin/theme/update. It correctly tells you there's a newer version and lets you download the files.
3. But nothing happens after that. It essentially makes it look like you're finished and has a success message on the screen, but never takes you to the next screen (as Drupal 7 does) to actually replace your existing copy of the theme with the downloaded new copy.

Part of this is fixed by #2042447: Install a module user interface does not install modules (or themes) but the fundamental problem here can be seen from comparing update_manager_download_batch_finished(), which is a batch "finished" callback, between Drupal 7 and Drupal 8:

https://api.drupal.org/api/drupal/modules!update!update.manager.inc/function/update_manager_download_batch_finished/7 (Drupal 7)
https://api.drupal.org/api/drupal/core!modules!update!update.manager.inc/function/update_manager_download_batch_finished/8 (Drupal 8)

The code in Drupal 7 does a drupal_goto() which works to send the user to the next step; the blind replacement of that with a RedirectResponse in Drupal 8 does nothing since there's no mechanism for batch finished callbacks to return a response object and have it used.

This may require changes to the batch API to fix, to give batch finished callbacks some way to (conditionally) set a redirect.

This is a critical bug since updating existing modules and themes is one of the main purposes of the Update Manager module, and especially because people use this to perform security updates (which makes it even worse to have this fail but not be clear in the administrative interface about the fact that it failed).

↧

Suppress validation of required fields on ajax calls

April 23, 2015, 6:35 am
$
0
0

Problem/Motivation

At the moment we only have #limit_validation_errors for form elements of type button and submit. Using it it is possible to turn off validation completly or enable it only for desired regions. But there is no option to say what should not be validated.

Let's look at a simple example.

We have a form structure, which enables us to add more items to the form through ajax. Each of this items might have a required field. When the user submits the ajax call to add another item the form is automatically validated and if the user decided first to generate couple of items and then fill out the required fields in each of them, she will not be able to do this, as she is going to get error saying that some of the fields are required and a new item will not be generated.

Now the developer has the option to suppress the whole validation with setting 

<?php
#limit_validation_errors = array()
?>

But by using this even the custom validation introduced by the developer will be suppressed, e.g. the user should get a validation error, if she generated more than 10 items.

Instead there should be a possibility to generate items with required fields without filling them out and they should be validated only when the whole form is submitted and not on each ajax call.

Proposed resolution

Introduce a new setting for the form control '#ajax' called 'suppress_required_fields_validation', which when set to TRUE, will force the FormValidator to skip validation of required fields for the ajax call this setting was set for.

A form element might then set the ajax form control with the setting suppress_required_fields_validation like this:

<?php
        '#ajax'=> array(
          'callback'=> 'my_custom_ajax_callback',
          'wrapper'=> 'my_custom_wrapper_id',
          'effect'=> 'fade',
          'suppress_required_fields_validation'=> TRUE,
        ),
?>

Remaining tasks

User interface changes

none

API changes

New setting 'suppress_required_fields_validation' for the form controll '#ajax'.

The patch commited with the issue shows the changes needed to achieve this.

↧

Make Drupal handle incoming paths in a consistent and case-insensitive fashion for routing/aliases

August 28, 2013, 4:11 am
$
0
0

Problem/Motivation

Whilst working on #1987898: Convert user_view_page() to a new style controller we've discovered that the 8.0.x routing system is case sensitive.

In drupal 7 /node and /NODE would respond with the same page. In Drupal 8 /NODE will get a 404.

In additionath and alias should be consistent.
for eg. create node as node/1 and path alias as /path/alias

Node/1 - 404
Path/Alias- not 404

Proposed resolution

Drupal 8 should handling incoming paths consistently, and independent of the database back-end and whether the path is aliased or not.

Remaining tasks

User interface changes

API changes

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue categoryBug because links in D6/D7 sites can break during an upgrade to D8.
Issue priorityMajor because previously working links can break during a D8 upgrade. Not critical because:
  • There are workarounds (e.g. .htaccess rules).
  • It can't actually result in any data integrity or security issues, just a whole lot of embarrassing broken links.
  • We can fix it in a patch release safely.

See #23 for more details.

original report:

Whilst working on #1987898: Convert user_view_page() to a new style controller we've discovered that the routing system is case sensitive.

In drupal 7 /node and /NODE would respond with the same page. In Drupal 8 /NODE will get a 404.

This might have some interesting repercussions for site upgrading to D8 where links that used to work no longer do. Also when we match paths in BlockAccessController::checkAccess() we convert everything to lower case. I think we also need to think about page caching. AFAICS in Drupal 8 this will be case sensitive because the page cache cid is a hash. In Drupal 7 I think it was a just path and stored in a varchar field so in mysql in would be case insensitive.

↧
↧

Migration Files for Drupal 7 Block Content Type

January 27, 2015, 12:44 pm
$
0
0

Create Files to enable end user to migrate Content Types from Drupal 7 to Drupal 8.

↧

EntityListBuilder should render the entity label

April 23, 2015, 8:09 am
$
0
0

Problem/Motivation

EntityListBuilder currently just renders the entity operations as the only part of the row. This is not very useful as is, so it always needs to be extended. In the most trivial case, which is implemented several times in core, it is extended just to display a label in each row in front of the operations. This is cumbersome and makes the out-of-the-box experience for new entity types less than ideal.

Proposed resolution

Make EntityListBuilder render a label for each render in case the entity type provides a label key. That way EntityListBuilder can be used as is in core but also for contrib and custom entity types which do not need anything fancy.

As a second step we could consider making the label a link to the entity view page, but let's do that in a follow-up as that is non-trivial in its own right.

Remaining tasks

User interface changes

API changes

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue categoryBecause this increases the maintainability of Drupal because it actually removes code this is not a feature request but a task
Issue priorityNormal because nothing is broken as is, even though the DX is less than ideal
DisruptionDisruptive for core/contributed and custom modules that extend the default EntityListBuilder because a label will automatically be added. In most cases, they will have added the label manually anyway, and they will have used the same key that EntityListBuilder uses so they will not be affected, but in some cases this could lead to the label being displayed twice.
↧

Add an active_theme twig function

January 29, 2015, 1:35 pm
$
0
0

Problem/Motivation

$current_theme from D7 has no equivalent in Drupal 8.

Templates knowing what theme is active is useful when paired with the functionality we see with modules such as Theme Key (https://www.drupal.org/project/themekey), where complex theme switching rules are used. There are also use cases like the front end theme loading a piece of content using the admin theme and vice versa. In these cases markup changes may be desired, but the template needs context to understand how it is being presented.

Proposed resolution

Add an active_theme twig function.

Remaining tasks

User interface changes

API changes

The new twig function, active_theme.

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue categoryTask because we are adding a function to twig that is missing as compared to D7.
Issue priorityMajor. The parent is Major because this and some related functions that existed in D7 are missing from the theme system in D8. Lack of this particular functionality prevents D7 modules which use it from being ported to D8.
DisruptionThis should produce little disruption, except to patches on similar issues that are adding twig functions.
↧
Search

Make 'user.permissions' a required cache context

May 21, 2015, 11:52 am
$
0
0

Problem/Motivation

The SmartCache issue promises to bring a huge performance boost. But, it's not without caveats. This issue is about significantly reducing one of those caveats. Please read on.

Quoting myself in #2429617-62: [PP-7] Make D8 2x as fast: SmartCache: context-dependent page caching (for *all* users!):

We had a (very long) discussion about the security implications of this issue at DrupalCon LA with Mark Sonnabaum, Wim Leers, Crell, dawehner, webchick, Alex Pott and fgm.

The problem

If a piece of code (an access result, a function building a render array …) forgets to add a certain cache context, it's possible for information disclosure to happen: if something should only be accessible for users with role A, and the user.roles cache context is missing, then if a user with role A first accesses the content, and then a user with role B accesses it, then the user with role B will be able to see the content.

[…]

The solution

  1. Document security considerations for custom/contrib modules (and custom especially): those who don't have the resources to either do the necessary QA nor write the necessary test coverage should opt out by setting max-age = 0.
  2. …

This issue is about implementing that requirement.

Proposed resolution

Make 'user.permissions' a required cache context

Remaining tasks

Make tests green.

User interface changes

None.

API changes

None. Solely a default configuration change.

↧
↧

move comment.theme.css to classy

May 15, 2015, 1:26 pm
$
0
0

Problem/Motivation

See: #2489460: [Meta] Move module.theme.css files to Classy

Proposed resolution

Move the CSS file to classy
Create a library for the CSS file
Add the library in the Classy twig template

Remaining tasks

  • Add screenshots.

User interface changes

None for Classy, Stark will be more Stark

API changes

None

Stark:

Classy:

↧

Port password-hash.sh to a console command

June 19, 2014, 1:16 pm
↧

Port rebuild_token_calculator.sh to a console command

June 19, 2014, 2:13 pm
↧

Port update-countries.sh to a console command

June 19, 2014, 10:03 pm
↧
↧

Integrate Symfony Console component to natively support command line operations

April 16, 2014, 10:45 pm
$
0
0

Postponed on 8.1.x being open for development.

Problem/Motivation

Drupal 8's new OOP niftiness just sits there waiting to be driven around from the console.

A simple composer requirement plus a few classes later, and it can be.

Here's an easy introduction to Symfony's Console component: http://symfony.com/doc/current/components/console/introduction.html

Drush is very useful for complex tasks such as drush make, and remote usage with site aliases, as well as working with Drupal versions other than 8. These type of tasks would be outside the scope of the console.

However, the addition of console commands to core, with stringent code review and testing requirements, would be a framework useable by Drush, allowing Drush to slim down in the Drupal 8 use case.

Beta phase evaluation

evaluating for https://www.drupal.org/contribute/core/beta-changes

the first thing that needs to be decided is, is this a feature request.
which leads me to https://www.drupal.org/core/issue-category

Reading that it does seem this is a feature, so moving this to 8.1.x and postponing it. (also see @webchick comment in #44)

Proposed resolution

Add the dependencies, create a core/console script, and off we go.

Remaining tasks

  • Proof of concept... See below.
  • Determine scope for console-oriented tasks.
  • Determine testing regimen. Symfony gives us ConsoleTest.
  • Contemplate contrib extensions.
  • Add your consideration here...

User interface changes

Users will be able to type things like core/console module:install my_module. That seems desirable, doesn't it?

API changes

↧

module_exists() always returns FALSE during early bootstrap

May 28, 2015, 9:35 am
$
0
0

Problem/Motivation

The module_exists() function always returns FALSE during early bootstrap, as module_list() returns an array of module names with numeric indexes in that case (see system_list() and module_list()).

Proposed resolution

Always return an associative array.

Remaining tasks

  • Validate the proposed solution
  • Write a patch
  • Reviews

User interface changes

None

API changes

None

↧
Search

file_unmanaged_save_data() doesn't clean up its temp files

May 27, 2015, 6:47 pm
$
0
0

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.

↧

SQL layer: $match_operator is vulnerable to injection attack

May 21, 2015, 10:17 am
$
0
0

Problem/Motivation

#2490420: EntityAutocomplete element settings allows sql injection and for arbitrary user-supplied data to be passed into unserialize() was not only arbitrary code execution via unserialize, but even if it had used JSON it would still have led to a SQL injection attack.

We try to reduce those attacks as much as possible, but the simple code of:

<?php
  // [...]
  $match_operator = !empty($_GET['match_operator']) ? $_GET['match_operator'] : 'CONTAINS';
  $entity_labels = $handler->getReferenceableEntities($string, $match_operator, 10);
?>

is making core vulnerable to a SQL injection attack.

It is well known that

a) one should escape user input (a check_plain() would not be enough though)
b) not trust user input (yes, need a white list)
c) use FORM-API with an options element (views exposed filters)

etc. as best practice, but it has been common security hardening in Drupal 8 to make such attacks as hard as possible.

And in this case nothing in https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21... tells that $match_operator MUST not be user input.

So it is not even that hard to make that mistake, when copying e.g. from core's autocomplete handler / controller ...

Proposed resolution

- Harden the SQL layer some more

There is several possibilities:

a) preg_replace('\W', '', $op)
b) a white list of known operators

Both have the problem that the list of operators is dynamic, e.g. there is "BETWEEN SYMMETRIC" in POSTGRESQL and whitespace is even used within other valid database operators.

A possibility how to solve that would be to introduce a:

SafeDatabaseOperator('BETWEEN SYMMETRIC') class and allow an object instead of just a string to escape the escaping / limited white list of most common operators.

That would be a backwards compatible API change though.

Could throw a helpful Exception for the operators whitelist case however to point to the docs how to get arbitrary operators working.

Also could of course use a variable / setting / ... to override list of allowed operators.

Tagging for potential backport to D7.

Remaining tasks

- Discuss

User interface changes

- None

API changes

- Maybe allow $match_operator to be string|object
- Maybe restrict list of operators

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue categoryBug
Issue priorityCritical because security
↧
↧

Introduce PluginDefinitionInterface

March 24, 2015, 2:40 pm
$
0
0

Problem/Motivation

The plugin system contains a lot of code that was designed to accomodate array *and* object plugin definitions. As a result type hints are missing for definition parameters and we have to jump through all kinds of hoops to accommodate both data types. This creates code that is hard to read, hard to test, and hard to maintain and extend, of which #2458769: Derivative plugin definitions contain base plugin IDs instead of derivative IDs is an example.

Proposed resolution

Introduce PluginDefinitionInterface and allow plugin definitions to either be arrays or instances of a class that implements this interface. We can then perform operations on both types of definitions by requires arrays to conform to predefined structure and by calling methods on the interface.

Remaining tasks

Discuss and develop a solution.

User interface changes

None.

API changes

None. This is an internal refactoring only.

Blocked issues

↧

Migration Files for Drupal 7 User Picture Field

January 26, 2015, 12:53 pm
$
0
0

Create Files to enable end user to migrate User Picture Field from Drupal 7 to Drupal 8.

↧

Allow file_scan_directory() to ignore folder

December 15, 2014, 8:49 am
$
0
0

The file_scan_directory() is a demon that slow the whole Drupal system 10~100 times when your development directory has other tools like node_modules, bower_components.

I purpose a simple solution:

// Allow ignoring the folder, intend for folder that contains too many useless files.
if (file_exists($dir . '/.scanignore')) {
  return $files;
}

If that folder contains a '.scanignore' file, just ignore that folder.

↧
Viewing all 295039 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>