Both node and media modules have a conditional access check where the revisions tab only shows if there is more than one revision (if revisions aren't created by default), as well as restricting access to the current revision if it's the only one.
The title of the menu item in the configuration page changes from
When the translation module is enabled, the title of the menu item on the configuration page (admin/config) and in the admin menu changes from:
(no Content Translation module) Content language
Configure language support for content
to:
(with Content Translation module) Content language and translation
Configure language and translation support for content
But the title of that page that it links to (/admin/config/regional/content-language) remains "Content language" in both situations (with or without the Content Translation.
It should be changed as well.
Proposed resolution
Change title of the page /admin/config/regional/content-language to "Content language and translation" when the Content Translation module is enabled.
¿Are there some additional usage for this extra field that I was not able to find out? If not, it could be removed since it has no real usage and it is present in form display options of translatable entity types.
Steps to reproduce
In an installation with the content_translation module enabled and some entity set as translatable, go to its form display options.
Proposed resolution
If confirmed, remove the translation extra form field.
I was working on #2937166: Improve count() for ContentEntity source plugin and just wanted to reduce the repetitive code.
This is just changing a test to make it easier to read and maintain by converting it to use a dataprovider.
Steps to reproduce
Proposed resolution
Use a dataprovider for the 4 tests of the constructor
The d7_taxonomy_term_translation migration plugin skips every row where i18n_mode is 1, 0, or is empty.
If the TermTranslation migrate source plugin excluded these rows, we would get back the appropriate source record number – and that would increase DX a lot imho.
Proposed resolution
Improve source query to only get that should be migrated, where i18n_mode is not 0 or 1.
Add source plugin test source/d7/TermTranslationTest.php
Change * For available configuration keys, refer to the parent classes: to * For available configuration keys, refer to the parent classes. and add a blank line.
Once the combined width of menu items exceed the available container width, they overflow outside their intended home. Image may be NSFW. Clik here to view.
When this happens, the page becomes horizontally scrollable, and attempts to horizontally scroll result in a redraw loop, which can be seen in this video: overflow-glitch.mov
Bartik addresses this by wrapping menu items to a new line if needed. It's quite possible there's a more elegant way to address this. If a more elegant solution exists I'm confident the folks working on Olivero will find it 🙂.
The entity_test test module contains lots of test entity types. Some of these use the same label. This means that if a developer enables the module to work on tests, they will see the same entity label twice in the UI (e.g. reference fields, views, etc).
The output of
$ ag -G '/Entity/' --nofilename 'label = @' | sed '/^$/d' | sort | uniq -d
shows:
* label = @Translation("Test entity - data table"),
* label = @Translation("Test entity - revisions and data table"),
Steps to reproduce
Proposed resolution
Change the name of the duplicates, based on the entity class name.
Currently, when a new user registers for a Drupal account the details are sent to the user's supplied email address. This provides a basic mechanism that confirms the user is at that email address. However, once registered, users are permitted to change their email address without further confirming that the user is in fact at that email address.
Possible implications
A user can change their email address to be that of an unsuspecting third party as no confirmation of change is required. Using a second Drupal account (with it's email address also faked using the same method) the first user is then able to send anonymous malicious messages to the unsuspecting third party
A slow method for sending spam but exploitable none the less
Proposed resolution
Add a mechanism (similar to reset password) that:
Sends an E-mail to the new address requiring the verification of the new address (similar to register confirmation).
Sends a notification E-mail to the old address.
Allow the site builder to customise both messages at admin/config/people/accounts
Provides an update path to set the default behaviour and messages content.
Write tests.
This new mechanism is bypassed if the e-mail address is changed by an administrator.
Remaining tasks
#279.2: Seems to be fixed as well as possible right now given limitations of other issues. Raise a follow-on issue to tidy up once other issues have been fixed.
#279.6: Add a test - see further explanation in #284
Release note snippet for IS.
Security review.
Follow-up questions from usability review in #270 and #272.
User interface changes
New UI additions to admin/config/people/accounts:
Image may be NSFW. Clik here to view.
New confirmation message (warning) when user changes e-mail address:
Image may be NSFW. Clik here to view.
Default text of the generated e-mail (some elements will vary):
alice,
A request to change your email address has been made at Drupal Usability. You
need to verify the change by clicking on the link below or copying and
pasting it in your browser:
New controller used for mail changing: \Drupal\user\Controller\MailChangeController
Data model changes
New schema for configs user.settings and user.mail.
Release notes snippet
When users wishes to change their email, they must now verify the email belongs to them using a link sent to that address. This behavior is enabled by default on new installations but disabled by default on existing installations. Review the change record for more information.
1. Create a Basic Page with the title "Home" and path /home
2. Set the default front page to /home
3. Visit node/add/article
Proposed resolution
Current proposal
Add a breadcrumb builder that applies to node/add and node/add/{content_type} that outputs the respective breadcrumbs:
For node/add: Home - Administration - Content
For node/add/{content type}: Home - Administration - Content - Add content
The breadcrumb builder will be marked as deprecated for removal in 10.x, with a follow-up issue being filed against 10.x to move relevant node/add paths to sit under admin/content.
Original proposal
Add a default title to the view, suggestion 'Promoted content' as in essence that's what it is
Add a test for this displaying in breadcrumbs per the steps to reproduce A UX team review decided that this is an unacceptable workaround, as it has unintended consequences.
Workarounds
If this is impacting your site, there are at least two ways a site administrator can work around the problem:
Getting the below HTTP 500 fatal error on trying to add a translation of an 'draft' English node, Which was earlier 'published' with language 'not defined'. InvalidArgumentException: Invalid translation language (und) specified. in Drupal\Core\Entity\ContentEntityBase->addTranslation() (line 955 of /core/lib/Drupal/Core/Entity/ContentEntityBase.php).
Steps to reproduce
Install Vanilla Drupal's Standard Installation Profile with English as site language.(Note: I faced this error on 8.x and 9.x. So Install any version you want.)
Log in as an admin and enable the following modules
Configuration Translation
Content Translation
Interface Translation
Language
Content Moderation
Workflows
Go to the path /admin/config/regional/language/add& add the French language to your site.
Configure URL language detection method by visiting the path /admin/config/regional/language/detection/url such that it has below values:
Part of the URL that determines language: Path Prefix should be selected
Path Prefix Configuration: en in English textfield, And fr in French textfield.
Create content type, Allow content of this content type to be translatable. And show the 'Language' dropdown on this content's add/edit page.
Make this content type follow the default editorial workflow by visiting the path /admin/config/workflow/workflows/manage/editorial
Create a node of this content type, Such that it's published with language as Not Specified.
Now, Edit the newly created node, Change its language to English and save it as a draft.
On the node view page, You will see the Translate tab. Click on it.
Try adding the french translation of this node. And you will see the fatal error shown in attached screenshot.
Note: When the content type does not follow the 'editorial' workflow, Then you won't see the fatal error
Proposed resolution
Ideally, We should not allow language switching of an existing node.
But in the real world content editors tend to do language switching. Hence If we are allowing language switching, Then we should not get an fatal error for adding translations.
Steps:
1. Install Drupal 9 with olivero theme.
2. Create any content type.
3. Visit the node and check it at a resolution @1920.
Issue:
On higher resolutions, the page container is left aligned. There is no spacing to the left of the container. As per my understanding, there should be equal padding from the left and right of the container.
Drupal 8.5.0 with the media_module in core is bundled with four media types: audio, file, image and video.
Let's create a content type with two fields:
the field_local_video_file field which is using the media video type
the field_local_image_file field which is using the media image type
The node rendering an HTML5 video is handled by the file-video.html.twig file (which is a file_module core file located at core/modules/file/templates/file-video.html.twig):
{#
/**
* @file
* Default theme implementation to display the file entity as a video tag.
*
* Available variables:
* - attributes: An array of HTML attributes, intended to be added to the
* video tag.
* - files: And array of files to be added as sources for the video tag. Each
* element is an array with the following elements:
* - file: The full file object.
* - source_attributes: An array of HTML attributes for to be added to the
* source tag.
*
* @ingroup themeable
*/
#}
<video {{ attributes }}>
{% for file in files %}
<source {{ file.source_attributes }} />
{% endfor %}
</video>
Now, the idea is to offer the possibility to display a poster image using content from the field_local_image_file for the HTML5 video.
It would be nice if this feature could be managed by {{ attributes }} but I cannot figure how to implement this.
Maintainership of the package: created and maintained by Andres Morey
Security policies of the package: none I could find
Expected release and support cycles: I don't see any roadmap, last release was 3 years ago. package is feature complete so i wouldn't expect new releases.
Other dependencies: no runtime dependencies, dev dependencies are gulp and jshint
The code is pretty straightforward, we could probably roll our own if necessary, the heavy lifting can be done with something like this. Better to use something battle-tested though, especially when it's small like this.
Drupal 7 sites with File Entity installed may have invalid values at file_managed.filename since File Entity uses the filename property as the entity's title:
Image may be NSFW. Clik here to view.
The above gets saved like this in the database:
Image may be NSFW. Clik here to view.
Once migrated to Drupal 8, the following validation error is thrown when the image is about to be updated:
Image may be NSFW. Clik here to view.
Steps to reproduce
Proposed resolution
Change the file migrations to get the filename from the uri
filename:
plugin: callback
callable: basename
source: uri
Expected output: <a href="/" data-drupal-selector="edit-link" data-drupal-states="{"visible":{":input[data-drupal-selector=edit-checkbox]":{"checked":true}}}" id="edit-link">Link to front page</a>
Actual output: <a href="/" data-drupal-selector="edit-link" id="edit-link">Link to front page</a>
This appears to be because \Drupal\Core\Render\Element\Link::preRenderLink moves the attributes into #options['attributes'], which would be fine... if drupal_process_states() (which adds the states to the element's #attributes) was invoked before pre_render callbacks were invoked in \Drupal\Core\Render\Renderer::doRender.
Proposed resolution
Move the invocation of drupal_process_states() before pre_render callbacks.
BigPipe::performPreSendTasks() re-starts the session, with the following justification:
/**
* Performs tasks before sending content (and rendering placeholders).
*/
protected function performPreSendTasks() {
// The content in the placeholders may depend on the session, and by the
// time the response is sent (see index.php), the session is already
// closed. Reopen it for the duration that we are rendering placeholders.
$this->session->start();
}
In debugging my HTTP traffic on a site using BigPipe, I have noticed that all BigPipe'd pages contain a Set-Cookie header, re-setting the already existing cookie for the active session. I have narrowed this down to the above call (this behavior is not noticed when disabling the call to start() but for the life of me I can't figure out why this code path makes PHP send the set-cookie header, while the exact same code path during Drupal's main request handling does not.
