Remove all invalid lowercase transformations from translatable strings

October 25, 2015, 4:02 am

≫ Next: Get d6 migrate tests and schema for new primary/secondary menus back into core

≪ Previous: Followup: Add more tests for RSS feeds to the Comment and Aggregator modules

$

0

0

getEntityTypeId() returns a lowercase string. This is incorrect in German. Strings must not made lowercase!

<?php
/**
   * {@inheritdoc}
   */
  public function getTitle() {
    // Use the custom 'config_translation_plugin_id' plugin definition key to
    // retrieve the title. We need to retrieve a runtime title (as opposed to
    // storing the title on the plugin definition for the link) because it
    // contains translated parts that we need in the runtime language.
    $type_name = Unicode::strtolower($this->mapperManager()->createInstance($this->pluginDefinition['config_translation_plugin_id'])->getTypeLabel());
    return $this->t('Translate @type_name', array('@type_name' => $type_name));
  }
?>

Screenshot (admin/config/regional/language/edit/de):
Image may be NSFW.
Clik here to view.

This need to be "Sprache" and not "sprache" or as translation "Translate language" becomes "Sprache übersetzten" in German or in code '@entity_type übersetzen'

---

Get d6 migrate tests and schema for new primary/secondary menus back into core

September 28, 2014, 7:18 pm

≫ Next: Allow annotations to inherit across namespaces

≪ Previous: Remove all invalid lowercase transformations from translatable strings

$

0

0

Follow-up to #1869476: Convert global menus (primary links, secondary links) into blocks

Problem/motivation

Schema was removed for the old style global primary and secondary navigation configuration.

Proposed solution

Attempt to re-create those changes using the new block based menus within migration and add tests.

Allow annotations to inherit across namespaces

October 25, 2015, 2:50 pm

≫ Next: link to i18n defgroup (and update the information) instead of linking to the Localization API handbook page

≪ Previous: Get d6 migrate tests and schema for new primary/secondary menus back into core

$

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.

link to i18n defgroup (and update the information) instead of linking to the Localization API handbook page

October 25, 2015, 2:53 pm

≫ Next: Make themeInitialization public property in theme registry protected

≪ Previous: Allow annotations to inherit across namespaces

$

0

0

Problem/Motivation

Follow-up to #2578377: Make translatable docs consolidated and better for developers

that issue wants to refer to the ways to make strings available for translation
and it was noted that it is better practice to update the defgroup and link to that.

Proposed resolution

link to a topic here (something in a defgroup) and make sure we have the essential information covered -- and then in that topic link to d.o for more info

Remaining tasks

Contributor tasks needed

Task	Novice task?	Contributor instructions	Complete?
Create a patch		Instructions
Review patch to ensure that it fixes the issue, stays within scope, is properly documented, and follows coding standards		Instructions

User interface changes

No

API changes

No

Data model changes

No

Make themeInitialization public property in theme registry protected

October 25, 2015, 2:18 pm

≫ Next: [meta] Arbitrary files can be referenced in POST request, access bypass

≪ Previous: link to i18n defgroup (and update the information) instead of linking to the Localization API handbook page

$

0

0

Problem/Motivation

themeInitialization property in theme registry should be protected

Proposed resolution

Make themeInitialization public property in theme registry protected

Remaining tasks

User interface changes

API changes

Data model changes

[meta] Arbitrary files can be referenced in POST request, access bypass

October 12, 2015, 4:36 am

≫ Next: Add a Drupal Yaml wrapper so we can default to PECL Yaml component if it is available

≪ Previous: Make themeInitialization public property in theme registry protected

$

0

0

This issue has been discussed by the Drupal Security Team, but it was decided to fix this in a public issue because the impact is less critical.

Problem/Motivation

When an entity is created with a PATCH/POST request then an arbitrary existing file can be referenced in a file field. No file restrictions like file extension, file size etc. is validated.

The same problem happens when editing entities in the browser/form API and manipulating file IDs when the form values are POSTed. Arbitrary other files can be referenced, bypassing any validation.

This problem also affects Drupal 7.

Steps to reproduce on a fresh install of Drupal 8:
Before you begin:
If you didn't install Drupal with a specified path to private files, update the private file path in settings.php and clear system cache.
Your private file folder should have permissions of 770 OR you can manually add the .htaccess file.
1. Enable REST module and HAL module
(You might have to edit a php.ini setting if you're getting an error about always_populate_raw_post_data)
2. Edit the content type "Article" and limit the image field to allow only png images
3. Edit the content type "Basic Page" and add a private file field that only allows txt files
4. Grant permission "Article: Create new content" to the anonymous user
5. Grant permission "Access POST on Content resource" to the anonymous user
6. Upload a file secret.txt to a published basic page node
7. Determine the id of the file you uploaded by visiting admin/content/files and checking the file id in the Usage url.
8. Issue the following request as anonymous attacker to reference secret.txt in an article (where the target_id 1 is the file ID of secret.txt and you replace YOURLOCALHOST with the url of your localhost): curl --include --request POST --header 'Content-type: application/hal+json' http://YOURLOCALHOST/entity/node --data-binary '{"_links":{"type":{"href":"http:\/\/YOURLOCALHOST\/rest\/type\/node\/article"}},"title":[{"value":"test title"}],"type":[{"target_id":"article"}],"field_image":[{"target_id":"1"}]}'

Now there is a new node with a file referenced that has bypassed all file validation for this field.

Another effect of this:
8. Unpublish the basic page with secret.txt
9. secret.txt is still accessible to anonymous users because it is referenced in the new article node created over REST

Proposed resolution

#1927648: Serialize file content (base64) to support REST GET/POST/PATCH on file entity started work on file handling over REST from where we can take the validation constraint approach. We should fix this bug independently of the fully working file uploads over REST issue to get this fixed faster.

Remaining tasks

Patch + tests

User interface changes

none.

API changes

File validation is moved to a constraint?

Data model changes

none.

Add a Drupal Yaml wrapper so we can default to PECL Yaml component if it is available

February 18, 2013, 10:23 pm

≫ Next: Views feed doesn't encode embedded HTML anymore

≪ Previous: [meta] Arbitrary files can be referenced in POST request, access bypass

$

0

0

Problem/Motivation

We should be defaulting to the PECL Yaml component if it is available as opposed to Symfony's because:
it is a performance improvement for reads (decoding)
and is YAML complient.

(Also, see #249)

We had originally talked about this way back in the beginning but it had been forgotten about.

Image may be NSFW.
Clik here to view.

Proposed resolution

Add a YAML class that decides whether to use the extension or Symfony. There's no point in using plugins and plugins are too heavy for this -- it's not extensible.

Also, Created Symfony issue for their invalid parsing: https://github.com/symfony/symfony/issues/16234

API changes

Config save no longer throws exceptions if the config object contains an object or resource. While we could make Symfony do this, yaml_emity() doesn't do this so we can't make this a requirement.

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes

Issue category	Task|Bug because it is a performance improvement
Issue priority	Major, because it saves actually something
Unfrozen changes	No
Prioritized changes	Yes, performance improvements
Disruption	None

Major, no disruption, performance improvement so allowed.

Views feed doesn't encode embedded HTML anymore

June 5, 2015, 2:10 am

≫ Next: Apply 'box-sizing: border-box' globally.

≪ Previous: Add a Drupal Yaml wrapper so we can default to PECL Yaml component if it is available

$

0

0

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes

Issue category	Bug because valid HTML in RSS feeds is rendered unescaped.
Issue priority	Major because this breaks RSS feeds that involve a field that allows HTML, including the default site RSS feed (/rss.xml).
Prioritized changes	Yes: bug fix.
Disruption	None.

Problem/Motivation

HTML in views feeds isn't escaped anymore at all which completely breaks the feed.

It looks like this:

<description><span data-quickedit-field-id="node/1/title/en/rss" class="field field-node--title field-name-title field-type-string field-label-hidden">RSS Feed test</span>
<span data-quickedit-field-id="node/1/uid/en/rss" class="field field-node--uid field-name-uid field-type-entity-reference field-label-hidden"><a title="View user profile." href="/user/1" lang="" about="/user/1" typeof="schema:Person" property="schema:name" datatype="" class="username">admin</a></span>
<span data-quickedit-field-id="node/1/created/en/rss" class="field field-node--created field-name-created field-type-created field-label-hidden">Fri, 06/05/2015 - 08:44</span>
</description>

Additional information

The W3C's RSS 2.0 spec implies that the description field is the only field that may have "entity-encoded HTML."

Proposed resolution

The RSS description element should be converted to a string and automatically escaped by Twig when sent to the template so it appears as escaped HTML and not part of the DOM. With the move towards as-late-as-possible rendering, this will be done in the template_preprocess_views_view_row_rss().

Remaining tasks

1. Moot: Need feedback on #8, specifically the last blockquote and the paragraph following it. The one that starts with "I don't understand this question..." :)
2. Add tests to prevent regression. Done: #2.
3. Determine if additional tests are needed for the Comment and Aggregator module changes (there are no existing tests for RSS feeds for the Aggregator module and very limited for the Comment module). See #8. Moved to a followup: #2600922: Followup: Add more tests for RSS feeds to the Comment and Aggregator modules

User interface changes

None.

API changes

None.

Why this should be an RC target

Without this fix, the default site-wide RSS feed (/rss.xml) is broken and will not validate using the W3C's feed validation tool. A partial workaround is to rebuild the default RSS feed using fields and strip HTML from the field assigned to the description element. I say "partial" because there are many feed readers that will render properly escaped HTML and this workaround leaves us with plain text.

Disruptions for this change are minimal. Contrib modules that provide RSS display or row plugins will need to ensure they are passing a render array for the description element. Core modules that provide those plugins (Comment and Aggregator) are updated with this patch.

---

Apply 'box-sizing: border-box' globally.

October 30, 2013, 11:17 am

≫ Next: Follow-up for #2408371: PageCache is 1ms slower due to wrong service pass order

≪ Previous: Views feed doesn't encode embedded HTML anymore

$

0

0

There's a strong argument to be made for applying box-sizing: border-box.

1. It's easier to write fluid layouts, you can do crazy things like width: 80%; padding: 0 10px;
2. Contrib modules can rely on it being applied, which means they don't need to add inner/wrapper divs on things to have reliable styling.

The downside is this will affect every width set by in core and contrib. We implemented this on the D7 version of Bluecheese and came across a few bugs with contrib module CSS. If contrib modules want a responsive admin interface in D8 they are probably going to have to rewrite all their CSS anyway so this probably isn't that big a deal.

Things left to do:

• Move the box-sizing "hack" into system.theme.css.
• Review the new patch again.
• Take screenshots to make sure we don't break anything.
• Move into classy?

Follow-up for #2408371: PageCache is 1ms slower due to wrong service pass order

July 13, 2015, 4:56 am

≫ Next: Add non-HTML placeholder generation to PlaceholderGenerator or a new service

≪ Previous: Apply 'box-sizing: border-box' globally.

$

0

0

Follow-up to #2408371: Proxies of module interfaces don't work

Several little problems:

- Currently middlewares after page_cache are not proxied as the ProxyServicesPass() comes too early to find the dynamic 'lazy' definition.

- The tags are on the wrong service:

<?php
diff --git a/core/lib/Drupal/Core/DependencyInjection/Compiler/ProxyServicesPass.php b/core/lib/Drupal/Core/DependencyInjection/Compiler/ProxyServicesPass.php
index 90b1755..b124f6c 100644
--- a/core/lib/Drupal/Core/DependencyInjection/Compiler/ProxyServicesPass.php
+++ b/core/lib/Drupal/Core/DependencyInjection/Compiler/ProxyServicesPass.php
@@ -29,13 +29,15 @@ public function process(ContainerBuilder $container) {
         if (class_exists($proxy_class)) {
           // Copy the existing definition to a new entry.
           $definition->setLazy(FALSE);
-          // Ensure that the service is accessible.
-          $definition->setPublic(TRUE);
+          $tags = $definition->getTags();
+          $definition->setTags([]);
+
           $new_service_id = 'drupal.proxy_original_service.' . $service_id;
           $container->setDefinition($new_service_id, $definition);
 
           $container->register($service_id, $proxy_class)
-            ->setArguments([new Reference('service_container'), $new_service_id]);
+            ->setArguments([new Reference('service_container'), $new_service_id])
+            ->setTags($tags);
         }
         else {
           $class_name = $definition->getClass();
?>

- Proxies of Symfony components do not work

Proposal, allow to specify proxy class as tag:

  'tags': [
   { 'name': 'drupal_proxy_class', 'proxy_class': '\Drupal\Core\ProxyClass\Symfony\Component\HttpKernel\HttpKernel', }
  ],

- The wrong service ID is on the proxied services, after instantiation the proxy should set the real _serviceID to the one it is itself.

- The generated code lacks coding standards.

- Only for enabled modules proxies can be generated, but there is no error message when a module is not enabled.

Why this should be an RC target

Due to changes of the proxy services, we no longer have lazy middlewares which causes a bit of an overhead for page cache. This is a performance only change,
but could totally be changed afterwards

Add non-HTML placeholder generation to PlaceholderGenerator or a new service

September 3, 2015, 3:17 am

≫ Next: Document common form/render element properties

≪ Previous: Follow-up for #2408371: PageCache is 1ms slower due to wrong service pass order

$

0

0

Problem/Motivation

From #2504139-103: Blocks containing a form include the form action in the cache, so they always submit to the first URL the form was viewed at:

Related to #102, we seem to have a mix of hashing algorithms and seeds for placeholders in HEAD plus this patch:

FormBuilder:
$placeholder = 'form_action_' . hash('crc32b', 'form_action' . $hash_salt);

RouteProcessorCsrf:
$placeholder = hash('sha1', $path);

Renderer:
$attributes = new Attribute();
$attributes['callback'] = $placeholder_render_array['#lazy_builder'][0];
$attributes['arguments'] = UrlHelper::buildQuery($placeholder_render_array['#lazy_builder'][1]);
$attributes['token'] = hash('crc32b', serialize($placeholder_render_array));
$placeholder_markup = SafeMarkup::format('<drupal-render-placeholder@attributes></drupal-render-placeholder>', ['@attributes' => $attributes]);
  
FilterProcessResult:
$attributes = new Attribute();
$attributes['callback'] = $callback;
$attributes['arguments'] = UrlHelper::buildQuery($args);
$attributes['token'] = hash('sha1', serialize([$callback, $args]));
$placeholder_markup = Html::normalize('<drupal-filter-placeholder' . $attributes . '></drupal-filter-placeholder>');

I think a dedicated service for generating placeholders would be good. Perhaps with 2 methods, such as asHtml() (for the cases where the placeholder can be HTML markup, like the bottom two examples above) and asIdentifier() (for the cases where the placeholder needs to appear inside an attribute value and not be altered by functions such as Html::escape(), Html::cleanCssIdentifier(), UrlHelper::stripDangerousProtocols(), etc., like the top two examples). Then such a service could be well documented for why the chosen hashing algorithm and seed have the appropriate level of security.

Proposed resolution

TBD

Remaining tasks

TBD

User interface changes

None

API changes

Only additions

Data model changes

None

Document common form/render element properties

October 22, 2015, 6:40 pm

≫ Next: Fix function docblocks in WebTestBase

≪ Previous: Add non-HTML placeholder generation to PlaceholderGenerator or a new service

$

0

0

Problem/Motivation

We need to document the properties of Form and Render elements that are common to all of them.

Proposed resolution

1. Document the properties that are common to all render elements on the RenderElement class doc header.
2. Document the additional properties that are common to all form elements on the FormElement class doc header.

The documentation can be taken from the current Form API Reference document on api.drupal.org

Also if there are some properties that are common to most form/render elements, they can be documented there now, probably in separate lists from the ones that are all common.

Remaining tasks

Make a patch.

User interface changes

No. API docs only.

API changes

No. API docs only.

Data model changes

No. API docs only.

Fix function docblocks in WebTestBase

October 23, 2015, 3:03 am

≫ Next: Undefined variable 'arg' in core/modules/views/src/Plugin/views/argument_validator/None.php

≪ Previous: Document common form/render element properties

$

0

0

Problem/Motivation

Many of the function docblocks in WebTestBase are incomplete. Some @return missing or incorrect.

Proposed resolution

Review the docblocks and fix any incorrect tags.

Remaining tasks

1. Figure out the correct return types for each method.
2. Roll a patch to fix the docblocks.

User interface changes

None.

API changes

None.

Data model changes

None

Undefined variable 'arg' in core/modules/views/src/Plugin/views/argument_validator/None.php

October 16, 2015, 10:23 am

≫ Next: Make Drupal handle path aliases in a consistent and case-insensitive fashion on all database drivers

≪ Previous: Fix function docblocks in WebTestBase

$

0

0

Hi,
Found undefined variable argument in core/modules/views/src/Plugin/views/argument_validator/None.php.

Solution : Line 31 - Replaced with $argument variable.

Make Drupal handle path aliases in a consistent and case-insensitive fashion on all database drivers

October 8, 2015, 1:45 pm

≫ Next: Write tests to ensure that all classes in Drupal can actually be found by the autoloader

≪ Previous: Undefined variable 'arg' in core/modules/views/src/Plugin/views/argument_validator/None.php

$

0

0

Splitting off part of the work from #2075889: Make Drupal handle incoming paths in a consistent and case-insensitive fashion for routing

Problem/Motivation

Whilst working on #1987898: Convert user_view_page() to a new style controller and #2075889: Make Drupal handle incoming paths in a consistent and case-insensitive fashion for routing we note that path aliases handling will be case insensitive on mysql but case sensitive on pgsql and others.

So on some sites:

/Path/Alias and /path/alias will resolve the same, on other sites one will be a 404

Proposed resolution

we agreed to fix this by keeping most of the existing behavior from Drupal 7.

/Path/Alias- not 404. Same as /path/alias on all supported databases

Remaining tasks

User interface changes

none

API changes

Change the query to the select builder so we take advantage of the ILIKE on pgsql

Data model changes

none

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes

Issue category	Bug because links in D6/D7 sites can break during an upgrade to D8.
Issue priority	Major because previously working links can break during a D8 upgrade. Not critical because: There are workarounds (e.g. .htaccess rules). It can't actually result in any data integrity or security issues, just a whole lot of embarrassing broken links. We might be able to fix it in a patch release safely (but better before release). See #23 for more details.
Disruption	Disruptive for sites running on beta versions that added case-sensitive aliases in Drupal 6-7 or in Drupal 8.

---

Write tests to ensure that all classes in Drupal can actually be found by the autoloader

June 13, 2012, 6:59 am

≫ Next: Add comments for skip link and main-content anchor in templates

≪ Previous: Make Drupal handle path aliases in a consistent and case-insensitive fashion on all database drivers

$

0

0

Problem/Motivation

The new PSR-0 autoloader in Drupal 8 is very fragile in that it requires an exact match between the class name, namespace and location in the filesystem in order to work. If there is a typo in any of those, the class will not be loaded.

For runtime classes, this is generally less of a problem, since if your class fails to load, you'll notice it pretty quickly in most cases (although even then, there are some where you won't, such as those involving dynamic class names that are optionally loaded).

However, for simpletests, this is a major problem. If the class doesn't load, the tests simply won't be run by the testbot at all.... It will be like the test was never written in the first place.

This is more than a theoretical concern, since it's already happened several times. The ones I know about are:

• #1591296: Convert contextual tests to PSR-0 (patch was RTBC before anyone noticed)
• #1598602: Fix the path of Queue tests (patch was committed before anyone noticed)
• #1598552: Move batch tests to the right directory (patch was committed before anyone noticed)

and, one more special one...

• #1598620: Convert uuid.test to PSR-0 (nobody noticed yet - the patch in this issue actually reveals the bug!)

Proposed resolution

Write a test that looks through the "lib" directories of all core modules and ensures that all classes which it finds there can actually be found by the PSR-0 autoloader.

Remaining tasks

An initial version of the patch is already written and will be attached in the first comment.

It should work as is, but currently only runs on core modules and isn't easily extensible. We should consider refactoring it into a helper class (to run the tests on a set of locations in the filesystem) and a subclass (to specifically run the test on core modules). This would allow us to also use this to test the "core/lib" and "core/vendor" subdirectories (thereby making the Symfony autoloading tests in #1598610: Convert symfony.test to PSR-0 and remove all the files[] instances in system.info obsolete), as well as core themes, etc. It would also be possible to test all contrib modules on a particular site with this too.

Also, this test is going to use up a lot of memory (since it loads up pretty much every file in the codebase and checks them for classes). If that's a concern, we could break it up into separate test classes, perhaps, each only doing a subset of modules.

This should be backportable to Drupal 7 also, although it's less necessary there since the class registry is less fragile in this regard. But if you forget to list a new test file in the .info file, the same kind of problem can occur, so it wouldn't hurt to backport.

User interface changes

None.

API changes

None.

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes

Issue category	Bug since it happened that automated tests were skipped
Issue priority	Major because it will help to prevent regressions
Unfrozen changes	Unfrozen since this is a change in automated test
Prioritized changes	Prioritized as a bug fix
Disruption	No disruption

Add comments for skip link and main-content anchor in templates

December 31, 2011, 7:21 am

≫ Next: Mismatched entity and/or field definitions after upgrade from RC1 to RC2

≪ Previous: Write tests to ensure that all classes in Drupal can actually be found by the autoloader

$

0

0

What is the main-content and why is hidden.

seven theme page.tpl.php:

   
<div id="content" class="clearfix">
      <div class="element-invisible"><a id="main-content"></a></div>
      <?php if ($messages): ?>
        <div id="console" class="clearfix"><?php print $messages; ?></div>
      <?php endif; ?>

Mismatched entity and/or field definitions after upgrade from RC1 to RC2

October 26, 2015, 12:18 pm

≫ Next: Comment field may not be added (no comment type avaliable to select)

≪ Previous: Add comments for skip link and main-content anchor in templates

$

0

0

Updating from RC1 to RC2 result in:

Entity/field definitions Mismatch detected
Mismatched entity and/or field definitions.

No modules other the core ones are enabled.

Comment field may not be added (no comment type avaliable to select)

October 26, 2015, 9:01 am

≫ Next: Add static cache to module_load_include()

≪ Previous: Mismatched entity and/or field definitions after upgrade from RC1 to RC2

$

0

0

I have set up a comment type.

Image may be NSFW.
Clik here to view.

However I may not add this comment type as a field, the respective list is blank.

Image may be NSFW.
Clik here to view.

Add static cache to module_load_include()

February 16, 2012, 3:39 pm

≫ Next: References to CSS, JS, and similar files should be relative to server

≪ Previous: Comment field may not be added (no comment type avaliable to select)

$

0

0

Problem/Motivation

Function calls require_once so using drupal_static() and clearing this static is pointless.

On cache flush:

Before:

Total Self: 94ms
Total Cumulative: 163ms
Calls: 2,982

After:

Total Self: 49ms
Total Cumulative: 72ms
Calls: 2,982

Total savings ~90ms.

Proposed resolution

Add static cache to module_load_include()

Remaining tasks

Contributor tasks needed

Task	Novice task?	Contributor instructions	Complete?
Profiling		Instructions
Update the issue summary noting if allowed during the beta		Instructions
Review patch to ensure that it fixes the issue, stays within scope, is properly documented, and follows coding standards		Instructions

User interface changes

API changes