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

Fatal error when trying to edit book nodes (that have children) in large books

$
0
0

Problem/Motivation

STR:

  1. First create a new book add a series of child pages nested to as deep as 7 to 8 levels.
  2. Now create a second child page of the top-level book node and set of several child pages of that.
  3. When attempting to edit a node that has children that go deep enough, there is a fatal error:
    [Mon Jan 25 17:23:18.977405 2016] [:error] [pid 27538] [client 206.192.168.17:5717] PHP Fatal error:  Call to a member function label() on null in /var/www/html/core/modules/book/src/BookManager.php on line 414</li>
      <li>

the recurseTableOfContents function doesn't properly handle the case when it's pruned every node in a particular branch. E.g. it runs through this foreach loop, and every node is below the depth_limit. The break exits the loop, and proceeds through the function.

<?php
    foreach ($tree as $data) {
      if ($data['link']['depth'] > $depth_limit) {
        // Don't iterate through any links on this level.
        break;
      }
      if (!in_array($data['link']['nid'], $exclude)) {
        $nids[] = $data['link']['nid'];
      }
    }
?>

It then crashes within this foreach loop, as it attempts to call Unicode::truncate without verifying if there are any nodes left.

<?php
   foreach ($tree as $data) {
      $nid = $data['link']['nid'];
      if (in_array($nid, $exclude)) {
        continue;
      }
      $toc[$nid] = $indent . '' . Unicode::truncate($nodes[$nid]->label(), 30, TRUE, TRUE);
      if ($data['below']) {
        $this->recurseTableOfContents($data['below'], $indent . '--', $toc, $exclude, $depth_limit);
      }
    }
?>

Proposed resolution

add a check on or after the first foreach loop that returns from the function if there aren't any nodes.

<?php
    // Return to calling function if all links have been excluded due to depth
    if (empty($nids)) {
      return;
    }
?>

Remaining tasks

Add tests

User interface changes

n/a

API changes

n/a

Data model changes

n/a


[meta] No definition of "Experimental" & not nearly enough warning

$
0
0

Problem/Motivation

Drupal 8 introduces the concept of an "experimental" module (in a "Core (experimental)" package), which indicates that a module is shipped with core but not fully supported. We plan to rely more on this concept as we add new optional functionality in minor versions. However, there is currently not enough explanation of what this means for site users or developers.

  1. There is no definition of what "experimental" actually means.
  2. Experimental modules should have separate versions than core -- alpha, beta, etc.
  3. There is no obvious warning when you enable an experimental module -- just an innocuous-seeming success message. And enabling the module via (e.g.) Drush won't even have had the information from the group label that core does (see above screenshot).
  4. The status report does contain the needed warning, but could use a link to more details (the aforementioned handbook page).
  5. The help page might also benefit from a note about the module being experimental, and known issues should be documented (there or somewhere else).

Proposed resolution

  1. #2657062: [policy, no patch] Experimental module policy and handbook page
  2. #2656994: Experimental modules should have their own version numbers
  3. Expand/highlight experimental module group info or info when version differs from core's?
  4. #2663796: Use a confirmation form when enabling required modules
  5. #2657096: Provide a link to the experimental module policy in the status report warning
  6. #2657178: Warn about experimental modules on their help pages
  7. Document known issues for help?
  8. Standardize on experimental module section for release notes? (Known issues, version, etc.)

Remaining tasks

File child issues.

Calling EntityManager::createInstance() fatals

$
0
0

Calling EntityManager::createInstance() fatals, because it does not use entity creation through the storage controller.

Entity load hooks are called in the wrong order

$
0
0

Posted by xjm

Problem/Motivation

(From #1346032-14: Ordering of hook_entity_delete() is inconsistent.)

Proposed resolution

  • Change the hook order so that the type-specific hook is first.

Remaining tasks

  • TBD

User interface changes

  • The entity-type-specific load hook will now precede the generic entity load.

API changes

  • TBD

For Drupal migration, identify the source module

$
0
0

The migrate_upgrade UI is now providing a confirmation page, showing the administrator performing the upgrade what modules are being upgraded from their legacy sites (and what modules are not). There is not currently an automated way to get this information - the closest thing is the source_provider annotation on the source plugin, but this doesn't help us with configuration-only migrations. My suggestion is adding a module key to the source plugin config for the Drupal migrations.

Allow annotations to inherit across namespaces

$
0
0

Problem/Motivation

While working on #2560795: Source plugins have a hidden dependency on migrate_drupal, I discovered (with help from @chx and @tim.plunkett) that it's impossible (at least without doing a bunch of black magic) for an annotation class to extend another annotation class if they reside in different namespaces. This is a major gotcha for anyone who wants to define a new annotation by extending an existing one.

Proposed Resolution

AnnotatedClassDiscovery should accept an array of additional namespaces in which to search for annotation classes.

Remaining Tasks

^^ Write that, in patch form. Commit heartily, then sit back and have a drink.

API Changes

Additional argument to AnnotatedClassDiscovery::__construct() and greater flexibility in defining annotations.

How to disable E-mail Id from being published

$
0
0

Hi,

I am facing issues with disabling E-mail information from being published with the comment posted by a visitor in

the Blog section. As far as I know, I am using the out of the box text editor for the comments section. Please refer

image uploaded.

With Regards,

Saakar

Use a confirmation form when enabling required modules

$
0
0

Problem/Motivation

Part of #2649768: [meta] No definition of "Experimental"& not nearly enough warning. When you enable an experimental module, you have no warning or indication that it is a risky thing to do.

Proposed resolution

  • Redirect to a confirmation form when enabling an experimental module.
  • Use the same form when any dependency is a required module.

@webchick was in favor of this approach when we discussed it previously.

Remaining tasks

  • Patch needs review.
  • Patch needs tests. There are at least three scenarios:
    1. If there is no experimental module, no message is displayed, and the experimental confirm form is not used.
    2. If any of the modules' dependencies are experimental, there should be both a list of the dependencies to enable and a list of the experimental modules.
    3. If the module itself is experimental but does not have any unchecked dependencies to enable, the experimental message should be displayed, but no list of dependencies.
  • Drush still provides no specific warning when the experimental module is enabled. Followup PR to provide some warning in Drush?
    $ drush en migrate
    The following extensions will be enabled: migrate
    Do you really want to continue? (y/n): y
    migrate was enabled successfully.

User interface changes

Single experimental module, no dependencies

Multiple experimental modules

Experimental modules when a required dependency was not submitted

(This includes the same language as the confirm form for that existing action.)

API changes

None.

Data model changes

None.


Undefined index: strip_tags_and_unescape in _options_prepare_options() after updating to 7.42

$
0
0

After updating from 7.41 to 7.42 I get the following notice: Notice: Undefined index: strip_tags_and_unescape in _options_prepare_options() (line 282 of /home/mydomain/public_html/modules/field/modules/options/options.module).

I am not sure where this comes from, but I only get this on specific pages. In 7.41 I never had this message.

ajax.js insert command sometimes wraps content in a div, potentially producing invalid HTML and other bugs

$
0
0

Problem/Motivation

Prior to #39, Drupal.AjaxCommands.prototype.insert() always added a DIV wrapper to the content returned by the server. Since #39, it only does that if the content isn't already contained in a single root element. The current HEAD code is:

    
      // For legacy reasons, the effects processing code assumes that new_content
      // consists of a single top-level element. Also, it has not been
      // sufficiently tested whether attachBehaviors() can be successfully called
      // with a context object that includes top-level text nodes. However, to
      // give developers full control of the HTML appearing in the page, and to
      // enable Ajax content to be inserted in places where DIV elements are not
      // allowed (e.g., within TABLE, TR, and SPAN parents), we check if the new
      // content satisfies the requirement of a single top-level element, and
      // only use the container DIV created above when it doesn't. For more
      // information, please see http://drupal.org/node/736066.
      if (new_content.length !== 1 || new_content.get(0).nodeType !== 1) {
        new_content = new_content_wrapped;
      }

There are multiple conditions where even the more limited DIV wrapping creates problems (see comments #41-#48).

Proposed resolution

Figure out if we can improve ajax.js to never require the DIV wrapper. Specifically:

// For legacy reasons, the effects processing code assumes that new_content
// consists of a single top-level element.

Can we fix that?

// Also, it has not been
// sufficiently tested whether attachBehaviors() can be successfully called
// with a context object that includes top-level text nodes.

Can we test/fix that?

Remaining tasks

User interface changes

API changes

Original report by @peterpoe

As a workaround for a Safari bug, ajax.js wraps new content inside an empty div after a successful ajax request:

    // Manually insert HTML into the jQuery object, using $() directly crashes
    // Safari with long string lengths. http://dev.jquery.com/ticket/3178
    var new_content = $('<div></div>').html(response.data);

The div makes inserting content not at block level (like in table rows and spans), difficult to achieve. I have published a workaround for Drupal 6 here: http://drupal.org/node/472328

Since the corresponding bug has been solved in Safari since 2009-03-19, I think that both Safari 3.2.3 and 4.x won't crash anymore with long strings. Given that Safari 3 has is used by 0.3% of web users, my opinion is that the limitations posed by the workaround are now worse than the problem solved.

Attached patch changes the behavior to:

    var new_content = $(response.data);

Following a password reset link while logged in leaves users unable to change their password

$
0
0

Problem/Motivation

As things stand, the user edit form requests the current password to change the password. EXCEPT if there is a special value set in the session.
This is what the password reset link does when you follow it: it sets the special session token for 'don't ask current password'.

Detail

Steps to reproduce:

  1. Log off if necessary
  2. Request a new password
  3. Log back in with the old password [a]
  4. On receiving the password reset email, click on that link to log on [b]
  5. You are taken to the home page of the site, with a message "You are logged in as USERNAME. [LINK]Change your password[/LINK].
  6. Following the link takes you to the user edit form, which requires the current password if you enter a new one

Note that this requires 2 steps which don't seem terribly logical on the part of the user:

[a] Why would you request a new password, and then log in?
[b] Having logged in again, why would you click the link in the email?

Possible explanations include:

* the user was on the wrong machine or the wrong browser, and then remembered to switch to something that has their password stored.
* the user simply remembered it after requesting the reset
* the user is currently logged in, but is aware that they have forgotten their password, and wishes to reset it, and therefore goes to the site in a 2nd browser to get a password reset email sent to them, because that's the only way they know to reset their password without knowing the existing one.

Proposed resolution

add this token when user follows the password reset link AND they are logged in.

Remaining tasks

  • Fix error (See #58 and #67
  • manually test (once there is a new patch)
  • add automated tests? (is this possible?)
  • review 8.0.x
  • commit 8.0.x
  • backport to d7

User interface changes

A message when click the link.

API changes

No.

Extension System, Part III: ExtensionList/ExtensionHandler

$
0
0
  1. The "list" of extensions defines the list of enabled/installed extensions.
  2. There is a list for each extension type: profile, module, theme, theme_engine.
  3. The installation profile

    1. is defined as $settings['install_profile'] in settings.php (but only its name)
    2. is added to the list of enabled modules with a weight of 1000 in drupal_rebuild_module_data()
    3. is contained in the %container.modules% parameter on the service container

    There is a second"parent" installation profile when a test is executed, which

    1. is defined as $config['simpletest.settings']['parent_profile'] in config/settings.php (only its name)
    2. is NOT added to the list of enabled modules
    3. is NOT contained in the %container.modules% parameter of the service container
    4. is only used by ExtensionDiscovery to additionally find extensions in the parent installation profile, from which tests were executed.
  4. The list of enabled modules

    1. is maintained by ModuleHandler::install() and ModuleHandler::uninstall()
    2. is stored in the core.extension configuration object
    3. is contained in the %container.modules% parameter on the service container
    4. can be manipulated at runtime (without touching configuration) via ModuleHandler::setModuleList()
    5. is consumed by system_rebuild_module_data() to enhance module info with a $status property reflecting the installation status

    Aside from that and the system_rebuild_module_data() aspect, management and maintenance of the module list is pretty clean already.

  5. The list of enabled themes

    1. is maintained by ThemeHandler::install() and ThemeHandler::uninstall()
    2. is stored in the core.extension configuration object
    3. is consumed, enhanced with theme info, and cached by system_list()
    4. is consumed by system_rebuild_theme_data() to enhance theme info with a $status property reflecting the status (whereas there is no installation status yet)

    Except of the core.extension:theme configuration, this list factually does not really exist on its own right now — it is deeply intertwined with theme info currently.

    The list is also not stored in an efficient way like the %container.modules% parameter on the service container; i.e., the system always has to consult the configuration system to retrieve it.

  6. The list of theme engines

    1. does not exist at all.

    ThemeHandler::rebuildThemeData() blatantly performs an ExtensionDiscovery to simply retrieve all available engines.

Proposed solution

  1. Provide a common way to list extensions (enabled and not enabled ones)

    → Central data source for ExtensionList (ModuleExtensionList, ThemeExtensionList, ...)

  2. → Provide common methods for e.g. resolving dependencies

    → Use it directly for profiles and theme engines.

  3. Try to untangle at least some of the theme list/data/info mess.

<span class="ajax-new-content" style="display:inline-block;"> causes unwanted whitespace

Possible access bypass for rendered links

$
0
0

I wanted to remove the input format tips link from the TextFormat form element and so I have disabled access to the filter.tips and filter.tips_all routes via event subscriber by setting the requirements to ['_access' => 'FALSE'].

This works just fine, when I visit the /filter/tips I will get proper 404. But the issue is that the link itself is still visible. I was checking if the access method on the Url object works and it does so the bug is somewhere else. And I found out that in the LinkGenerator::generate() method there is no access check for routed Urls.

By catch's recommendation I am attaching this simple patch that fixes this bug(ie. the link has disappeard) to see what the test bot will have to say.

PHP warning on install: headers already sent

$
0
0

This error occurs during installation:

Warning: Cannot modify header information - headers already sent by (output started at /home/davp/www/core/vendor/symfony/http-foundation/Symfony/Component/HttpFoundation/Response.php:1255) in Drupal\Core\Session\SessionManager-&gt;destroy() (line 267 of /home/davp/www/core/lib/Drupal/Core/Session/SessionManager.php).

Screenshot attached.


Include .gitattributes file in list of core files to move in INSTALL.txt instructions

$
0
0

Problem/Motivation

In the INSTALL.txt file that ships with D8 core, there is a command given for moving core files from the download directory to the web server's document root:
mv drupal-x.y.z/* drupal-x.y.z/.htaccess drupal-x.y.z/.csslintrc drupal-x.y.z/.editorconfig drupal-x.y.z/.eslintignore drupal-x.y.z/.eslintrc /path/to/your/installation

This command misses the drupal-x.y.z/.gitattributes file.

Proposed resolution

Include the drupal-x.y.z/.gitattributes file in the list of files to mv.

Remaining tasks

Confirm that the .gitattributes file should be included in the mv command, review and commit.

The SQLite database driver fails to drop simpletest tables

$
0
0

Problem/Motivation

Drupal creates a new SQLite database file for each simpletest test case but it fails to delete them at the end of the test.

Proposed resolution

Make \Drupal\Core\Database\Schema::findTables() use unprefixed tables as an argument and for the return value.

Remaining tasks

None.

User interface changes

Nope.

API changes

\Drupal\Core\Database\Schema::findTables() works with prefixed tables by default.

Data model changes

Nope.

ContextInterface needs documentation

$
0
0

Problem/Motivation

<?php
/**
 * Interface for context.
 */
interface ContextInterface extends ComponentContextInterface {
?>

Proposed resolution

?

Remaining tasks

Write something.

User interface changes

API changes

Theme suggestions may not be in theme include files, Search and Views UI suggestions are not (always) found

$
0
0

Problem/Motivation

Theme suggestions of search result suggestions (theme hook: search_result) and views ui preview section suggestions (theme hook: views_ui_view_preview_section) are not always found.

That's because they are in a theme include file, which is not allowed for implementations of hook_theme_suggestions_HOOK() and related hooks. If the file happens to be included previously, it will get picked up but this is coincidental.

Proposed resolution

  1. Move search_theme_suggestions_search_result() to search.module
  2. Move views_ui_theme_suggestions_views_ui_view_preview_section() to views_ui.module
  3. Add docs to hook_theme_suggestions_HOOK(), hook_theme_suggestions_alter(), and hook_theme_suggestions_HOOK_alter() to mention that implementations must be placed in *.module files.

Note that because code cannot be unloaded, it is not possible to write tests for this.

Remaining tasks

Contributor tasks needed
TaskNovice task?Contributor instructionsComplete?
Create a patchInstructions
Review patch to ensure that it fixes the issue, stays within scope, is properly documented, and follows coding standardsInstructions

User interface changes

None.

API changes

None.

Data model changes

None.

.htaccess protections do not work on Apache 2.4 without mod_access_compat

$
0
0

In Apache 2.4, the "Order" becomes deprecated

With Apache 2.4 the old Order get's deprecated in favor of Require.

If hosters by default have Access compat, then Order keeps working. Otherwise however, with our current .htaccess Apache 2.4 will not start after installing Drupal.

I tried to figure out a way to check which the current version of Apache is, but unfortunately IfVersion is only available in 2.4, so that will break 2.2. My stackoverflow question hasn't yielded anything that we can use yet. I asked on IRC, and got two suggestions.

  • Ship two files, one < 2.4 and one >= 2.4. Pick one during install. Not sure how feasable that is for us.
  • Find modules that are unique and frequently enabled in the different environments, and do IfModule on those to determine where we are. This seems like a total hack to be honest, but may actually be the best way to go if we can identify a reliable set of modules.
Viewing all 303526 articles
Browse latest View live


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