Problem/Motivation

\Drupal\language\ConfigurableLanguageManager::getConfigOverrideLanguage() returns NULL if \Drupal\language\Config\LanguageConfigFactoryOverride::setLanguage() or ::setLanguageFromDefault() were not called before. This violates the interface both those classes implement.

Steps to reproduce

(not properly yet, as the fatal occurs in a contrib module doing weird things)

• Enable more than one language
• Generate a bunch of content
• drush search-reindex -y; drush search-index

Detailed backtrace:

Call Stack:
    0.0050     228784   1. {main}() /Users/dawehner/.composer/vendor/drush/drush/drush.php:0
    0.0712     402520   2. drush_main() /Users/dawehner/.composer/vendor/drush/drush/drush.php:12
    0.4679    9603376   3. Drush\Boot\BaseBoot->bootstrap_and_dispatch() /Users/dawehner/.composer/vendor/drush/drush/includes/preflight.inc:68
    0.8950   26225488   4. drush_dispatch(???, ???) /Users/dawehner/.composer/vendor/drush/drush/lib/Drush/Boot/BaseBoot.php:72
    1.3679   30938704   5. call_user_func_array:{/Users/dawehner/.composer/vendor/drush/drush/includes/command.inc:185}(???, ???) /Users/dawehner/.composer/vendor/drush/drush/includes/command.inc:185
    1.3679   30939224   6. drush_command(???) /Users/dawehner/.composer/vendor/drush/drush/includes/command.inc:185
    1.3692   30944016   7. _drush_invoke_hooks(???, ???) /Users/dawehner/.composer/vendor/drush/drush/includes/command.inc:217
    1.3714   30989784   8. call_user_func_array:{/Users/dawehner/.composer/vendor/drush/drush/includes/command.inc:366}(???, ???) /Users/dawehner/.composer/vendor/drush/drush/includes/command.inc:366
    1.3714   30990120   9. drush_core_php_eval(???) /Users/dawehner/.composer/vendor/drush/drush/includes/command.inc:366
    1.3715   30991568  10. eval('drush_module_invoke('search', 'cron');;') /Users/dawehner/.composer/vendor/drush/drush/commands/core/core.drush.inc:1160
    1.3716   30991784  11. drush_module_invoke(???, ???) /Users/dawehner/.composer/vendor/drush/drush/commands/core/core.drush.inc(1160) : eval()'d code:1
    1.3716   30992040  12. Drupal\Core\Extension\ModuleHandler->invoke(???, ???, ???) /Users/dawehner/.composer/vendor/drush/drush/commands/core/drupal/environment.inc:241
    1.3716   30992256  13. call_user_func_array:{/Users/dawehner/Documents/c3/client/docroot/core/lib/Drupal/Core/Extension/ModuleHandler.php:391}(???, ???) /Users/dawehner/Documents/c3/client/docroot/core/lib/Drupal/Core/Extension/ModuleHandler.php:391
    1.3716   30992512  14. search_cron() /Users/dawehner/Documents/c3/client/docroot/core/lib/Drupal/Core/Extension/ModuleHandler.php:391
    1.4674   34214296  15. Drupal\node\Plugin\Search\NodeSearch->updateIndex() /Users/dawehner/Documents/c3/client/docroot/core/modules/search/search.module:195
    1.4931   37041040  16. Drupal\node\Plugin\Search\NodeSearch->indexNode(???) /Users/dawehner/Documents/c3/client/docroot/core/modules/node/src/Plugin/Search/NodeSearch.php:450
    1.5068   37819384  17. Drupal\Core\Render\Renderer->renderPlain(???) /Users/dawehner/Documents/c3/client/docroot/core/modules/node/src/Plugin/Search/NodeSearch.php:478
    1.5074   37838024  18. Drupal\Core\Render\Renderer->executeInRenderContext(???, ???) /Users/dawehner/Documents/c3/client/docroot/core/lib/Drupal/Core/Render/Renderer.php:152
    1.5074   37838480  19. Drupal\Core\Render\Renderer->Drupal\Core\Render\{closure}() /Users/dawehner/Documents/c3/client/docroot/core/lib/Drupal/Core/Render/Renderer.php:572
    1.5074   37838592  20. Drupal\Core\Render\Renderer->render(???, ???) /Users/dawehner/Documents/c3/client/docroot/core/lib/Drupal/Core/Render/Renderer.php:151
    1.5074   37839984  21. Drupal\Core\Render\Renderer->doRender(???, ???) /Users/dawehner/Documents/c3/client/docroot/core/lib/Drupal/Core/Render/Renderer.php:195
    1.5097   37888272  22. call_user_func:{/Users/dawehner/Documents/c3/client/docroot/core/lib/Drupal/Core/Render/Renderer.php:379}(???, ???) /Users/dawehner/Documents/c3/client/docroot/core/lib/Drupal/Core/Render/Renderer.php:379
    1.5097   37888336  23. Drupal\Core\Entity\EntityViewBuilder->build(???) /Users/dawehner/Documents/c3/client/docroot/core/lib/Drupal/Core/Render/Renderer.php:379
    1.5097   37888896  24. Drupal\Core\Entity\EntityViewBuilder->buildMultiple(???) /Users/dawehner/Documents/c3/client/docroot/core/lib/Drupal/Core/Entity/EntityViewBuilder.php:203
    1.5658   40563104  25. Drupal\node\NodeViewBuilder->buildComponents(???, ???, ???, ???) /Users/dawehner/Documents/c3/client/docroot/core/lib/Drupal/Core/Entity/EntityViewBuilder.php:246
    1.5658   40563280  26. Drupal\Core\Entity\EntityViewBuilder->buildComponents(???, ???, ???, ???) /Users/dawehner/Documents/c3/client/docroot/core/modules/node/src/NodeViewBuilder.php:24
    1.6254   44300560  27. Drupal\Core\Entity\Entity\EntityViewDisplay->buildMultiple(???) /Users/dawehner/Documents/c3/client/docroot/core/lib/Drupal/Core/Entity/EntityViewBuilder.php:303
    1.6525   45229264  28. Drupal\Core\Field\FormatterBase->view(???, ???) /Users/dawehner/Documents/c3/client/docroot/core/lib/Drupal/Core/Entity/Entity/EntityViewDisplay.php:259
    1.6526   45229320  29. Drupal\address\Plugin\Field\FieldFormatter\AddressDefaultFormatter->viewElements(???, ???) /Users/dawehner/Documents/c3/client/docroot/core/lib/Drupal/Core/Field/FormatterBase.php:80
    1.6526   45232944  30. Drupal\address\Plugin\Field\FieldFormatter\AddressDefaultFormatter->viewElement(???, ???) /Users/dawehner/Documents/c3/client/docroot/modules/contrib/address/src/Plugin/Field/FieldFormatter/AddressDefaultFormatter.php:129
   12.6373   45536224  31. Drupal\address\Plugin\Field\FieldFormatter\AddressDefaultFormatter->getValues(???, ???) /Users/dawehner/Documents/c3/client/docroot/modules/contrib/address/src/Plugin/Field/FieldFormatter/AddressDefaultFormatter.php:150
   12.6495   45851376  32. CommerceGuys\Addressing\Model\Subdivision->hasChildren() /Users/dawehner/Documents/c3/client/docroot/modules/contrib/address/src/Plugin/Field/FieldFormatter/AddressDefaultFormatter.php:281
   12.6495   45851440  33. Doctrine\Common\Collections\AbstractLazyCollection->isEmpty() /Users/dawehner/Documents/c3/client/docroot/vendor/commerceguys/addressing/src/Model/Subdivision.php:241
   12.6495   45851512  34. Doctrine\Common\Collections\AbstractLazyCollection->initialize() /Users/dawehner/Documents/c3/client/docroot/vendor/doctrine/collections/lib/Doctrine/Common/Collections/AbstractLazyCollection.php:85
   12.6495   45851632  35. CommerceGuys\Addressing\Collection\LazySubdivisionCollection->doInitialize() /Users/dawehner/Documents/c3/client/docroot/vendor/doctrine/collections/lib/Doctrine/Common/Collections/AbstractLazyCollection.php:332
   12.6495   45851720  36. CommerceGuys\Addressing\Repository\SubdivisionRepository->getAll(???, ???, ???) /Users/dawehner/Documents/c3/client/docroot/vendor/commerceguys/addressing/src/Collection/LazySubdivisionCollection.php:62
   12.6501   45899656  37. CommerceGuys\Addressing\Repository\SubdivisionRepository->createSubdivisionFromDefinitions(???, ???, ???) /Users/dawehner/Documents/c3/client/docroot/vendor/commerceguys/addressing/src/Repository/SubdivisionRepository.php:94
   12.6502   45900616  38. CommerceGuys\Addressing\Repository\SubdivisionRepository->get(???, ???) /Users/dawehner/Documents/c3/client/docroot/vendor/commerceguys/addressing/src/Repository/SubdivisionRepository.php:228
   12.6502   45901096  39. CommerceGuys\Addressing\Repository\SubdivisionRepository->createSubdivisionFromDefinitions(???, ???, ???) /Users/dawehner/Documents/c3/client/docroot/vendor/commerceguys/addressing/src/Repository/SubdivisionRepository.php:79
   12.6502   45901096  40. CommerceGuys\Addressing\Repository\SubdivisionRepository->translateDefinition(???, ???) /Users/dawehner/Documents/c3/client/docroot/vendor/commerceguys/addressing/src/Repository/SubdivisionRepository.php:214
   12.6502   45901160  41. Drupal\address\Repository\SubdivisionRepository->getDefaultLocale() /Users/dawehner/Documents/c3/client/docroot/vendor/commerceguys/addressing/src/Repository/DefinitionTranslatorTrait.php:21

Proposed resolution

To be determined.

Remaining tasks

To be determined.

User interface changes

None.

API changes

To be determined.

Data model changes

To be determined.

When #states is attached to a form element that contains #markup the following notice occurs:

Notice: Undefined index: #type in drupal_process_states() (line 583 of core/includes/common.inc).

This happens because a #markup element does not require the #type to be set.

Problem/Motivation

To use cachetags on a Drupal 8 site, you need to add http.response.debug_cacheability_headers: true to services.yml. Everything is in a name, and for me cachetags are not a debug setting, it is a feature, so it should be named in a way that describes what it is.

Proposed solution

My suggestion is to rename http.response.debug_cacheability_headers to http.response.enable_cacheability_headers, HttpResponseDebugCacheability to HttpResponseEnableCacheabilityHeaders.

Problem/Motivation

Some Entities for some reason cause PDO Exceptions, this looks to be related to the user_module function user_roles and the session_api
For me this happens with node and comment entities. However, there have been several issues posted for the same issue with other entity types being fixed by some work arounds like enabling/disabling/feature rebuilding/standing on head.

I currently do not have a workaround.

Full Error

Additional uncaught exception thrown while handling exception.

Original

PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT r.rid AS rid, r.name AS name FROM {role} r ORDER BY weight ASC, name ASC; Array ( ) in user_roles() (line 2923 of /modules/user/user.module).

Additional

PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT ff.* FROM {filter_format} ff WHERE (status = :db_condition_placeholder_0) ORDER BY weight ASC; Array ( [:db_condition_placeholder_0] => 1 ) in filter_formats() (line 426 of /modules/filter/filter.module).

Uncaught exception thrown in session handler.

PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT 1 AS expression FROM {sessions} sessions WHERE ( (sid = :db_condition_placeholder_0) AND (ssid = :db_condition_placeholder_1) ); Array ( [:db_condition_placeholder_0] => -F2LoaJZu994OC_EaM2-zo18NfBquFs9Lr29R2biF14 [:db_condition_placeholder_1] => ) in _drupal_session_write() (line 209 of /includes/session.inc).

Proposed resolution

Still debugging

Remaining tasks

Debug

This file contains several functions which are marked as deprecated. The documentation tells you what you should use instead.

However, the thing the documentation tells you to use instead is *itself* deprecated! This needs to be fixed, so the advice is correct and up to date.

eg in entity_view()

 * @return array
 *   A render array for the entity.
 *
 * @deprecated as of Drupal 8.0.x, will be removed before Drupal 9.0.0.
 *   Use the entity view builder's view() method for creating a render array:
 * @code
 * $view_builder = \Drupal::entityManager()->getViewBuilder($entity->getEntityTypeId());
 * return $view_builder->view($entity, $view_mode, $langcode);
 * @endcode
 *
 * @see \Drupal\Core\Entity\EntityManagerInterface::getViewBuilder()
 * @see \Drupal\Core\Entity\EntityViewBuilderInterface::view()
 */
function entity_view(EntityInterface $entity, $view_mode, $langcode = NULL, $reset = FALSE) {

entityManager() is itself deprecated -- https://api.drupal.org/api/drupal/core!lib!Drupal.php/function/Drupal%3A...

Also, the use of the @code tag here is broken -- see https://api.drupal.org/api/drupal/core!includes!entity.inc/function/enti...

Part of #2072251: [meta] Modernize forms to use FormBase

Updated: Comment #N

Problem/Motivation

Now that #2059245: Add a FormBase class containing useful methods is in, I was looking at old forms that have empty validateForm() methods, or still use Drupal::service() or t().

Proposed resolution

Convert existing FormInterface forms to extend FormBase

Remaining tasks

User interface changes

API changes

Related Issues

Problem/Motivation

When you have a div in a fieldset with the class container inline all divs and labels get a display: inline.
On divs this breaks some style like margin and padding.

Proposed resolution

The proposed resolution applies the supplied patch to all divs that have the class .container-inline and sets the display style to inline-block.

Remaining tasks

From comment #5:
Search through core files to find instances of "container-inline" to find where this markup is used. Then take screenshots of as many of these instances as possible to make sure we are not visually breaking anything with this change.

Original report by @Oostie

When you have a div in a fieldset with the class container inline all divs and labels get a display: inline.
On divs this breaks some style like margin and padding.

This patch sets inline-block on divs.

Problem/Motivation

When we install Drupal 8 if we see the page's <title> tag then there is no value after the Pipe (|). Compared to Drupal 7 this showed "Drupal" keyword. As per the below image:

Proposed resolution

The page title is generated finally in "core/modules/system/templates/html.html.twig" with a Safe Join filter joining strings coming from $variables['head_title']. If the site "name" is not set then use "Drupal".

Remaining tasks

1. Write a patch
2. Some existing tests might fail (there are some dealing with the page title). If so then alter those accordingly.
3. Write test for this fix if needed.

User interface changes

TBD

API changes

N/A

Data model changes

N/A

Just like in this issue #2655474: version in info yaml confuses update reports, this module also has
version: VERSION
in the yaml file after a download from a make file or from git.

But that will then display version 8.0.5 (or the version of the installed core), and that will confuse the reports.

The solution is to remove this line, like at the other module.

Add a README.txt to the Seven Theme that includes instructions on changing Admin theme and changing theme for add / edit node pages.

Core does not support IE8 anymore. The shiv is not required: http://caniuse.com/html5semantic

Needs to be ported to the ie8 module contrib module, patches welcome.

There is non sense to leave a lot of spaces to the Operations columns. especially dropdown menu introduced into CORE, most of Operations columns are SINGLE button only.

Beta phase evaluation

Allowed in the beta since it is an unfrozen change: just CSS.

Before:

After:

Remaining Tasks

• make the big patch to affect all tables
• Update code that tests the output of the tables

Original Issue summary

It will be a big patch, would like to hear feedbacks before I made it into all tables. Attached a quick patch for tests. :)

It used same technique as #1252206: Remove checkbox spacing

From #1510544: Allow to preview content in an actual live environment

I did accidentally find one other bug in testing: if you're at admin/content, and select "Edit" next to a node in the list, then click "Preview," instead of being shown the preview, you will be taken back to admin/content and your changes lost. I suspect that's because the URL you end up on is http://8.x.local/node/1/edit?destination=admin/content and this somehow screws with the preview system's use of URLs? Hm.

Oh yes, the destination parameter, we somehow lost that in the patch somewhere, I remember we used to store that property as well.
It's not /that/ hard to implement, but I'm AFK until monday. If we can wait that's fine, unless someone else takes that up. Also more than happy to fix that in a follow up. You can even assign it on me immediately :)

The default value for "link text" is not being saved.

I added a link field to a content type. The link field is configured with "Allowed link text" set to be required. Under Default Value, I entered text for the "link text". I did not provide a default URL. When I save the field, Drupal is not saving my link text.

Problem/Motivation

I tried adding a local cached libary to libraries.xml file and referenced it properly. Per data_types.library.xml this is something that works for sure with CSS, but with JS it seems failing.

google_analytics.cached:
  remote: https://developers.google.com/analytics/devguides/collection/analyticsjs/
  version: VERSION
  license:
    name: © Google
    gpl-compatible: false
  js:
    'public://google_analytics/analytics.js': { async: true, minified: true, preprocess: false }

The website encountered an unexpected error. Please try again later.

Exception: Only local files should be passed to _locale_parse_js_file(). in _locale_parse_js_file() (line 1141 of core\modules\locale\locale.module).

locale_js_translate(Array) (Line: 503)
locale_js_alter(Array, Object, NULL) (Line: 501)
Drupal\Core\Extension\ModuleHandler->alter('js', Array, Object) (Line: 276)
Drupal\Core\Asset\AssetResolver->getJsAssets(Object, ) (Line: 298)
Drupal\Core\Render\HtmlResponseAttachmentsProcessor->processAssetLibraries(Object, Array) (Line: 161)
Drupal\Core\Render\HtmlResponseAttachmentsProcessor->processAttachments(Object) (Line: 45)
Drupal\Core\EventSubscriber\HtmlResponseSubscriber->onRespond(Object, 'kernel.response', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.response', Object) (Line: 179)
Symfony\Component\HttpKernel\HttpKernel->filterResponse(Object, Object, 1) (Line: 161)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 62)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 628)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Proposed resolution

Fix the bug.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Problem/Motivation

Can we get a followup to remove the last remnants of drupal-ajax (used in tests alot) and it's drupal- friends. Or maybe it should be cleanup here? We still have things like:

$response = $this->drupalPost('editor/' . 'node/1/body/en/full', 'application/vnd.drupal-ajax', array());
and

// We set up a request so it looks like an request in the live preview.
$request = new Request();
$request->setFormat('drupal_ajax', 'application/vnd.drupal-ajax');
$request->headers->set('Accept', 'application/vnd.drupal-ajax');

Proposed resolution

Remaining tasks

User interface changes

API changes

Problem/Motivation

Content types are ordered by machine name on node/add but by name on admin/structure/types. This is inconsistent.

Proposed resolution

Order content types by name on node/add.

Remaining tasks

User interface changes

API changes

Data model changes

When only one text format is available, the help link "About text formats" doesn't make much sense, since there is no manifestation of a text format in the UI that could need an explanation. See this screenshot from @LewisNyman (in the context of #784672: Allow text field to enforce a specific text format, which makes the situation of having just a single text format more common):

When only one text format is available, we should remove the link and well as the wrapper around it, not just the dropdown element as is currently the case.

Problem/Motivation

The information about text formats is a drupalism and most of the sites end up hiding that bit of information. Drupal 8 makes it a little more hard to hide so it might not be trivial to do.

Proposed resolution

- Add '#format_hide' property for the text format element.
- Expose this as an option for textarea widgets which support the #text_format type.

Remaining tasks

User interface changes

Adding a checkbox in manage form display to hide text formats.

API changes

If a node has revisions associated with it, and is deleted, the file reference (in the file_usage table) will remain, even after the node is deleted.

Since the record in the file_usage table still exists, any module that uses hooks from the file module (or filefield module - see https://www.drupal.org/node/1191438), such as the media module (see https://www.drupal.org/node/911830) will be unable to delete files, per the lock on those files in the file_usage table.

I believe that the is an issue with the revisions system, which seams to be working as designed, but has at least one bug and functions, in some ways, counter-intuitively even when working correctly.

IF a node has revisions, any files associated with it will be locked, even if the file changes in future revisions - this is, I believe, the intended behavior. However, If that node is deletion, the file_usage table is only updated with the current revisions, and old revisions, which no longer exist, as the node was deleted, still keep the file locked.

The solution is to add the removal of the file_usage directly in node.module itself - lots of people are trying to get around this and making it much more complicated than it should be, when all that is necessary is the following (in /modules/node.module, in the function node_delete_multiple()):

db_delete('file_usage')
       ->condition('id', $nids, 'IN')
       ->execute();

The following is SQL code that cleans up orphaned references in the file_usage table (Remove all records associated with nodes that no longer exist):

DELETE from file_usage WHERE fid IN (select fid from (select fu.fid as fid from file_usage fu LEFT JOIN node n ON n.nid = fu.id WHERE n.nid IS NULL) as tt);