Problem/Motivation

For proper render caching it is very important that not only the markup is saved, but also the accompanying assets ('#attached').

Currently both the block cache and Drupal core's render cache do loose attachments during the cache process.

While drupal_render_collect_attached() tries to mitigate this problem, it has several edge cases where it fails to work, mainly in the interaction with the theme system (early rendering) and it only works if no custom or contrib code ever calls drupal_add_js() / drupal_add_css(). (which in 2016 still has not happened)

Proposed resolution

The reason this is happening is that Drupal 7 mostly still relies on global state for adding attachments (drupal_add_*).

The idea to resolve this is to use a standard subscriber-pattern to collect these global state calls as attachments.

The caching code is then responsible to collect the Attachments that have been added after the cache miss until the cache is finally set.

The API looks like this:

$attachments_collector = new DrupalAttachmentsCollector();
// ... do the work to render the things ...
$attachments = $attachments_collector->getAttachments();
unset($attachments_collector);
// ... now store the attachments in the render array

This also allows views or other modules that used a diff based approach to collect attachments, to properly work and is also e.g. very useful for row based views caching.

Remaining tasks

- Port the relevant part of #2754245: [META] Explore how to backport render context and #cache properties from Drupal 8 to empower contrib to this issue.
- Fix documentation
- Get reviews
- Commit

User interface changes

- None

API changes

- Only API additions

API page: https://api.drupal.org/api/drupal/core%21core.api.php/group/form_api/8.2.x

Enter a descriptive title (above) relating to Form generation, then describe the problem you have found:

The following statement is wrong:

The argument to \Drupal::formBuilder()->getForm() is the name of a class that implements FormBuilderInterface.

It should be:
The argument to \Drupal::formBuilder()->getForm() is the name of a class that implements FormInterface.

Problem/Motivation

Currently, outside_in_contextual_links_view_alter() hardcodes a single contextual link as using offcanvas.
Any other links to be added will need the same logic.

Proposed resolution

Make it easier for contextual links to opt-in to being displayed in a dialog.
In #2784443: Move off-canvas functionality from Settings tray module into drupal.dialog.ajax library so that other modules can use it, make this available for all contextual links and all dialog/modal options.

Remaining tasks

User interface changes

API changes

Data model changes

In D8 now you can use CKEditor to add an image caption. This properly wraps an image in a figure/figcaption element. I do think this would be a useful option for the image system. It would also make the UI more consistent.

If this is done though, we'd need to keep in mind from the W3C"An image is contained within a figure element and has an associated caption provided using the figcaption element. Using an empty alt attribute hides an image from some users. If an image has a caption the image needs to be discoverable by users, otherwise a caption is present that refers to nothing for some users."

Some screenshots of what it could look like (and I added figure/figcaption here too)

Made with gimp sadly

Made properly with Firebug

Problem/Motivation

The CKEditor toolbar configuration UI (seen at e.g.admin/config/content/formats/manage/full_html is very hard for sighted keyboard-only users to use. The available buttons CAN currently be moved in and out of the active toolbar, but keyboard focus is not indicated to the user, which makes it practicallly impossible to know which button you are dealing with.

This issue is part of our goal of meeting WCAG 2.0 level AA, specifically Success Criterion 2.4.7. Focus Visible.

This is a follow-up to #1872206: Improve CKEditor toolbar configuration accessibility. Accessibility of toolbar configuration for screen reader users was previously addressed there.

Before:

After (Well BarisW's first stab):

Proposed resolution

Add some Clear keyboard focus styles to the CKEditor toolbar configuration UI.

The scope of this issue is specifically about the experience of sighted keyboard users. It does not propose to change the screen reader experience.

Remaining tasks

• Decide how to style the keyboard focus. Should not use colour alone.
• Write CSS. Ensure it works in Seven theme (and Bartik?)

User interface changes

Adds keyboard focus styles for the CKEditor "Toolbar Configuration". Exact styles not yet decided. The design impact aims to be minimal, by only providing a focus style specific to the CKEditor admin UI.

API changes

None.

Data model changes

None.

I am going to keep this short, I am very new to Drupal.

Theme: Writer (should have no implication). View: I only changed the Frontpage View from Teaser to Full Page. This is a new site, very fresh install.

I changed a few blocks. Just content location. Assignment. Nothing special.

I added a test article and removed it.

I then added two new Articles. One after the other. Then I went to the second and changed the publication date to one day back. Then I went to the first and changed the publication date to one day back. The second one had 2 revisions, I deleted the first at some point.

Now at this point the first article had a later update time and showed above the second article [ for clarity, I mean in the content view]

I now added some 3 more posts, regular writing and posting.

I refresh the page. The front page lists full articles. I notice that the 2nd post (penultimate post on display, vertically in the list) does not have a Title!!!

It does not display a title. All the other posts have title. This post has a title too, but it does not show. I check the HTML and the (inspector) elements.

Other posts have a [h2] header (writing bracketed for convenience) but this one has no h2 header.

For no reason? I go into the content area. I go into the 2nd post (that has the earliest modification time) and update its publication time with a few seconds (later) so that it gets updated now after the first post. Now after this the 2nd post is displayed on top.

I refresh the page or go back into the view of the website. Now the H2 header does show and the title is visible again.

I have no other modules installed and this is a completely fresh install with the default set of modules. I don't think the theme should have any influence. The anomaly did not occur before (when there were fewer posts. Total number of posts when all of this happened: 4. This is a bit of a test site. All posts are Articles. So:

Display was:

Post 4
Post 3
Post 2 (missing title)
Post 1

Update order was:

Post 4 (newest)
Post 3
Post 1
Post 2 (oldest)

Creation order was:

Post 4 (newest)
Post 3
Post 2
Post 1 (oldest)

After updating post 2 and putting the time a little ahead (added some 4 seconds to it) the update order was:

Post 2 (newest)
Post 4
Post 3
Post 1 (oldest)

When I say I will keep this short I mean I will not do any troubleshooting for you. The problem is now gone (for now) and I am not willing to do reproduction work here.

Regards.

Updated: Comment #334

Problem/Motivation

Currently, when a node table is left joined into a query, adding a node_access tag to the query filters out accessible rows from the base table (effectively acting more like an inner join). In particular, rows containing null values are incorrectly filtered out by node_access (i.e., if the base table has null entries for the node ID, node_access denies access to all users based on those null values, even though they should have no relevance to node_access checks). The most common example is a view where rows disappear from the table after adding an optional relationship to the view.

See the tests in patch #326 to reproduce, or more manually in D7:
1. Install Entityreference and Views,
2. Create a field referencing nodes (using entityreference),
3. Create a node having the entityreference field empty,
4. Create a View with a relationship using the entityreference field. Do NOT select "Require this relationship".
5. Expected result is that regular users can see the node in the View. Current result is that regular users cannot see the node.

Proposed resolution

The problems can be fixed by altering how the node_access conditions are added into the query whenever the node table is a joined table. Currently the conditions are added to the overall query conditions; the proposal is to instead add the node_access conditions into the join conditions.

This approach maintains the integrity of the node_access checks: all nodes to which the current user is denied access are removed from the query results. However, it makes as few additional changes as possible to the query results.

The primary effect is that rows containing optional, empty (null node ID) entries are no longer removed. Furthermore, if rows contain optional (left-joined) content from an access-denied node, only the content of the denied node is removed from the results. In the context of a view, this means that any individual cells of a table containing restricted content will be blanked, but non-restricted content in the rest of the row is still visible to the user.

Adding the node_access conditions into the join conditions is made more difficult by limitations of the database API: #2275519: Unable to use Condition objects with joins. The current patch has opted to add this missing feature to the database API, instead of implementing more complex code that tries to work around the limitation.

Both D8 (#326) and D7 (#332) patches implementing this approach have been provided.

Remaining tasks

1. Patch needs to be reviewed by the community. Earlier patches (in particular D7) were extensively reviewed, but more feedback on the current patch is needed. Some specific recent questions include:
   1. Is the current patch, which avoids an API change, preferable (see #321)?
   2. Is it appropriate for a bug-fix patch to incorporate code for a requested feature (see #319)?
   3. Are there use cases that cannot be handled by patch #326, and would instead require patch #302? (See also Detailed Example)
2. Write tests.(Patch #326 contains comprehensive tests, including nested joins and all combinations of accessible and restricted content.)
3. In Postgres with 3 node tables and a count query, placeholders are getting inserted in the wrong sequence.(This was an issue for patch #149 but was reported as fixed by a subsequent patch. The current D8 patch doesn't edit the placeholders, and has been tested successfully using PostgreSQL.)
4. Address issue of node access with a type of "entity" -- no known cases where this bug is triggered, recommend creating new issue.(The entity-specific query alterations have been removed in D8, making the issue no longer relevant.

User interface changes

None

API changes

None

Data model changes

None

Detailed example

As an example, a site has 'page' nodes containing a field that is a reference to a related 'article' node. A view is created to list the page nodes: the page title is shown in the first column; the related article's title is shown in the second column (using an optional relationship). The following is the view as seen by an admin. Any node with 'public' in the title is visible to everyone; any node with 'private' in the title should not be visible to regular users.

With current code, the table shown to non-admins incorrectly removes some rows containing public pages:

With patch #326, regular users will see:

All private pages and private articles have been filtered out. Public-page-3 is still displayed because it is public content; the reference to private-article-b is in an optional column, implying that unavailable content should result in a blank cell instead of removing the entire row.

Some users may prefer to construct a view where the entire row is removed if it contains a reference to an inaccessible article. In many cases, such views will simply want to change the article column into a required column. If, however, it is necessary to keep rows with missing articles, and only filter rows with inaccessible articles, users can add the appropriate filter into the view, for example, "where article_title is null AND article_reference is not null". This would produce:

Note that one proposed patch, patch #302, uses a different approach that directly produces Case D, without the need for additional filters. However, using patch #302 it is impossible to produce Case C (except by gutting the node_access checks). In other words, patch #326 can be used to handle all reported use cases, but patch #302 cannot.

Original report by [username]

I'm loving the Entity Reference module, but I've come across some weird behavior. It's probably just something I've missed setting.

I have a content type called Album. I've got another content type called Review which has an entity reference to Album.

I've created a View which lists Albums. I wanted to include some fields from my Review content type, but I still want to list each Album, even if a review referencing the album has not been created yet.

In my view, under Relationships, I add an "Entity Reference: Referencing entity" relationship. I make sure "Require this relationship" is NOT checked.

When I'm logged in as an administrator, all Albums are returned, as expected. But when I'm not logged in, or I'm logged in as a regular user, only albums that are referenced by a review are displayed. I'm really puzzled as to why I get different results depending on my user role.

I get the same results regardless of if I add fields from the Review content type or not. I've tried clearing the cache multiple times, and I've tried checking and unchecking the "Require this relationship" box. I've deleted the relationship and tried adding it again, but I always get the same results.

I feel there should be ability to select time only option for timestamp. For example if i want only time field and no date, like timefield module.

In a current project since upgrading to 8.2.2 the following code which applies an active-trail class no longer works. While trying to debug this issue I pasted the menu template into the stark theme.

When changing themes without rebuilding cache the active trail works as expected, however once I cache-rebuild the active trail no longer works. I can then switch back to my project's theme and the active trail works as expected until I rebuild cache.

Here is the code I'm working with ( which is from classy theme):

    {% for item in items %}{%
        set classes = ['menu-item',
          item.is_expanded ? 'menu-item--expanded',
          item.is_collapsed ? 'menu-item--collapsed',
          item.in_active_trail ? 'menu-item--active-trail',
        ]
      %}

When I try to access basic site information i get this error

"Message InvalidArgumentException: Source path has to start with a slash. in Drupal\Core\Path\AliasManager->getAliasByPath() (line 186 of /home2/myfolder/public_html/Mysite.com/core/lib/Drupal/Core/Path/AliasManager.php)."

in the error log

Right now, upload progress only works if you're running in mod_php mode (with the PECL extesion uploadprogress). Sadly mod_php only work with Apache.

PHP >=5.3 has a built-in upload progress http://php.net/manual/en/session.upload-progress.php than we should support.

I have a content type with a date field and when I create a new node of this type the edit form shows the date picker when I click on the date field to edit it. All is good :)

Now.. if I open the form in a modal using class="use-ajax" and data-dialog-type="modal" on the link then the form loads in a modal and is fully functional apart from the date picker is not displayed when clicking on the date field.

Do I need to attach some js to the modal or should this work automatically?

Thanks.

Problem/Motivation

For better compatibility with existing Simpletests we should try to provide assertFieldByXPath(), but mark it as deprecated. That way we need to change fewer parts of a test when converting from Simpletest to BrowserTestBase.

Proposed resolution

Implement the method, test it in BrowserTestBaseTest.

Remaining tasks

Patch.

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

After #2749955: Random fails in UpdatePathTestBase tests, we are continuing to see random fails in UpdatePathTestBase tests. For example, from #2627512-139: Datetime Views plugins don't support timezones:

https://www.drupal.org/pift-ci-job/532197

https://www.drupal.org/pift-ci-job/532126

https://www.drupal.org/pift-ci-job/532196

https://www.drupal.org/pift-ci-job/532198

When you look at these reports, there isn't a clear symptom other than

fail: [Browser] Line 248 of core/modules/system/src/Tests/Update/UpdatePathTestBase.php:
GET http://localhost/checkout/update.php/start?id=2&op=do_nojs returned 0 (0 bytes).

fail: [Other] Line 263 of core/modules/system/src/Tests/Update/UpdatePathTestBase.php:
Schema key block.block.bartik_login:settings.cache failed with: missing schema

at some point in the output.

Given the recent work that has gone into test isolation (need links to the related issues) for APCu, database, and filesystem collisions during parallel tests, these new fails more baffling.

Proposed resolution

Until this can be isolated, I think we need to consider two radical options

- Disable parallel tests
- or Force a fresh testbot for each full run

that should(?) point us in the right direction.

Remaining tasks

User interface changes

API changes

Data model changes

Steps to reproduce

1. Go to admin/config/people/accounts
2. Navigate to REGISTRATION AND CANCELLATION > When cancelling a user account
3. Inspect the radio buttons. Seeing that aria-describedby="edit-user-cancel-method--description" which edit-user-cancel-method--description doesn't exists.

Those 3 radio buttons don't have any description. So I think they don't need to have aria-describedby attribute.
For example, in REGISTRATION AND CANCELLATION > Who can register accounts?, the radio buttons don't have aria-describedby attribute since they don't have description.
However, the description below (Users with the Select method ...) is a description of the fieldset wrapper.

Hello,

I need to be able to apply bulk operation on taxonomy terms (and files, it will be another issue). I saw that VBO is implemented only for nodes and users.

I didn't see any opened issue on this subject.

I will try to provide a patch for that.

Problem/Motivation

admin/content/filesis currently a view, but it is no VBO view, so for example mass-deletion is not available.

Proposed resolution

Add a bulk form to that view, similar to admin/content

Remaining tasks

User interface changes

API changes

Given the most recent PSA: https://www.drupal.org/psa-2016-003 and diving into the workings of why it happened, brought the idea up that "maybe" Drupal needs to create a secured temporary file directory within /files that is only accessible to Drupal and the webserver (not public).

With PSA-2016-003 and the public file system, "if" a file is allowed to upload by anonymous (or anybody who can upload a file really), a temporary file is created and accessible to the public. This creates an open door for anyone to access provided they have the URL. To mitigate the problem, the site builder must either convert the entire file system to private, otherwise it is left up to each individual module to provide a private upload method that can be different than the sitewide public method.

What I propose to mitigate this problem in the future, since Drupal itself is not mitigating this, is to have Drupal either create a temporary /files/tmp folder that is not accessible to the public where all tmp files are subsequently stored, or, create some sort of hash on the uploaded temporary file that is impossible for the uploading party to decipher. For the example of image.jpg, it would be uploaded and renamed to GbJvyf-image.jpg. (IMO, they should be hashed last, after they are sanitized through modules like transliteration) This method would require some obvious DB overhead within Drupal to maintain and properly deal with the hashed files, then remove the hash and rename them once they are permanently placed.

If the secured /files/tmp directory is used, I believe securing this folder across various website servers and hosting platforms might be somewhat difficult to accomplish. (apache vs nginx vs lightspeed etc).

The main idea of this is to allow anonymous and authenticated uploads by any module, but secure those temporary files until the system has decided what needs to happen with it.

Without some sort of security measure in place on this matter, it doesn't matter if the user is trusted or authenticated because they can still mitigate this security hole. Since temporary files are not logged (that I know of), there is no way for a site builder to even know that a trusted / authenticated user is out there uploading files with the sole purpose of mitigating this security hole and if cron is set to run at a longer interval, those files can potentially be indexed and accessible out in the wild for quite some time.

Drupal doesn't support other calendars, Solar Calendar(Gregorian calendar)
here is some works for supporting it using a module. However, it needs a custom hook to be added, which means editing common.inc

Drupal did a great job supporting RTL languages and include many translations. Now we need to step it up in 8.x
I basically added the custom hoon into common.inc
If you have a better way please do inform me.
PS: this hook can be used for all kinds of Calendar systems, more info http://drupal.org/project/calendar_systems

Problem/Motivation

Per Gabor in https://drupal.org/node/2272363#comment-8822223 I implemented translatable configuration in a way how it was not intended by the design. What a lot of people need is the ability to have configuration per language. As maintainer of a Google Analytics I thought this is the way how I can allow my users to use independent UA codes per language. We had this already implemented in D7 with variables module.

Proposed resolution

Allow definition of translatable settings, but also block POTX from extracting them as translatable string to l.d.o. We could add a new key like translation_export: false to help POTX.

    account:
      type: string
      label: 'Web Property ID'
      translatable: true
      translation_export: false

Remaining tasks

Write patch.

User interface changes

None

API changes

Maybe