If revisions are enabled and a media item is changed on later revisions, it's no longer possible to delete the original media item from the library, despite removing all revisions or the node in it's entirety.
The media item is added to the node using an image field.
Steps to reproduce:
Create a node and add media
Create a new revision and change the media
Delete the node
The original media item will remain in the library and cannot be deleted
Since 8.0, I have problem uploading images to posts/image field. The images upload successfully but the thumbnail for those images is not created. The images are stored in files/yyyy-mm/file.name or files/default_images/file.name. The thumbnail which should be in files/styles/thumbnail/public/yyyy-mm/file.name or files/styles/thumbnail/public/default_images/file.name do not exist. Actually, the files/styles is empty. Flush thumbnail image does not help.
There is no error related to the issue in log file.
My server is running:
Drupal 8.1.1
Nginx 1.8.1
PHP 5.6.19
MariaDB 10
Realname module alters the display name, but at user/1234 the username is shown. This is incorrect.
SafeMarkup::checkPlain is going to depreciate.
Will be removed before Drupal 9.0.0. Rely on Twig's auto-escaping feature, or use the #plain_text key when constructing a render array that contains plain text in order to use the renderer's auto-escaping feature. If neither of these are possible, \Drupal\Component\Utility\Html::escape() can be used in places where explicit escaping is needed.
$url->toString(TRUE)->getGeneratedUrl()
Seriously, what does TRUE even mean.
Add $url->toGeneratedUrl()
The bulk operation drop-down menu on the Content page /admin/content and the User Pages /admin/peopleis labelled "With selection".
This doesn't fit the function of this field, because it is not filtering anything (as it gives the impression), but it allows users to choose an action that they want to apply to the selected items.
default actions
Change the label.
Several solutions have been proposed:
| Task | Complete? |
|---|---|
| Finalize the label wording | |
| Update the patch |
The changed wording needs to be changed in the hook_help text of the Node module. If still open, that can be taken up as part of #2470994: Update hook_help text for Node module
I am recommending that we add Andrew Macpherson to the Maintainers.txt
I remember first talking to Andrew at DrupalCon London when he came to the Accessibility BoF then. It was hard to forget meeting him that first time because he was mostly blue, but also because he was clearly interested in this topic.
Andrew's been active in quite a few accessibility issues in Drupal 8 and is contributing some great work on this issue.
Accessibility is a big issue and we need more champions. We have a goal of meeting WCAG 2.0 AA for Core and we're good, but there is still a lot of work to do to get there.
Managing the issue queue is important, but so is educating the community. I do think that Andrew can and is willing to play a role in educating the Drupal developers about the importance of accessibility in Camps & Cons in Europe.
Especially with the new release cycle it will be important to see that new features are not introducing barriers to people with disabilities.
#608118: Where can we tie a generic Field UI? points out that field ui permissions are rather coarse, e.g.: someone with "administer users" can also manage fields for users. We need to figure out a sensible scheme and implement it.
This one is related to https://www.drupal.org/node/2705643
The problem is more common. I think that whenever the frontpage is set to a path that a specific user cannot access (e.g. to an unpublished node for e.g. guest users) this (misleading) exception is thrown.
InvalidArgumentException: Source path has to start with a slash. in Drupal\Core\Path\AliasManager->getAliasByPath() (Zeile 191 in .../core/lib/Drupal/Core/Path/AliasManager.php).
The Path Alias element is a static 30 weight. This means that if you putz with the form display of a node content type with the path module enabled, the field will sometimes "unexpectedly" show up in the middle of everything. We either need a way to move the path alias field around on the form via the UI, or we need to pick one end or another so it doesn't get in the way.
I personally vote moving it always to the end like I did with taxonomy in #2655328: Relations Form Element static at weight 10.
You can see this in path_form_node_form_alter().
Imported po files are treated as regular files, and so appear at admin/content/files. When they listed there they have a link, even though they do not have a public URL -by design. Clicking their link gives:
LogicException: PO files URL should not be public. in Drupal\locale\StreamWrapper\TranslationsStream->getExternalUrl() (line 55 of core/modules/locale/src/StreamWrapper/TranslationsStream.php).
file_create_url('translations://en.po')
Drupal\file\Plugin\views\field\File->renderLink('en.po', Object)1. Filter them out in the view, or
2. Soften the error, maybe returning an empty string instead of an Exception.
I know this is a bit incomplete. I'm just recording the general issue as a start. See 2717673 for more information.
Prior to 2717673, the calculated dependencies of a comment type did not include the provider module of the target entity. It is likely that some sites have comment types where the provider module has been uninstalled leaving the comment type in an invalid state.
Following @catch's suggestion here we need to understand the implications of this and decide on a course of action.
Write a test which creates a comment type, uninstalls the provider module and then tests some actions which fail. One action that fails is editing the comment type. That would be a good test to start with.
Create patch.
I don't think we can really "fix" the problem once it has occurred but we should be able to at least avoid fatal errors on the site.
Maintenance mode page's checkbox description shows a Permission name as "Access site in maintenance mode" which doesn't exist.
Change the permission name to the actual name as "Use the site in maintenance mode"
Follow-up to #2683085: Improve the message details in Broken Class in Block Module
I feel like we need a better solution than just wording updates. Is there any way to force the creation of a stub block if the related UUID block_content doesn't exist? If we did that creation, that would make the problem solved by pane go away.
The above problem, combined with things like a read only filesystem for your live site makes the Site Building Experience (SBX) very bad of managing configuration surrounding blocks. Considering the bad SBX, marking as major.
Steps to reproduce:
Something, anything.
TBD
Updated: Comment #179
drupal_get_path() infiltrates almost every module and isn't very intuitive for new developers.
Stream wrappers make much more sense and simplify the API for developers trying to refer to image, JS, CSS and other assets files in code.
Stream wrappers will make it easier to reference JS and CSS files from yml files in modules, e.g. *.libraries.yml and will support the API to be introduced by #1762204: Introduce Assetic compatibility layer for core's internal handling of assetsAssigned to: sdboyer
Consensus is to go with the module:// theme:// and profile:// streamwrappers. Replace drupal_get_path() with stream wrappers in strings that are evaluated for a module, theme or profile path. Documentation will specify that this is *not* to be used to include PHP files.
Before patch examples:
_drupal_add_css(drupal_get_path('module', 'theme_test') . '/css/base-override.css');
$render_array['#attached']['css'][] = drupal_get_path('module', 'theme_test') . '/css/base-override.css';After patch examples:
_drupal_add_css('module://theme_test/css/base-override.css');
$render_array['#attached']['css'][] = 'module://theme_test/css/base-override.css';There are 4 possible use cases:
In a \Drupal\foo_module\Form\FooEntityForm where assets are attached,$form['#attached']['css'][] = 'module://foo_module/js/foo_bar.js'; is a far better DX than$form['#attached']['css'][] = __DIR__ . '/../../js/foo_bar.js'; or even$form['#attached']['css'][] = drupal_get_path('module', 'foo_module') . '/js/foo_bar.js';
Mainly in contrib, these would utilize js, css and other files from modules in core.
hook_library_info_alter(), hook_library_alter(), hook_css_alter(), etc. existing examples in system.api.php
The real benefit of this issue is the DX win of using "module://foo_module/js/foo_bar.js" which makes it easier to understand the code.
Reviews.
Commit.
Replacement of most / all uses of drupal_get_path calls (separate issue). This can be scripted.
Simplifies getting paths to modules, themes and profiles by using a stream wrapper.
#2028109: Convert hook_stream_wrappers() to tagged services.
#1308054: Add an abstract DrupalReadOnlyStreamWrapper that other stream wrappers can extend
#1762204: Introduce Assetic compatibility layer for core's internal handling of assetsAssigned to: sdboyer
#1702958: Add libraries:// stream wrappers to access system files
I wrote http://drupal.org/project/system_stream_wrapper and now let's merge it into core! It's super helpful to be able to access files via module://modulename/path/to/file.txt which nicely resolves to the actual file location.
Drupal's vulnerability to clickjacking (embedding a site in an iframe to trick the user into taking an admin action by clicking a button in the frame) is regularly reported to the security team
https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet
Implement a basic and reasonably secure defense Drupal in core, such as setting this header by default
X-Frame-Options: SameOriginWrite a change record
none
none
| Issue category | Task because it is security hardening. |
|---|---|
| Issue priority | Major because defending against clickjacking is an important security practice. |
| Prioritized changes | The main goal of this issue are security improvements. |
| Disruption | Not disruptive for contributed modules. |
Since #2471154: Anonymous user label can't be viewed and auth user labels are only accessible with 'access user profiles' permission, we have a new entity access operation, 'view label', which is better suited for the entity reference label formatter than the generic 'view' one.
Use the new access operation.
Review.
Nope.
Nope.
Nope.
Comment types do not declare a dependency on the module that provides the target entity type. Thus, if that module is installed, the comment type will remain and using it will lead to fatal errors.
Declare the dependency on the provider of the target entity type. In particular implement calculateDependencies() in CommentType. EntityDisplayModeBase::calculateDependencies() can be used as inspiration.
| Task | Novice task? | Contributor instructions | Complete? |
|---|---|---|---|
| Create a patch | Instructions | ||
| Add automated tests | Instructions | ||
| Review patch to ensure that it fixes the issue, stays within scope, is properly documented, and follows coding standards | Instructions |
None.
None.
The fact that comment types now get appropriately deleted when a module is uninstalled is a change in behavior, but since the comment types that were previously left in the system were completely broken, I don't see how anyone can currently rely on that behavior. Thus, I do not see the need for a change record either.
Comment types have a new entry in their exported configuration dependencies.
- Create an AJAX enabled view with exposed filters (preferably a couple, at least one being text/string filter), enable the reset button
- Load the view page - no reset button
- click filter submit button
- Reset button appears
- Click Reset button
- View is refreshed but reset button never disappears and the views query is not the same as the initial load
- Do the same with no AJAX for the view and it works as expected
Overwrite the views exposed input during exposed form submission, otherwise exposed input is rebuilt from the current (AJAX POST) request data with contains the exposed values again.
Tests?
The description for the Inline Form Error moduled on the Extend page does not follow the Help text standard as described in https://www.drupal.org/node/632280
Edit the text into one concise sentence by removing the second sentence.
Since this module is listed in the section "Experimental", the second sentence can just be deleted.
This issue should be tagged with the module, but that's not yet in the list of components.
none
none
none
none
