Hello.
I just noticed image styles do not apply to the images I uploaded to a private folder. It just opens original image file. At the same time the same image style works as expected with images from public directories.
Thank you.
↧
Image styles do not apply to the pictures uploaded in private directories
↧
In the documentation, change all instances of "url" to "URL".
Problem/Motivation
Proposed Solution
In the documentation, change all instances of "url" to "URL". Under '/core/modules/' folder
↧
↧
Move views/includes/ajax.inc to a class in views_ui module
the only function in this file is used by views_ui module only
↧
Remove fields that do nothing from the "RSS publishing" settings form
Problem/Motivation
The "RSS publishing" settings form allowed users to change basic rss feed behaviours on Drupals prior to version 8. Drupal 8 now uses a view to provide the front page /rss.xml feed link. This view does not use the rss form settings, which is confusing for users.
Proposed resolution
Remove the admin/config/services/rss-publishing form.
Remaining tasks
- Fix the patch:
- Change update from 8014 to 8100
- Fix the syntax error (trailing left brace) in update 8013.
- Add content to the empty docblocks
- Change the 8.0.0-rc1 doc block to 8.0.0, and add 8.1.0 update docblock
User interface changes
API changes
Original report by @cafuego
↧
Failed to execute 'contains' on 'Node'
Problem/Motivation
The solution for this issue #2561619: Drupal Ajax objects and settings grows endlessly lead previously to errors in contrib modules like the one we fixed here #2673824: Views JS passing wrong type of object to Drupal.ajax.
But due to other possible errors in contrib that issue was rolled back in 8.0.x, but I found a related error that breaks in 8.1.x due to that change, you can see it here: https://github.com/dpi/courier/issues/21 maybe in other modules.
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
↧
↧
Implement ContainerAwareEventDispatcher::getListenerPriority()
When we updated to Symfony 2.8 in #2611816: Update to symfony 2.8 we didn't implement the getListenerPriority() method on ContainerAwareEventDispatcher, probably because it was not required on the interface.
Unfortunately the omission of this method on the interface is a bug in Symfony, since the method is being actively used. This has been fixed in Symfony 3.0 in Issue #16301: [EventDispatcher] add method getListenerPriority() to interface but it is not clear if this will be backported to 2.8.
Marking this as a bug since it is already breaking contrib (e.g. #2682343: Fatal error enabling web profiler on 8.1.x). We'll have to implement this anyway before Drupal 8.2.x which will depend on Symfony 3.0, but it would be good to have this in earlier.
↧
Update Doxygen for \Drupal\Component\DateTimePlus
Problem/Motivation
The doxygen on \Drupal\Component\DateTimePlus are out of date and do not match the type signature for the functions in the class. These need to be fixed.
Proposed resolution
Update doxygen for
\Drupal\Component\DateTimePlus::createFromDateTime()\Drupal\Component\DateTimePlus::createFromArray()\Drupal\Component\DateTimePlus::createFromTimestamp()\Drupal\Component\DateTimePlus::createFromFormat()\Drupal\Component\DateTimePlus::prepareTime()\Drupal\Component\DateTimePlus::prepareTimezone()\Drupal\Component\DateTimePlus::prepareFormat()\Drupal\Component\DateTimePlus::hasErrors()\Drupal\Component\DateTimePlus::getErrors()
Remaining tasks
Fix remaining instances.
User interface changes
None.
API changes
None.
Data model changes
None.
Release Eval
This is a simple documentation improvement, so it should be eligible to be in a patch release per the allowed changes policy.
Original report
While working on other issue I spotted incomplete doxygen comment. Having fully specified function description helps prevent unhandled exception cases, so here is a
simple patch.
↧
Rename Drupal Upgrade UI to Drupal Migrate UI
Problem/Motivation
#2701027: Drupal 8 UPGRADE.txt is misleading in many ways (in its name to begin with) reminded me how often people get confused between update and upgrade. This confusing is reasonable since they don't really mean anything different outside of Drupal.
However we've just added 'Drupal upgrade UI' which is a user interface for migrate/Drupal Migrate.
Additionally, if we eventually add Drupal 8 sources, it might be possible to migrate from Drupal 8 to Drupal 8, which is not an upgrade. I don't know if we'd ever want to allow that via a UI shipped in core, but it'd be possible to do if we wanted to.
Only a very small proportion of sites will be able to simply install Drupal 8 and 'upgrade' from Drupal 6 or 7 without further work. In the majority of cases they'll also need to re-install themes and contrib modules as well. So whatever happens it's a migration to a new install, not an upgrade of an existing install (which arguably 6-7 upgrades still are since with those at least you theoretically could keep the same git repo and have it make some degree of sense).
Proposed resolution
Rename the module to 'Migrate Drupal UI'.
Remaining tasks
User interface changes
API changes
Data model changes
↧
Menu link overrides are lost after cache rebuild
Problem/Motivation
Views provided menu links are lost after cache clear/rebuild because the changed config is not stored in core.menu.static_menu_link_overrides. I wrote a test case to explain the issue.
Proposed resolution
Add options for expanded/enabled to the config schema so that their status gets stored.
Don't provide a UI though - this is just to preserve them.
Remaining tasks
User interface changes
API changes
↧
↧
Improve unit test coverage for AssetResolver
Problem/Motivation
#2603138: CSS/JS asset caching can easily be trashed shows we have almost zero test coverage, and adds some basic tests.
This issue is for expanding the unit tests to have proper coverage.
Proposed resolution
Moar tests.
Remaining tasks
User interface changes
API changes
Data model changes
↧
"unpublished" status of rendered entities is not accessible (and looks bad)
Problem/Motivation
"unpublished" status of rendered entities is not accessible (pink too hard to notice for some) (and looks bad)
blocks #2290101: UI telling you a field is shared across languages is way too subtle
RC phase evaluation
| Issue category | Bug because there is an accessibility violation. Even for sighted people with good vision, the light pink background is difficult to see. For someone with low vision, there is no distinction. For someone using a mobile device outside, they won't be able to distinguish between published and unpublished content. For a blind user, there is no indication that a node is unpublished. |
|---|---|
| Allowed in RC | Because it fixes an accessibility bug, unblocks another issue and sets a good pattern. It also isn't a disruptive change. |
| Changes the data model (upgrade path), translatable strings, markup, CSS, user interfaces, render array structures, third-party libraries, etc.: postpone it to 8.1.x. | Minor CSS Changes on a few admin pages. |
| Disruption: Fixes a bug, blocks a contributed project, or should be backported to Drupal 7 | Not disruptive and fixes an outstanding accessibility & usability bug. |
Proposed resolution
Add a marker to nodes & comments to ensure that the published/unpublished state is semantically defined.
Enhance the visual representation of the unpublished content so that it is more distinct.
Remaining tasks
| Task | Novice task? | Contributor instructions | Complete? |
|---|---|---|---|
| Update the patch to incorporate feedback from reviews (include an interdiff) | Instructions | ||
| Embed before and after screenshots in the issue summary | Novice | Instructions | (done, but might need redone if changes to head or patch are big enough) |
| Review patch to ensure that it fixes the issue, stays within scope, is properly documented, and follows coding standards | Instructions | do as needed |
User interface changes
CSS changes are suggested.
before
This example has an unpublished node, with an unpublished comment.
after
See more in #201
before markup
draft image
Comments
Wed, 10/07/2015 - 19:58
after markup
article body
Comments
unpublished
Thu, 10/15/2015 - 19:00
API changes
None.
Original report by @joshk
I really like this change: #394736: Unpublished node's pink background unclear
As the pink background is just too hard too see. This is the same issue as for unpublished comments as well!
Why this change should be committed during RC
A color based signifier for content state is not accessible or intuitive for any users.
↧
Ajax Callback retun new form element value is not available in $form_state when get submitted.
Problem
I have added a field through ajax callback [returning a render array of the new form element] , But the values are not available on $form_state when get it submitted.
↧
Remove current path parts from theme suggestions
#788900: Deprecate and remove usages of arg() reminded me that we still generate theme and template suggestions based on path, for example page--node--1.tpl.php
The problem
Now that most code in core is based on routes, someone could change /node/% to /content/% and your theme would break. This makes those suggestions impossible to use in contrib themes since they can't work generically.
Additionally HTML head is one of the least-cacheable parts of the page in 8.x, and per-path suggestions will make it harder to cache that HTML.
Also these suggestions are a bit broken in D8 in the first place, they include a suggestion with a percent character:
<!-- THEME DEBUG --><!-- THEME HOOK: 'html' --><!-- FILE NAME SUGGESTIONS:
* html--node--2.html.twig
* html--node--%.html.twig
* html--node.html.twig
x html.html.twig
--><!-- THEME DEBUG --><!-- THEME HOOK: 'page' --><!-- FILE NAME SUGGESTIONS:
* page--node--2.html.twig
* page--node--%.html.twig
* page--node.html.twig
x page.html.twig
-->Proposed solution
Remove the automatic theme suggestions based on path parts.
Why this should be an RC target
1. This is code removal only.
2. In general, contrib themes never use the per-page suggestions (and if they do they're fragile), they're sometimes used by custom themes (and often incorrectly when block configuration, page manager or similar would be a better choice). So the disruption in terms of number of themes using the feature should be low.
3. New theme developers sometimes use this 'by mistake' instead of the better options in #2, which can lead to custom themes with 10-15 page templates all with minro variations, this is one of the worst maintenance issues with custom themes in the wild.
4. Also themes can add back the suggestions by copying the removed code to template.php.
5. While templates using the suggestions won't be picked up, there's no other disruption to actual sites from the change in terms of errors etc. even if they're using the feature, which 99.9% won't be.
↧
↧
Simplify Dropbutton markup inline with our CSS standards
Problem/Motivation
The current markup for Dropbutton looks like this:
<div class="dropbutton-wrapper dropbutton-processed dropbutton-multiple"><div class="dropbutton-widget"><ul class="dropbutton"><li class="edit dropbutton-action"><a href="/admin/structure/views/view/content">Edit</a></li><li class="dropbutton-toggle"><button type="button"><span class="dropbutton-arrow"><span class="visually-hidden">List additional actions</span></span></button></li><li class="clone dropbutton-action secondary-action"><a href="/admin/structure/views/view/content/clone">Clone</a></li><li class="disable dropbutton-action secondary-action"><a href="/admin/structure/views/view/content/disable?token=hQ2egsGF5LtsScdw2oQFeoWNKrUi1HHP9W1WZhjehOk" class="use-ajax ajax-processed">Disable</a></li><li class="delete dropbutton-action secondary-action"><a href="/admin/structure/views/view/content/delete">Delete</a></li></ul></div></div>There's a lot we could do we simplify and improve the markup so it's inline with our CSS coding standards
Proposed resolution
<div class="dropbutton dropbutton--modifier"> <!-- whole component is dropbutton. --><a class="button dropbutton__action">Action One</a><button type="button" class="button dropbutton__trigger"><span class="visually-hidden">List additional actions</span></button><ul class="dropbutton__menu" role="menu"><li><a class="dropbutton__action">Action Two</a></li><li><a class="dropbutton__action">Action Three</a></li></ul></div>Remaining tasks
Decide on a battle plan of improvements
Write a patch
Test a lot
User interface changes
None
API changes
Mark up changes
↧
dropbutton with a single option missing its rounded corners
With Workbench Moderation module, it's possible for a node to only have one option in its save dropbutton -- you have to publish a node, then archive it, then edit that again.
When the dropbutton has only one option, the rounded corners are missing.
↧
Move theme quickedit CSS to the Seven theme
Problem/Motivation
See discussion in: #2195695: Admin UIs on the front-end are difficult to theme
See: #2489460: [Meta] Move module.theme.css files to Classy or Seven
Quickedit is an administrative UI component that appears on the frontend of sites. It's important that they are consistent with the Seven style guide and that other admin themes can control the look and feel.
Proposed resolution
Our CSS standards define module CSS as: “the minimal styles needed to get the module's functionality working.”
Theme CSS is defined as: “extra styles to make the module's functionality aesthetically pleasing. ”
Move the theme styling into the Seven theme
Add a library alter hook to load the admin theme CSS. Example: #2341221: Node preview has usability issues, is difficult to use on mobile, not usable without Bartik, and does not align with the Seven style guide and current toolbar designs
Remaining tasks
Write the patch.
Test.
User interface changes
None
API changes
None
Data model changes
None
↧
Drupal.ajax.expired not sufficiently defensive
The Drupal.ajax.expired function in core/misc/ajax.js is not sufficiently defensive: Namely, it loops through object members calling a contains() without first checking that said method exists; with the result, that if custom code adds unexpected members it causes AJAX requests to fail with a message like this:
In Chrome:
Uncaught TypeError: Failed to execute 'contains' on 'Node': parameter 1 is not of type 'Node'.
In Firefox:
TypeError: Argument 1 of Node.contains does not implement interface Node.
Possibly related to #2673824: Views JS passing wrong type of object to Drupal.ajax
↧
↧
Using token views to rewrite css output causes Twig_Error_Syntax, "Unexpected token "end of template" of value " in Twig/ExpressionParser.php line 190
Using D8-beta13 I attempted to use a token in a view to rewrite the CSS output:
To reproduce:
- Add text field (plain) to a view.
- Under Style Settings in the field configuration, select 'create a css class'
- Insert:
something-{{ field_fieldname }} headingwhere '{{ field_fieldname }}' is the replacement token grabbed from the 'rewrite results' section. - Save
- Load a page with this view on it (in my case, it was a page displaying the blocks of the view.
Expected:
Line would be enclosed in css like this: <i something-fieldcontent heading>whatever</i> This does not fail in the view preview. It renders as expected there. However,
When a page with the block/view is loaded, the "website encountered an unexpected error". Console output shows:[Thu Jul 30 16:52:36.495200 2015] [fcgid:warn] [pid 17226:tid 3015823360] [client 127.0.0.1:52474] mod_fcgid: stderr: Uncaught PHP Exception Twig_Error_Syntax: "Unexpected token "end of template" of value "" in "{# inline_template_start #}something-{{" at line 1" at /core/vendor/twig/twig/lib/Twig/ExpressionParser.php line 190, referer: http://local.site/admin/structure/views/view/services
Note:
1. The same replacement token works without error in the "Rewrite Results" section. I.e., when no css is involved.
2. CSS replacement works if it does not contain the token.
↧
Views Exposed Filters or Paging with Ajax Only Works on First Click
After specifying that Ajax is to be used for a View for either paging or an exposed filter, it only works once after a page refresh. All subsequent clicks on the links to page forward, backward, etc. or the Apply or Reset button of an exposed filter result in nothing happening. There are no messages and no indication that the second click is processed. If I refresh the page, it will work one time again.
If I disable Ajax on the View, all does work as expected. That is the current work around.
I've also tried this on 8.0.5 with the same results. It does not appear to be a new issue with 8.1.x.
↧
core/composer.txt may no longer be required
Follow-up to #2701969: core/composer.txt is out of date
Problem/Motivation
core/composer.txt lists libraries we officially depend on. Now that depencies are built via composer rather than committed to the git repo, this can be inferred. Removal of this file means it would no longer have to be maintained.
Proposed resolution
Remove the core/composer.txt file.
Remaining tasks
None
User interface changes
None
API changes
None
Data model changes
None
↧
what
what?