Problem/Motivation

When running Drupal on MySQL or Maria DB you can run in several errors that corrupt the database connection. Some examples for these kind of errors on the database layer are

• 1100 - Table 'xyz' was not locked with LOCK TABLES
• 1153 – Got a packet bigger than ‘max_allowed_packet’ bytes
• ...

If such an error happens, the MySQL server invalidates the connection and answers all further request through this connection by 2006 - MySQL server had gone away.
Just have a look at https://www.google.com/search?q=site%3Adrupal.org+2006+MySQL+server+had+... to see that the drupal project is affected by that.

Again, 2006 - MySQL server had gone away is not the error that causes an issue, it's the symptom you face after a different error happened. The causal error might be software bug in core or a contributed module or an inappropriate setup of the environment (for example the MySQL setup).

Normally you'll find details about the causal error in the logs. But if you use dblog, which is the most common in shared hosting environments, you won't find anything in the log because the log entry is not written due to the already invalidated connection.

If you also turned off error reporting on the site, all you get is a WSOD.

Proposed resolution

The solution to this problem is easy. The 2006 - MySQL server had gone away error causes an Exception while wrinting to the log. If such an exception occurs we can simply open a second connection to the database and write the log entry again.

If you read through the comments, you'll notice that @Damien Tournoud already agreed on the proposed solution throughout the years for the different drupal versions:

Good idea, let's see how we can implement that in the new database layer.

Still applies to 8.x, which uses the default connection for watchdog messages.

Remaining tasks

Review and commit the existing patch.

User interface changes

None.

API changes

None.

The original issue description as posted for Drupal 6

If you read through different drupal bug reports you often see a quote like
Table 'watchdog' was not locked with LOCK TABLES

This could happen if you're using MySQL and a module requests a table lock and run into an error afterwards. In this case drupal is unable to store the error because it could not access the watchdog table.

I attached a patch that opens a dedicated database connection to write watchdog entries like I already proposed in these bug reports:
#298678: Impossible to lock two MySQL tables
#195812: db_error() doesn't work on default connection

Here are some issues related to this bug report:
#286176: Views causing error "Table 'watchdog' was not locked with LOCK TABLES'
#286380: Got past mem problem only to hit a timeout problem
#174705: Modify node type configuration storage to use a serialized collection stored in one variable rather than long variable names
#99718: user warning: Duplicate entry - work around available

Beta phase evaluation

This may or may not be a bug. I'm unable to enable page caching for anonymous users and can't find the reason.

I know that page and block caching is important for most Drupal sites. The other day I noticed one of our sites had neither of these caching types enabled. A warning on the Performance page stated that “block caching may be disabled due to some modules that impose content access restrictions.” True enough, I found the Content Access module and disabled it and that allowed me to enable block caching. However, Page caching still can’t be enabled.

Searching my files for "Cache pages for anonymous users," I found the source of the page cache switch on line 1707 of system.admin.inc:

$cache = variable_get('cache', 0);    // default value is page cache = FALSE.
  $form['caching']['cache'] = array('#type' => 'checkbox','#title' => t('Cache pages for anonymous users'),'#default_value' => $cache,'#weight' => -2,
  );

The default is 0. My question is, would changing the 0 to 1 force page caching ON? Or would that be wrong and ill advised? To avoid hacking core, I assume I would copy system.admin.inc to another location, such as /sites/all/default/files or my custom module folder if that sort of thing were permitted. Does Drupal even let you tamper with this system file?

I’m not finding many clues in Watchdog or Google searches. I did find a very good page on caching options:

https://www.drupal.org/docs/7/managing-site-performance-and-scalability/...

I will have to experiment. If anyone can share particular guidance that would be most helpful.

1. Opcode caching,
2. Database caching,
3. Web server (proxy) caching, eg Varnish

Option one looks promising, https://www.drupal.org/project/apc

Problem/Motivation

Initially this issue was about changing the label of the contextual (delete) link to match the label in block-layout (remove). In fact the link in contextual links actually deletes the block and all of it's instanaces. This is too destructive an action to expose in a contextual link, since users are likely to think they are only removing a single instance when they are in fact removing all instances and any associated content.

Proposed resolution

Remove the 'delete' contextual link from blocks.

Remaining tasks

Create patch

User interface changes

There will be no 'delete' link on blocks.

API changes

?

Data model changes

?

Having set up an auto-reply message the mail finally gets sent without any line breaks in it. Neither <br> nor \r\n nor \\r\\n works.

Problem/Motivation

Now that we're well on our way to managing coding standards in a reproducible way: #2571965: [meta] Fix coding standards in core

...let's just add the tools to core's composer.json dev requirements.

That way we don't have to instruct people how to install them beyond saying "run composer install --dev"

Proposed resolution

Modify core/composer.json to add drupal/coder and squizlabs/php_codesniffer as a dev requirement.

Add an install script to composer.json which adds coder's code_sniffer as an installed_path.

Remaining tasks

Update documentation such as https://www.drupal.org/node/1419988 and https://www.drupal.org/node/1587138

User interface changes

API changes

Data model changes

Problem/Motivation

JSON produced by the HAL and JSON normalizers provides all data values as strings. This makes it difficult for strongly typed uses of the REST interface to interact with the JSON payload. Examples include: client libraries, auto-generated documentation, and schemas. By providing BooleanItems as booleans, IntegerItems as integers, and so on, the values output in JSON will have the correct type without client-side casting. This has the nice side effect of better lining up output with expectations of the Typed Data API.

Proposed resolution

Add additional field item normalizers casting values to explicitly match the type implied by the field item class.

Remaining tasks

None.

User interface changes

None.

API changes

None: this is an opt-in change. Existing sites continue to get the exact same responses, with booleans and integers as strings.

Only new sites will get the "correct" output by default.

See the change record: https://www.drupal.org/node/2837696.

Data model changes

None.

The file upload widget has some strange behavior when Inline Form Errors is enabled.

Issue is blocked by #2482783: File upload errors not set and shown correctly. and #77245: A place for JavaScript status messages.

This can be tested after uploading a wrong file type.

With JavaScript:

1. There is a hash link directly above the image, this should be removed.
2. The important error is not inline, and a not needed error "this value should not be null" is shown inline.
3. Minor importance: there is no new hash link at the top of the page to the error. (No blocker because the user doesn't has to search for the error on the page, it is right before him/her.

Without JavaScript enabled.

1. The file type error is not inline
2. In case that the file is required, the required message is also shown. When there is another error the required error shouldn't be shown./li>

Original issue:

Pulled from #435 from @dmsmidt written on April 15, 2015 at 5:12pm

Problem/Motivation

List of authentication providers consists of module names, which are defined them. In this case an authentication cannot be configured, because providers with such names aren't exists.

Display configuration through UI.

Exported configuration

Proposed resolution

Correct a computation of the authentication_providers variable for DI container inside of \Drupal\Core\DependencyInjection\Compiler\AuthenticationProviderPass::process() method.

Correct a computation of the options list for configuring the authentication (\Drupal\rest\Plugin\views\display\RestExport::getAuthOptions()).

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

The description and behavior is completely the same as in #2836827: Drupal.tableDrag: column span calculated wrongly for custom column, because `tabledrag.js` wasn't redesigned and mostly was migrated from 7.x.

Problem/Motivation

Configuration entities defines the config_prefix which is used for schema describing. For instance, prefix of \Drupal\taxonomy\Entity\Vocabulary is vocabulary and schema with the taxonomy.vocabulary.*: name will be used for storing the data. If \Drupal\taxonomy\Entity\Vocabulary class will implement the getConfigDependencyName() method which returns 'taxonomy.TEST.' . $this->id(), then toArray() method of \Drupal\Core\Config\Entity\ConfigEntityBase will ignore this change.

Proposed resolution

1. Use $this->getConfigDependencyName() instead of $entity_type->getConfigPrefix() . '.' . $this->id() in \Drupal\Core\Config\Entity\ConfigEntityBase::toArray()
2. Return $this->getEntityType()->getConfigPrefix() . '.' . $this->getConfigTarget() by getConfigDependencyName() of the same class.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Form containing three tables with "tableDrag" feature for every of them. Every row of table consists of four columns (latest - weight, which is hidden). Also, for every table manually added one extra row, containing a custom button in a single column. For this column, in last row, the colspan attribute is set to 4 to make it as wide as row is.

The logic of tabledrag.js is increasing or decreasing the values of colspan attribute for elements with tabledrag-has-colspan class, depending on initial state (show/hide the weight field), saved in cookie.

Also, an error will be produced if colspan attribute for a custom cell will not be exist.

First table of three in a form

Actually there should be 3, since weights columns are hidden. So JS logic should just decrease it by one.

Second table of three in a form

Last table in a form

Extra-row without colspan attribute

I am a contributed module maintainer and am working on a port of a module that dynamically generates inline SVG in page content. It does so to produce charts, graphs, etc based on SQL data. Currently the rendering system removes all inline SVG from markup. Most of the suggestions I've seen suggest writing custom theme layers to embed the SVG, but in my case, I don't know how many SVG graphs will be in a document in advance.

Can anyone suggest how to proceed? Would it be appropriate to try and include every possible SVG tag in the #allowable_tags attribute? Are there issues with namespaced attributes such as xlink if I attempt this?

Problem

• PHP 5.4 calls a new stream_metadata() method on stream wrappers for chmod(), touch(), chown(), and chgrp() operations, while PHP 5.3 does not, which causes our stream wrappers to blow up depending on PHP version.
• We largely didn't notice, because most of our chmod() calls in core are @error-suppressed.

Proposed solution

1. Drop the custom StreamWrapperInterface::chmod() method and require all stream wrappers to implement stream_metadata() instead.

Original report

Running D8 tests on my local PHP5.4 installation I get tons of this warning (especially on cleaning up after a failed test):

Warning: chmod(): Drupal\Core\StreamWrapper\PublicStream::stream_metadata is not implemented! in Drupal\simpletest\TestBase::filePreDeleteCallback() (line 1339 of core\modules\simpletest\lib\Drupal\simpletest\TestBase.php).

A bit bizar that chmod warns about it, but as of PHP5.4 stream_metadata is part of the suggested StreamWrapper class: http://php.net/manual/en/streamwrapper.stream-metadata.php.

We don't require PHP5.4 yet, but we do support it. So this warning should be prevented. I guess we can do some dummy implementation if it is not really used elsewhere.

Looking at the suggested list of methods in the 5.4 documentation, I see 4 missing methods:
- public bool stream_metadata ( string $path , int $option , mixed $value )
- public bool stream_truncate ( int $new_size )
And already part of PHP5.3:
- public resource stream_cast ( int $cast_as )
- public bool stream_set_option ( int $option , int $arg1 , int $arg2 )

I'm not sure if they all may lead to a warning somewhere, but I think we better implement them to prevent warnings popping up somewhere sometime.

Problem/Motivation

For now, creating batches, using storage service, looks like \Drupal::service('batch.storage')->create($batch);. For instance, if batch defined as progressive, then it'll be created via the same construction inside of batch_process() function. Afterwards, when batch is finished and _batch_finished() executed, an entry will be deleted from storage by \Drupal::service('batch.storage')->delete($batch['id']);. Everything fine at the moment. My proposal is: take care about the storage and trigger the cleanup() method of the service inside of system_cron().

In addition to above, there could be a case when _batch_queue() function will try to construct wrong class. To resolve this, I propose to add an interface which will identify batch-related queues.

Proposed resolution

Add execution of \Drupal::service('batch.storage')->cleanup() to system_cron().

Remaining tasks

None.

User interface changes

None.

API changes

Add \Drupal\Core\Queue\BatchQueueInterface which must be implemented by every custom batch queue.

Data model changes

None.

Problem/Motivation

Follow-up to #2507031-158: Optimize automatic cron subscriber by moving automatic cron to a module

@catch

I'm not 100% on keeping the form and altering it, we could possibly move that to a status report item, then link to the form if automated cron is enabled.

The cron should not be run when the user clicks "Save configuration" button.

Proposed resolution

Move the cron form to a status report item, then link to the form if automated cron is enabled

Remaining tasks

User interface changes

1. With automated_cron module disabled, the cron form is disabled at /admin/config/system/cron.
2. In Status report there's a new line under "Cron maintenance tasks" telling to enable the automated_cron module, if disabled, or linking to Automated Cron settings form, if enabled.
3. The former route/link title 'Cron' (in /admin/config/system) renamed to 'Automated Cron'

.

4. Rearranged form elements in /admin/config/system/cron to give priority to 'interval' setting.

.

API changes

None.

Data model changes

None.

Problem/Motivation

When the page contains exposed form and additional form with AJAX enabled, then only views form will work. The most frequent case is: search page with AJAX exposed form and AJAX login form. In described case login will not be possible, because form will be broken by views.

Proposed resolution

Do not build exposed form when request contain the FormBuilderInterface::AJAX_FORM_REQUEST property.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

hook_preprocess_node() gets triggered while deleting a node.

Currently, Layouts can provide their own icon image which can be used in user interfaces. These icons could be in any size, color, dimensions, or style. As a result, user interfaces suffer as consistency is lost between different Layouts. The best example of this are the bright-pink icons provided by Radix, which look nothing like the default Panels or Display Suite Layouts (this isn't Radix's fault, we can't expect everyone to have the same design opinions).

The provided patch is a proof of concept for dynamically generated icons, which can not only help with consistency but could also be used in user interfaces to directly interact with regions. This also reduces developer strain as filling out config is far easier than creating an icon (which is a skill not everyone has).

Instead of making something fully featured, I wanted to put this forward and see if anyone sees value in what I've already done. Simply apply the provided patch, enable the layout_plugin_example module, and visit the path /admin/layout_plugin_example/layout_map/layout_example_stacked.

What you see on that page is the result of a new configuration value, "icon_map", which is a two-dimensional array mapping region names to their visual placement on a page. Widths of regions are determined dynamically based on the number of columns per row in the array. You can also hover over any region to see a tooltip containing the machine name of the region. See layout_plugin_example.layouts.yml for the exact structure used.

Thoughts?

Problem/Motivation

When a navigation menu contains an item that is inaccessible (access = FALSE), the following notice is generated:

Notice: Undefined index: localized_options in menu_navigation_links()

This issue can be reproduced with stock Drupal core by assigning the Navigation menu as the Secondary links source.

The source of the issue is that, for performance reasons, inacessible menu items are not localized. However, menu_navigation_links() processes all non-hidden menu items, regardless of access, and assumes that they have been localized.

Proposed resolution

When iterating items in menu_navigation_links(), test for access as well as hidden status before processing. This extra access check ensures that non-localized items won't be processed.

Remaining tasks

Write a test that reproduces the issue. A draft test is attached in #50.

User interface changes

None

API changes

None

Original report by javier.alejandro.castro

Using stock D7, with Spanish translation, and Zen theme with a custom sub-theme, i get this when choosing "Navigation menu" as source for "Secondary links".

Notice: Undefined index: localized_options in menu_navigation_links() (line 1780 of /var/www/html/drupal/includes/menu.inc).

OS: Fedora 14 Linux
Webserver: Apache 2.2.17
PHP: 5.3.4
Drupal: 7.0 (final)
Path: /var/www/html/drupal

Haven't quite tracked down the root cause of this yet, but the short version is:

1. select list with term options passed node->term_field[LANGUAGE_NONE][0] = array('tid' => NULL)
2. This gets saved into the db as array('tid' => 0) (in this case mongo).
3. If you then load and save the node, taxonomy_field_validate() evaluates 0 == 'autocreate' as TRUE
4. Then it tries to save a term with no vid or name and errors abound.

This took a long time to track down, not least because taxonomy_field_validate() runs on any taxonomy field, not just autocomplete.