When I attempt to use the views exposed filters in the media library widget I get the invalid hash error due to my hash having '_wrapper_format=drupal_ajax' appended to its end.
Related to #3038241: Implement a tamper-proof hash for the media library state
Hi All,
I am working on Drupal 8.2.0-dev for website on linux server with MariaDB as database server. The site setup is based on 3 instances of website setup or file system using one database. Whenever updates are made to the site cache is cleared from all 3 instances / nodes for changes to work properly esp. twig template changes.
Here is more detail about site configuration on server :-
The website is actually a 3-node cluster behind a load balancer.
Each node (node1,node2 and node3) are part of a MariaDB Galera Cluster, and each node is hosting the Drupal website.
Each drupal website communicates with it’s own DB. So this means when node1 is serving a page, it is reading/writing to the DB on node1. Likewise, node2 read/writes to node2’s DB and so on.
The website files on main location are replicated between the nodes using lsyncd and csync2.
So, when a visitor hits the website, traffic flow is :
HTTP Traffic -> HAPROXY Load Balancer -> (one of the 3 Nodes)
a. Node1 website communication to MariaDB on node1 (localhost)
b. Node2 website communication to MariaDB on node2 (localhost)
c. Node3 website communication to MariaDB on node3 (localhost)
I face an error :-
1. While using drupal admin interface for making updates or inserts website admin often gets error below.
2. Wen cache is cleared using Drush on website on the frontend also.
Uncaught PHP Exception Drupal\\Core\\Database\\DatabaseExceptionWrapper: "SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction: INSERT INTO {cache_entity} (cid, expire, created, tags, checksum, data, serialized) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6) ON DUPLICATE KEY UPDATE cid = VALUES(cid), expire = VALUES(expire), created = VALUES(created), tags = VALUES(tags), checksum = VALUES(checksum), data = VALUES(data), serialized = VALUES(serialized); Array, referer:
After searching on similar issues I found that solution suggested are using modules which are not ported to Drupal 8 yet e.g. https://www.drupal.org/project/apdqc. This issue was reported for Drupal 7 several times but not Drupal 8. I am not sure if its bug so adding support request.
Have not been able to find any reliable solution for this.
Just to add in my case the deadlock always is related to cache tables. Also can "Entity/field definitions" , " Mismatched entity and/or field definitions " as on page /admin/reports/status has any relation to this?
Any suggestions would be appreciated.
Thanks
Atul
When using the Paragraphs Classic widget with Preview as the edit mode the Dropbutton widget has some display issues.
It didn’t seem like any of the other existing issues addressed this, but sorry if I missed something.
After the completion of the new Extension system API's in #2208429: Extension System, Part III: ExtensionList, ModuleExtensionList and ProfileExtensionList and #2659940: Extension System, Part III: ThemeExtensionList and ThemeEngineExtensionList, drupal_get_path() has been replaced with the theme, module and profile extension listing services. This issue will deprecate the usage of drupal_get_path() in core and replace with the relevant extension listing service calls (Module|Profile|Theme)ExtensionList::getPath().
Replace all dynamic uses drupal_get_path() with (Module|Profile|Theme)ExtensionList::getPath(). The earlier issue #2351919: Replace uses of drupal_get_path() with __DIR__ where possible had taken care of static includes where relative location of the files were fixed.
Reviews
Commit
None
drupal_get_path() is deprecated.
Some blocks (especially those provided by contrib modules) may require Javascript behaviors to display properly.
If Layout Builder's "Show Content Preview" option is enabled, should we call Drupal.attachBehaviors($element); on new blocks that are added?
If Layout Builder's "Show Content Preview" option is not enabled by default, and then enabled, should we call Drupal.attachBehaviors($('#edit-layout-builder-layout-wrapper')); so any newly displayed blocks can have behaviors attached as needed?
The current behavior is that blocks requiring Javascript to display will not display as intended when used with Layout Builder.
Steps to reproduce:
- Install and enable the attached module.
- Create a view showing content.
- In the view, add a "Representative revision" relationship (provided by above module).
The view displays an error like this, complaining about a missing quotation mark:
SQLSTATE[HY000]: General error: 1 near "".langcode = "": syntax error: SELECT node_field_data.created AS node_field_data_created, node_field_data.nid AS nid, node_field_revision_node_field_data.vid AS node_field_revision_node_field_data_vid FROM {node_field_data} node_field_data LEFT JOIN {node_field_revision} node_field_revision_node_field_data ON (SELECT node_field_revisionINNER.vid AS vidINNER FROM {node_field_revision} node_field_revisionINNER LEFT JOIN {node_field_data} node_field_data_node_field_revisionINNER ON "node_field_revisionINNER".nid = "node_field_data_node_field_revisionINNER".nid AND node_field_data_node_field_revisionINNER".langcode = "node_field_revisionINNER".langcode WHERE ("node_field_data_node_field_revisionINNER".nid = node_field_data.nid) ORDER BY node_field_revisionINNER.vid DESC LIMIT 1 OFFSET 0) = node_field_revision_node_field_data.vid WHERE node_field_data.status = :db_condition_placeholder_0 ORDER BY node_field_data_created DESC LIMIT 11 OFFSET 0; Array ( [:db_condition_placeholder_0] => 1 )
I tested with the Drupal demo application (tried both the Umami and the standard install profile), no other contrib or custom modules installed.
The interesting part of the attached module is:
// groupwisemax_example.views.inc
<?php
/**
* Implements hook_views_data_alter().
*/
function groupwisemax_example_views_data_alter(array &$data) {
$data['node_field_data']['nid_representative'] = [
'relationship' => [
'title' => t('Representative revision'),
'label' => t('Representative revision'),
'help' => t('Obtains a single representative revision for each node, according to a chosen sort criterion.'),
'id' => 'groupwise_max',
'relationship field' => 'nid',
'outer field' => 'node_field_data.nid',
'argument table' => 'node_field_data',
'argument field' => 'nid',
'base' => 'node_field_revision',
'field' => 'vid',
'relationship' => 'node_field_revision:nid',
],
];
}
I can no longer save changes to the layout after any kind of form has been added to the layout.
Steps to reproduce:
1. Enable layout builder on a content type, then open layout builder.
2. Add 'Search Form' block to a section
3. Save the layout
4. Re-open the layout builder, and make some change (e.g. reorder blocks)
5. Attempt to save the layout
The page refreshes, but still shows unsaved changes. At this point, it is no longer possible to save the layout until the search form is removed.
Replace all FORM tags with DIV tags when in Layout Builder's preview mode.
Write tests
Layout Builder UI will no longer break when rendering forms
N/A
N/A
As part of #3094468: [plan] Update core JavaScript (and CSS) dependencies prior to 9.0.0-beta1 we need to update modernizr.
Update it
The standard_install() function from the Standard install profile prevents using the "Install from existing configuration" feature even though it does not deal with configuration at all. It simply creates/modifies some content entities.
Introduce the use of hook_install_tasks() to create/modify the content instead so that "Install from existing configuration" can be used with the Standard profile
No user interface changes here.
None.
Splitting standard_install into a number of hook_install_tasks() will clean up the function, and introduce some sanity in the install process.
GDToolkit::save() contains the following code.
// Work around lack of stream wrapper support in imagejpeg() and imagepng().
if ($scheme && $this->streamWrapperManager->isValidScheme($scheme)) {
// If destination is not local, save image to temporary local file.
$local_wrappers = $this->streamWrapperManager->getWrappers(StreamWrapperInterface::LOCAL);
if (!isset($local_wrappers[$scheme])) {
$permanent_destination = $destination;
$destination = $this->fileSystem->tempnam('temporary://', 'gd_');
}
// Convert stream wrapper URI to normal path.
$destination = $this->fileSystem->realpath($destination);
}
As the comment says, that code workarounds the lack of support for stream wrappers in imagejpeg() and imagepng(), but those functions accept a stream resource since PHP 5.4, as the Changelog section of those functions says.
5.4.0 Added support for passing a stream resource to to.
That code should be removed, since Drupal 8 doesn't support PHP 5.4 anymore.
Updated: Comment #74
New users registering accounts on a Drupal site can lose the welcome email to their spam filtering software.
New users can be created/imported into a Drupal system in bulk, and then it would be useful to be able to send a welcome email manually afterwards - #8.
Add the ability for users with the requisite permissions to re-send the welcome email to a user by visiting user/edit/XXX or using batch action in /admin/people.
Only users who can register accounts can re-send the welcome email - #71
RTBC working patch.
A new button "Re-send welcome message" appears on the user edit page for users with the correct permissions to use it.
Screenshots available at #44 and #73
None.
It would be nice if the admin could force a resend of the welcome message from the user edit page.
One case where this would be useful:
Many people are using spam-filtering software these days which make use of white lists, and the Drupal website sending address is not yet known to the user requesting an account.
The custom moderation_state_filter views filter plugin seems to work only with the the base table and not with entities brought in via a relationship. It complains about a base table field not being found with the raw table name instead of the alias. E.g. if relating a node it might complain that "node_field_data.type" is missing because the alias for the table is "n".
1. Ensure you have a moderation workflow that applies to an entity type of specific bundles (it's fine if you only have one bundle, but I think you do need to explicitly tick one)
2. Ensure you have an entity that can relate to that entity in a view (I've posted example view config for a user view related to representative nodes below)
3. Create a view where the base entity is the one that does *not* have a moderation workflow
4. Relate this view to the entity that *does* have a moderation workflow
5. Add the "Moderation state" filter plugin and select a state (or expose it)
The view should be rendered filtered by moderation state.
The view crashed with an error about an unknown field "node_field_data.type" (actual table alias is, e.g., node_field_data_users_field_data).
uuid: 60c84bd8-a39d-48a2-a93d-767ee0d84ba0
langcode: en
status: true
dependencies:
module:
- content_moderation
- node
- user
id: user_content_moderation_state_test_view
label: 'user content moderation state test view'
module: views
description: ''
tag: ''
base_table: users_field_data
base_field: uid
core: 8.x
display:
default:
display_plugin: default
id: default
display_title: Master
position: 0
display_options:
access:
type: perm
options:
perm: 'access user profiles'
cache:
type: tag
options: { }
query:
type: views_query
options:
disable_sql_rewrite: false
distinct: false
replica: false
query_comment: ''
query_tags: { }
exposed_form:
type: basic
options:
submit_button: Apply
reset_button: false
reset_button_label: Reset
exposed_sorts_label: 'Sort by'
expose_sort_order: true
sort_asc_label: Asc
sort_desc_label: Desc
pager:
type: some
options:
items_per_page: 5
offset: 0
style:
type: default
row:
type: fields
fields:
name:
id: name
table: users_field_data
field: name
entity_type: user
entity_field: name
label: ''
alter:
alter_text: false
make_link: false
absolute: false
trim: false
word_boundary: false
ellipsis: false
strip_tags: false
html: false
hide_empty: false
empty_zero: false
plugin_id: field
relationship: none
group_type: group
admin_label: ''
exclude: false
element_type: ''
element_class: ''
element_label_type: ''
element_label_class: ''
element_label_colon: true
element_wrapper_type: ''
element_wrapper_class: ''
element_default_classes: true
empty: ''
hide_alter_empty: true
click_sort_column: value
type: user_name
settings: { }
group_column: value
group_columns: { }
group_rows: true
delta_limit: 0
delta_offset: 0
delta_reversed: false
delta_first_last: false
multi_type: separator
separator: ', '
field_api_classes: false
filters:
status:
value: '1'
table: users_field_data
field: status
plugin_id: boolean
entity_type: user
entity_field: status
id: status
expose:
operator: ''
group: 1
moderation_state:
id: moderation_state
table: node_field_data
field: moderation_state
relationship: uid_representative
group_type: group
admin_label: ''
operator: in
value: { }
group: 1
exposed: true
expose:
operator_id: moderation_state_op
label: 'Moderation state'
description: ''
use_operator: false
operator: moderation_state_op
identifier: moderation_state
required: false
remember: false
multiple: false
remember_roles:
authenticated: authenticated
anonymous: '0'
admin: '0'
reduce: false
is_grouped: false
group_info:
label: ''
description: ''
identifier: ''
optional: true
widget: select
multiple: false
remember: false
default_group: All
default_group_multiple: { }
group_items: { }
entity_type: node
plugin_id: moderation_state_filter
sorts: { }
title: 'user content moderation state test view'
header: { }
footer: { }
empty: { }
relationships:
uid_representative:
id: uid_representative
table: users_field_data
field: uid_representative
relationship: none
group_type: group
admin_label: 'Representative node'
required: false
subquery_sort: node_field_data.nid
subquery_order: DESC
subquery_regenerate: false
subquery_view: ''
subquery_namespace: ''
entity_type: user
plugin_id: groupwise_max
arguments: { }
display_extenders: { }
cache_metadata:
max-age: -1
contexts:
- 'languages:language_content'
- 'languages:language_interface'
- url
- user.permissions
tags:
- 'config:workflow_list'
block_1:
display_plugin: block
id: block_1
display_title: Block
position: 1
display_options:
display_extenders: { }
cache_metadata:
max-age: -1
contexts:
- 'languages:language_content'
- 'languages:language_interface'
- url
- user.permissions
tags:
- 'config:workflow_list'When using the hal_json format with an entity that has a file field the hal_json output on GET does not provide enough information to access the file entity via the REST API.
I discovered this while reviewing #1927648: Allow creation of file entities from binary data via REST requests
I wanted to GET a node with a file field then be able to either GET, POST, PATCH or DELETE the file referenced. The example was working with had both a image and file field.
Here is the node GET response, the example has an image field, a public://file field and a private://file field.
{
"_links": {
"self": {
"href": "http://d8.dev/node/37?_format=hal_json"
},
"type": {
"href": "http://d8.dev/rest/type/node/article"
},
"http://d8.dev/rest/relation/node/article/revision_uid": [
{
"href": "http://d8.dev/user/1?_format=hal_json"
}
],
"http://d8.dev/rest/relation/node/article/uid": [
{
"href": "http://d8.dev/user/1?_format=hal_json",
"lang": "en"
}
],
"http://d8.dev/rest/relation/node/article/field_image": [
{
"href": "http://d8.dev/sites/default/files/2017-09/webform1.png",
"lang": "en"
}
],
"http://d8.dev/rest/relation/node/article/field_private_file": [
{
"href": "http://d8.dev/system/files/2017-09/interdiff-109-115.txt"
}
],
"http://d8.dev/rest/relation/node/article/field_public_file": [
{
"href": "http://d8.dev/sites/default/files/2017-09/interdiff-275-277.txt"
}
],
"http://d8.dev/rest/relation/node/article/field_tags": [
{
"href": "http://d8.dev/taxonomy/term/1?_format=hal_json",
"lang": "en"
}
]
},
"nid": [
{
"value": 37
}
],
"uuid": [
{
"value": "aef1528d-aedb-4afc-a20a-755a71805937"
}
],
"vid": [
{
"value": 53
}
],
"langcode": [
{
"value": "en",
"lang": "en"
}
],
"type": [
{
"target_id": "article"
}
],
"revision_timestamp": [
{
"value": "2017-09-07T19:33:55+00:00",
"format": "Y-m-d\\TH:i:sP"
}
],
"_embedded": {
"http://d8.dev/rest/relation/node/article/revision_uid": [
{
"_links": {
"self": {
"href": "http://d8.dev/user/1?_format=hal_json"
},
"type": {
"href": "http://d8.dev/rest/type/user/user"
}
},
"uuid": [
{
"value": "3d76e74e-25b5-45e9-af89-3d94f253b46c"
}
]
}
],
"http://d8.dev/rest/relation/node/article/uid": [
{
"_links": {
"self": {
"href": "http://d8.dev/user/1?_format=hal_json"
},
"type": {
"href": "http://d8.dev/rest/type/user/user"
}
},
"uuid": [
{
"value": "3d76e74e-25b5-45e9-af89-3d94f253b46c"
}
],
"lang": "en"
}
],
"http://d8.dev/rest/relation/node/article/field_image": [
{
"_links": {
"self": {
"href": "http://d8.dev/sites/default/files/2017-09/webform1.png"
},
"type": {
"href": "http://d8.dev/rest/type/file/file"
}
},
"uuid": [
{
"value": "ce48df6b-83e9-47b8-9875-c2fe391ef9b1"
}
],
"uri": [
{
"value": "http://d8.dev/sites/default/files/2017-09/webform1.png"
}
],
"lang": "en"
}
],
"http://d8.dev/rest/relation/node/article/field_private_file": [
{
"_links": {
"self": {
"href": "http://d8.dev/system/files/2017-09/interdiff-109-115.txt"
},
"type": {
"href": "http://d8.dev/rest/type/file/file"
}
},
"uuid": [
{
"value": "50ab6ba6-7a86-4027-a86d-a26ebf0e09b5"
}
],
"uri": [
{
"value": "http://d8.dev/system/files/2017-09/interdiff-109-115.txt"
}
]
}
],
"http://d8.dev/rest/relation/node/article/field_public_file": [
{
"_links": {
"self": {
"href": "http://d8.dev/sites/default/files/2017-09/interdiff-275-277.txt"
},
"type": {
"href": "http://d8.dev/rest/type/file/file"
}
},
"uuid": [
{
"value": "bb9ed1d1-f613-4647-b932-2e2f52143bfd"
}
],
"uri": [
{
"value": "http://d8.dev/sites/default/files/2017-09/interdiff-275-277.txt"
}
]
}
],
"http://d8.dev/rest/relation/node/article/field_tags": [
{
"_links": {
"self": {
"href": "http://d8.dev/taxonomy/term/1?_format=hal_json"
},
"type": {
"href": "http://d8.dev/rest/type/taxonomy_term/tags"
}
},
"uuid": [
{
"value": "5228c13c-265a-42d1-bbca-ea4a30385cfc"
}
],
"lang": "en"
}
]
},
"status": [
{
"value": true,
"lang": "en"
}
],
"title": [
{
"value": "uuuuu",
"lang": "en"
}
],
"created": [
{
"value": "2017-09-06T14:22:27+00:00",
"lang": "en",
"format": "Y-m-d\\TH:i:sP"
}
],
"changed": [
{
"value": "2017-09-07T19:33:55+00:00",
"lang": "en",
"format": "Y-m-d\\TH:i:sP"
}
],
"promote": [
{
"value": true,
"lang": "en"
}
],
"sticky": [
{
"value": false,
"lang": "en"
}
],
"default_langcode": [
{
"value": true,
"lang": "en"
}
],
"revision_translation_affected": [
{
"value": true,
"lang": "en"
}
],
"path": [
{
"alias": null,
"pid": null,
"langcode": "en",
"lang": "en"
}
],
"content_translation_source": [
{
"value": "und",
"lang": "en"
}
],
"content_translation_outdated": [
{
"value": false,
"lang": "en"
}
],
"comment": [
{
"status": 2,
"cid": 0,
"last_comment_timestamp": 1504707773,
"last_comment_name": null,
"last_comment_uid": 1,
"comment_count": 0,
"lang": "en"
}
]
}
Nowhere in the response do I have access to the file entity's id or url to access the file entity via the REST API.
This not true for the other entity reference fields.
For the term I am given: "href": "http://d8.dev/taxonomy/term/1?_format=hal_json
and for the user I am given: "href": "http://d8.dev/taxonomy/term/1?_format=hal_json
Therefore I wanted to view, update or delete the file entity I would not be able to via REST.
Not sure but somehow return http://d8.dev/entity/file/1?_format=hal_json
Response for hal_json normalized file fields would be changed.
Given following code snippet with a Drupal installation have en and de language enabled with LanguageUrlNeogotiation.
$url = '/de/i-am-an-alias';
$url_object = $this->pathValidator()->getUrlIfValidWithoutAccessCheck($url);
The expected result is to have a `$url_object` that correctly points to the related canonical entity URL of de language.
The actual result is the `$url_object` is null.
After digging into the underline code, below is the call stack.
\Drupal\Core\Path\PathValidator::getUrlIfValidWithoutAccessCheck -> \Drupal\Core\Path\PathValidator::getPathAttributes -> \Drupal\Core\PathProcessor\PathProcessorManager::processInbound -> \Drupal\Core\PathProcessor\PathProcessorAlias::processInbound
Inside `PathProcessorAlias::processInbound` it calls `aliasManager::getPathByAlias`, but it discards the `$request` parameter completely, the alias is heavily relying on the language negotiation result, ignore the language in `$request` context, will certainly give a problematic result.
Proposed Solution:
Respect `$reqest` parameter in `PathProcessorAlias::processInbound` and get the negotiated language from the `$request`.
1. Add the media as a reference field in the Basic Page content type.(Allow unlimited)
2. Add basic page content.
3. While adding a basic page in the media section click Add Media.
Select all media checkbox is missing media library popup.
#3041924: [META] Convert hook_help() module overview text to topics for the basic_auth, hal, jsonapi, rdf, rest, and serialization modules.
NOTE: What is below is the generic instructions for converting hook_help to topics. We want to end up with task-based topics; in this case, there really aren't "tasks" per se for these modules. So let's just make one topic called something like "Enabling web services on your site" with a filename starting with "core." (so it is not in one module's namespace), and describe what web services are, and what each of these 5 web services modules does.
Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:
switch ($route_name) {
case 'help.page.contact':
And ends either at the end of the function, or where you find another case 'something': line.
core/modules/help_topics/help_topics. Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).
core/modules/help_topics/help_topics. You will need to choose the appropriate module prefix for the file name -- the module that is required for the functionality. Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can use the "core" file name prefix. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in the core prefix), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module prefix). a) Make a patch (see Proposed Resolution section).
b) Review the patch:
admin/help/topic/rdf.overview within your site.admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.
None.
None.
None.
#3041924: [META] Convert hook_help() module overview text to topics for the internationalization modules: config_translation, content_translation, locale, language module(s).
Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:
switch ($route_name) {
case 'help.page.contact':
And ends either at the end of the function, or where you find another case 'something': line.
core/modules/help_topics/help_topics. Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).
core/modules/help_topics/help_topics. You will need to choose the appropriate module prefix for the file name -- the module that is required for the functionality. Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can use the "core" file name prefix. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in the core prefix), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module prefix). a) Make a patch (see Proposed Resolution section).
b) Review the patch:
admin/help/topic/action.configuring within your site.admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.
None.
None.
None.
If Drupal uses a node as startpage, and an admin deletes that user (ignoring that the user has ownership of nodes) the website has no frontpage and gives an error.
I suggest an extra check when a user gets deleted that displays a message like "If you deletes this owner and his/hers content, the website will have no frontpage. Are you sure you want to do that?" or perhaps even a level of security that prevents admin from deleting that particular user and his/hers content.
From \Drupal\Core\DrupalKernel::updateModules() docblock:
* @todo Remove obsolete $module_list parameter. Only $module_filenames is
* needed.
Indeed the two method parameters are the same. The core callers are passing every time the same value as both params.
Deprecate the 2nd parameter.
None.
None.
None.
N/A
Firefox 49 is out and has support for <details> which means our polyfill doesn't kick in. Normalize.css sets <details> and <summary> element as display:block which means Firefox won't display the marker, they fixed this in 5.0.0 (https://github.com/necolas/normalize.css/issues/604).
Checkout comparison aligned by @droplet: (removed comments & unchanged rules, re-reordering to match v3)
https://www.drupal.org/files/issues/diff-manual-aligned-by-%40droplet.patch
Here are the change logs for Normalize.css, starting at 4.0.0 (scroll up): https://github.com/necolas/normalize.css/blob/f06565fe8e0e1ad1b88f273271.... There are a lot of changes due to reorganization/sectioning of the code as well as comment changes.
There is one notable change that causes a regression in, at least, Seven: https://github.com/necolas/normalize.css/commit/02c5c7adbbec1707900fde86..., see the attached screenshot.
There may be regressions upgrading from 3.0.3 to the most recent normalize.css.
Upgrade core's Normalize to most recent version.
Normalize 3.0.3 should be copied to Stable. Stable needs to continue using 3.0.3 for BC.
Hopefully none!