Problem/Motivation

When the string in question has an invalid placeholder, placeholderFormat() throws an E_USER_ERROR, which according to the PHP docs behaves like E_ERROR and is a "fatal" error.

<?php
          // We do not trigger an error for placeholder that start with an
          // alphabetic character.
          if (!ctype_alpha($key[0])) {
            // We trigger an error as we may want to introduce new placeholders
            // in the future without breaking backward compatibility.
            trigger_error('Invalid placeholder (' . $key . ') in string: ' . $string, E_USER_ERROR);
          }
?>

In my case, the error was killing the script execution, which seems unnecessary. Are these errors really "fatal"? Won't they simply result in strings that aren't correctly rendered? I marked as "major" because it seems in some cases a minor coding mistake could result in lost data, etc. due to script abortion.

To repeat

I haven't been able to reliably reproduce it yet. In my case, the chain appears to start in devel_module.php, backtrace_error_handler().

Backtrace:

Proposed resolution

Change to E_USER_WARNING instead of E_USER_ERROR:

<?php
          // We do not trigger an error for placeholder that start with an
          // alphabetic character.
          if (!ctype_alpha($key[0])) {
            // We trigger an error as we may want to introduce new placeholders
            // in the future without breaking backward compatibility.
            trigger_error('Invalid placeholder (' . $key . ') in string: ' . $string, E_USER_WARNING);
          }
?>

I am having lots for trouble with updating Modules. I have been using Drupal for 6 months and think it is great. I am running Drupal 7.41 on two different WAMP servers and I keep getting the messages: There was a problem checking available updates for Drupal. See the available updates page for more information and to install your missing updates.
There was a problem checking available updates for your modules or themes. See the available updates page for more information and to install your missing updates.
One WAMP Server is using cygwin and the the other is using GNUWin32
I have installed DRUSH on both computers and when I run Drush Core-Requirements I get the following

Module and theme Warning Failed to get available update data.

update status There was a problem checking available

updates for your modules or themes. See the

available updates page for more information.

Drupal core update Warning Failed to get available update data.

status There was a problem checking available

updates for Drupal. See the available

updates page for more information.

Web server Info

When I run Drush Updatestatus I get the following:

Name Installed Proposed Message
Version version
Address Field (addressfield) 7.x-1.0 7.x-1.0 Unknown
Advanced help (advanced_help) 7.x-1.2 7.x-1.2 Unknown
Drupal 7.41 7.41 Unknown
Backup and Migrate (backup_migrate) 7.x-3.0 7.x-3.0 Unknown
Calendar (calendar) 7.x-3.5 7.x-3.5 Unknown
Chaos tools (ctools) 7.x-1.7 7.x-1.7 Unknown
Date (date) 7.x-2.8 7.x-2.8 Unknown
DrupalChat (drupalchat) 7.x-1.7 7.x-1.7 Unknown
Display Suite (ds) 7.x-2.8 7.x-2.8 Unknown
Media (media) 7.x-1.5 7.x-1.5 Unknown
IMCE (imce) 7.x-1.9 7.x-1.9 Unknown
IMCE Wysiwyg API bridge 7.x-1.0 7.x-1.0 Unknown
(imce_wysiwyg)
Libraries (libraries) 7.x-2.2 7.x-2.2 Unknown
Link (link) 7.x-1.3 7.x-1.3 Unknown
Media: oEmbed (media_oembed) 7.x-2.3 7.x-2.3 Unknown
Media: YouTube (media_youtube) 7.x-2.0-rc5 7.x-2.0-rc5 Unknown
Panels (panels) 7.x-3.5 7.x-3.5 Unknown
Pathauto (pathauto) 7.x-1.2 7.x-1.2 Unknown
Token (token) 7.x-1.6 7.x-1.6 Unknown
Views (views) 7.x-3.10 7.x-3.10 Unknown
Views Slideshow (views_slideshow) 7.x-3.1 7.x-3.1 Unknown
Webform (webform) 7.x-4.8 7.x-4.8 Unknown
Wysiwyg (wysiwyg) 7.x-2.2 7.x-2.2 Unknown
Marinelli (marinelli) 7.x-3.0-beta11 7.x-3.0-beta11 Unknown

C:\wamp\www\drupal-7.36\sites\default>
I thought the issue might have been related to McAfee Anti Virus but I get the same problems when I disable it.
Thank you very much.

Problem/Motivation

On the uninstall modules form, a module with existing fields displays "Fields type(s) in use" as the reason it cannot be uninstalled. Besides not making much sense, this message does not help the admin with any specifics.

Currently:

Proposed resolution

Rewrite the message and state which fields are involved.

Remaining tasks

User interface changes

API changes

Data model changes

Original Report

The comment module can not be disabled. At first it said it was because of a an existing Field. I found the field in Article and deleted it. Now it simply lists the 2 modules that depend on comments and has them both marked as disabled but won't allow me to disable comment.

Problem/Motivation

When we redesigned the place block UI, we changed where blocks live before they are placed in a region. On a standard install, the disabled region is now empty.

In the usability study we observed some users looking for blocks in this region, likely due to previous experience with the Drupal 7 UI.

Proposed resolution

Remove the 'disabled' region
Replace with a 'disabled' block state, so the blocks stay in the region they are, but are visually styled to be disabled.

Remaining tasks

Write an upgrade path
Write tests for the upgrade path
Write the beta evaluation

User interface changes

Remove the 'disabled' region
Replace with a 'disabled' block state, so the blocks stay in the region they are, but are visually styled to be disabled.

API changes

None

Data model changes

None

Problem/Motivation

POSTing to ie /entity/node with empty header/content gives or wrong header gives no clue about what was send.

The admin/reports/dblog shows an exception but the REST client is not informed except for a "415 Unsupported Media Type" response

No route found that matches the Content-Type header

How to test

Proposed resolution

Remaining tasks

User interface changes

API changes

Nginx is widely used and recommended by many Drupallers. There is sufficient documentation available on d.o for it. Let's add it to INSTALL.txt

Problem/Motivation

When a page contains a collapsible fieldset element, such that $('fieldset.collapsible') contains elements, and a fragment with special characters is in the url, such as http://mysite.com/#badfragment=broken, a javascript error will be thrown: Uncaught Error: Syntax error, unrecognized expression: .error, #badfragment=broken.

This issue happens in collapse.js near line 63:

Notice that the anchor is being directly pulled from the URL and used in the selector. However, '.error' + anchor will not yield a valid selector, resulting in an error being thrown (breaking all JS on the page).

Proposed resolution

Not sure the best way to fix this. Ideally, the fragment for collapsed fieldsets would be namespaced in the URL so that it wasn't pulling ANYTHING that is a fragment. So perhaps have it look for #collapsed=NAME_OF_ELEMENT.
A simpler/quicker fix would be to check if the selector is valid, or do some regex replacement on special (invalid selector) characters.

The documentation for hook_node_access() does not reflect what is in the current code.

The enforcement of create access has moved to hook_ENTITY_TYPE_create_access(). Node module doesn't use node_node_access() for permissions, instead using NodeAccessControlHandler::checkCreateAccess().

This patch:

• Updates the documentation of hook_node_access().
• Updates the documentation of node_node_access().
• Adds a negative test case to NodeCreationTest to ensure that create access permissions are handled securely.

Problem/Motivation

Moving modules into contrib/custom after install doesn't seem to work. According to the documentation, all one has to do if one wants to move modules into a custom or contrib directory structure is mv the directory, and clear the cache. This does not work. In fact uninstalling a module, and installing it in one of these directories doesn't work.

Proposed resolution

Ultimately fix this if it can be fixed, but presently updating the documentation would help alleviate the 'oh crap' feeling of a broken site.

Remaining tasks

User interface changes

API changes

Data model changes

In core/modules/system/tests/modules/form_test/form_test.routing.yml, how is it possible that these invalid route definitions (use of controller: with no underscore instead of _controller:) don't cause test failures when form_test is used in general and when the autocomplete test is performed in particular?

Problem/Motivation

The fluid experience in well-written single-page applications today far exceeds what Drupal’s admin layer provides. Thanks to the adoption of Backbone, parts of core already have this type of behavior, but many now consider Backbone obsolete. We need to accelerate the pace of these improvements to match users’ growing expectations. For example, it is no longer acceptable to experience a full page refresh when deleting a node or applying filters to searches of content. It is also extremely important that when performing any action, users get immediate feedback (or even optimistic feedback, in which the user sees the result even before getting a response from the server from their action, e.g. liking a Facebook post triggers an instantaneous response).

The purpose of this issue is to select a client-side framework (e.g. Angular, Ember, Knockout), library (e.g. React), or compile-to-JavaScript project (e.g. Elm, ClojureScript) that would help us build next-generation admin UIs.

Some suggest Drupal should evolve into an API-first CMS that supplies JSON and not full page builds (fully decoupled). This would render many admin UIs irrelevant, low-level functionality like localization would become more complicated or need reinventing, and many new performance improvements (like BigPipe) would become inaccessible. As such, Dries proposed a new paradigm called progressive decoupling, which advances UX without a corresponding loss of key Drupal functionality by providing an initial application state through the Drupal page render before transferring responsibility over parts of the page to a client-side framework:

• The future of decoupled Drupal
• Should we decouple Drupal with a client-side framework?
• Selecting a client-side framework for Drupal

Why adopt a framework? Application-like UIs in Drupal (e.g. Views UI and block placement) would benefit from a standard framework to enable a fluid experience. Over time, developers of modules with complex UIs are gravitating to frameworks to enable this type of functionality. A single site build should not have to leverage multiple frameworks for performance and maintainability reasons. Adopting a framework with a better front-end developer experience would also attract new front-end contributors to Drupal.

Where would we begin? Lightweight proofs of concept will be required to determine the best path forward. These should be built with the assumption that initially, Twig-based and JavaScript-based UIs coexist on the page. Over time increasing amounts of the overall page may become JavaScript-driven.

How would we do it? Dries offers some interesting possible options for adopting a client-side framework in his second blog post concerning decoupled Drupal. But there are also some important architectural questions in need of answering, including, for instance, whether shared templates across client and server could be feasible and whether the render pipeline would need to be refactored to accommodate JavaScript-based templates.

Proposed resolution

Key Drupal core contributors have teamed up with experts on important client-side frameworks (including Angular 2, Ember, and Elm) to produce a comparison matrix to help determine what framework would be most appropriate for Drupal core. The matrix assesses Angular 2, Ember, React, Elm, and a few less promising frameworks: Backbone, Angular 1 and Knockout.

This is a good start, but it is nowhere near comprehensive. We need your help with the following questions:

• Are these the correct criteria with which to evaluate client-side frameworks (for progressive decoupling)?
• Are there other frameworks that meet our minimum criteria?
• Are the conclusions we’ve made about these criteria appropriate?

Remaining tasks

• Agree on criteria for selecting a JavaScript framework well-suited to progressive decoupling in order to create a shortlist.
• Develop proofs of concept that show the right framework for the job of controlling Drupal’s admin UIs while still preserving key functionality (e.g. Drupal configuration, themes, and localization).
• Determine when / in which Drupal version (8.1? 8.2? 9.0?) to add the framework. Note that core code can’t leverage the framework until the framework is in core.
• Reach out to framework maintainers to resolve any considerations around licensing, release cadence, and inter-project cooperation.
• Draft a change notice similar to that created for Backbone adoption.

User interface changes

Leveraging the chosen framework to improve core UIs would be separate follow-up issues.

API changes

None.

Data model changes

TBD, but likely none.

Problem/Motivation

For some time we've been talking about moving away from preprocess - via Twig autoescape and other things. This didn't really happen to the extent people hoped during the 8.x cycle though.

So at this point we have a lot of preprocess implementations, and a lot of templates relying on variables prepared by them.

We can't remove preprocess in 8.x, and we can't make variables that were previously available to templates unavailable.

However, we can potentially rationalize specific preprocess implementations, deprecate the use of particular variables etc.

template_preprocess() gets called for every single template render, to generate exactly the same variables to pass in - this would be a good candidate to remove.

Additionally we may be able to define twig variables as objects for other things, so that they're used on demand in the template, rather than always generating strings in preprocess as we currently do. Something like node $submitted would be a good candidate for that.

Proposed resolution

Replace the variables added by template_preprocess() with Twig global variables: http://symfony.com/doc/current/cookbook/templating/global_variables.html

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

It's easy for a Logger implementation to run code that may want to log a message, leading to infinite recursion.

Proposed resolution

To prevent infinite recursion we should track the call depth and bail out.

Remaining tasks

Tests
Reviews
Commit

User interface changes

None

API changes

To prevent infinite recursion, we track the call depth and bail out at LoggerChannel::MAX_CALL_DEPTH iterations.

Data model changes

None

Original report by @beejeebus

i just found out it's easy for a Logger implementation to run code that may want to log a message, leading to infinite recursion.

here's a rough cut patch that prevents too many recursive calls.

The docblocks in file core/modules/views/src/ViewExecutable.php need some TLC.

The docblock short summary lines are inconsistent. Some do not start with verbs. Some go beyond one line. Some that start with verbs do not use the active case. These all need to be fixed. There also appears to be a number of @param and @return directives that are missing.

There is no link to remove a node from a book anywhere in the admin UI.

To reproduce:
- With Node and Book modules enabled, create a node and add it to a book.
- Click on the 'Outline' tab.
Expected: The action buttons on the form should read 'Update book outline' and 'Remove from book outline'.
Observed: Instead, the action buttons are 'Update book outline' and 'Delete'.

- Click 'Delete'
Expected: Browser redirected to node/*/outline/remove, user asked to confirm removing the node from the book.
Observed: Browser redirected to node/*/delete, user asked to confirm deleting the node.

BookOutlineForm is a subclass of EntityForm, which had its Delete button turned into a link as part of #216064: Entity form "Delete" button triggers server-side + HTML5 form validation; change "Delete" button to a link. This changed the underlying form structure out from under BookOutlineForm::actions(), which hasn't been updated since #1938316: Convert book_outline to a new-style Controller. node/*/outline/remove still exists, and still works, but there's no link to it.

Patch incoming.

We're buidling our first D8 site. I'm finding it to be buggy, but I guess that's to be expected.

One nasty bug in particular has cropped up.

I've built a contextual Views Block. This will seem silly, but my contextual views block renders the title of the node, and an image field of the node. I've placed it in the Breadcrumbs region, and I've disabled the regular node title block. So essnentially, this contextual views block is replacing the regular title block. It renders the node title over an image.

HOWEVER, while I'm working on the site, that block will disappear. I do now know if its tied to me making a change in Views, or a change to nodes. Something is happening, and the block just stops rendering. I can usually get it to reappear by flushing caches, or by making an edit to the node it has disappeared on.

This is not critical while in development, but I cannot launch this site into Production with this bug. The client will randomly lose their Views block with the title and not realize it.

If there is way to fix this, please let me know. Otherwise, please consider this a major bug and look into a fix as soon as possible.

Problem/Motivation

Problem: On the view edit screen, in the preview section, displaying a view with an attachment shows the results and the attachment results. If values are entered into an exposed filter and the Apply button clicked, the results are updated, the the attachment results are not. Saving the view and using the page display works as expected, both the results and the attachment update with changes to the exposed filter.

I've been going crazy trying to figure out why a view I had that used exposed filters wouldn't pass the values of the exposed filter to an attachment. Then when trying to build a demonstration for this issue, I tried saving the view and looking at the page it generates and the exposed filters work fine and update the attachment. I then tried it on the view I originally observed the issue on and sure enough, preview doesn't update the attachment, but saving the view and looking at the page does work. The attached configuration is from a clean install on simplytest.me with just core and devel (to generate content).

Proposed resolution

I'm not sure why the preview isn't updating the attachment with the exposed filter values.

Remaining tasks

User interface changes

API changes

Data model changes

In #2082499: Uninstalling action module removes actions created by the user module we're renaming all the config files system.action.machine_name since

everything still works when it is disabled/uninstalled

and remvoing all the config files cause heaps of problems :)

This module is just providing a UI in the same way as views_ui and field_ui.

When trying to install D8 on WAMP I get this error.

"Drupal\Core\Config\UnmetDependenciesException: Configuration objects (block.block.bartik_search, core.entity_form_display.node.article.default, core.entity_form_display.node.page.default, rdf.mapping.comment.comment, rdf.mapping.node.article, rdf.mapping.node.page, rdf.mapping.taxonomy_term.tags) provided by standard have unmet dependencies in Drupal\Core\Config\UnmetDependenciesException::create() (line 89 of core\lib\Drupal\Core\Config\UnmetDependenciesException.php).
Drupal\Core\Config\UnmetDependenciesException::create('standard', Array)
Drupal\Core\Config\ConfigInstaller->checkConfigurationToInstall('module', 'standard')
Drupal\Core\Extension\ModuleInstaller->install(Array, )
install_install_profile(Array)
install_run_task(Array, Array)
install_run_tasks(Array)
install_drupal(Object)"

I am running Apache and PHP 5.5.12

Problem/Motivation

#2418017: Implement autocomplete UI for the link widget implemented the 'entity_autocomplete' form element in LinkWidget but hardcoded the target type to 'node'.

Proposed resolution

We should expose the target type, selection handler and selection settings as widget settings in LinkWidget.

Remaining tasks

Do it.

User interface changes

Three new elements will be exposed in Field UI for the default link widget.

API changes

Nope.