#Needs issue summary update

We discussed this issue at 📌 Drupal Usability Meeting 2024-05-17 Needs work . That issue will have a link to a recording of the meeting.

For the record, the attendees at the usability meeting were @AaronMchale, @benjifisher, @rkoller, @shaal, @skaught, and @simhohell.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

While exploring the new responsive image form display widget we ran into one problem. On a standard 11.x-dev install with the responsive image module installed, and MR4628 applied, we had the following three options available for Preview responsive image styles:

2. Narrow
3. Wide

Our assumption was that based on micro copy you would either get the preview image added in the dimensions of the chosen responsive image style or you have no preview depending on your choice. But problem was no matter what setting we set the resulting preview looked like this:

Our expectation, based on the micro copy, would have been that this would only be the result in case option 1, no preview, was chosen. So we were not sure if this is a bug, and in general we've asked us how this feature is intended to work? We would need some clarification in that regard before we are able to make any recommendations.

We will also continue our initial discussion we've started in regards of the micro copy. There was already a clear consensus to change the label Preview responsive image style to Responsive image style for preview. "Technically" a user isn't "previewing a responsive image style", instead a preview image based on that responsive image style is being generated. About the corresponding description, there was the consensus to clarify where the image is shown (aka that it is shown on the edit form), and that "preview responsive image" is too verbose as well as misleading (There is only a single image being used, based on the responsive image style - but again we need to know how the feature is supposed to work).
One radio button option is called Bar with progress meter while within the description it is referred to as a progress bar. Aside this inconsistency in terminology it was also noted that the first sentence of the description is imprecise, the throbber actually is communicating the status of the upload, it is telling the user if the upload is still underway or was already finished. But the microcopy about the progress indicator would apply to regular image widgets as well. So making adjustments in that regard would be more suitable for a followup issue to keep things consistent between image and responsive image widgets.

But we will finish the discussions about the micro copy as well as the functionality in general as soon as the feedback is in. Thank you in advance!

Not sure what the best status would be in this case? I went with needs work but to postpone with maintainer needs more infos felt wrong since i am not the maintainer nor person working on this issue. I'll go with needs work, but please adjust accordingly if that is not the right choice and there is a more suitable one. Apologies in that case.

Resolved the Linting issue appearing on MR.

Mithun S → made their first commit to this issue’s fork.

Darren Oh → made their first commit to this issue’s fork.

Re-rolling #43/68 for 10.2.3

Re-rolling patch from #3 for 10.2.4 while work continues on this ticket.

Issue summary is still incomplete. Proposed solution is blank and should be filled in.

As a UI change there should be a before/after screenshot or gif in this case if possible.

Hi,

I tried to convert patch from comment 117 into a MR to more easily update it.

After trying to figure out in more details what it is was doing, I think I will open a separated issue for #3440128: version in info.yml for general project → .

In my case, I only want to try to extract versions from Composer if not present in .info.yml to provide site admin versions in admin pages.

Reopening this for consideration on the 3.x branch. I think it could be a useful addition. Will try to come back to it with updates if it's wanted.

My problem was:

I have n facets, for example:
Quality
- New (100)
- Medium (300)
- Poor (50)

Family
- Item family 1 (500)
- Item family 2 (30)
...

I want users to be able to filter on each of the facets with as many facet items as they want, using an OR.

But between the different facets it has to be an AND.

That is, if someone selects Item family 2 and Quality new and Quality Poor it would really be:

(Item family 2) AND (Quality New OR Quality Poor)

This already works this way by default, but it is not reflected in the number of results, so the logic that can be applied to the facets according to the results does not work well. For example hide a facet item if the results are 0. Or hide a facet if it is empty, having all its facet items deactivated.

Without the patch this doesn't work like that, but applying patch #44 it seems to work perfectly. Thanks to everyone who made this possible!

I'm using:
"drupal/search_api":"^1.34",
"drupal/elasticsearch_connector": "7.x-dev@dev",
"drupal/facets": "^2.0",

Shefali Shetty → credited dweberso → .

Shefali Shetty → credited nitishchopra → .

Shefali Shetty → credited vinnycustodio → .

Hi
I've tested MR !8082 on Drupal 11
MR is applied successfully...

The View Page is loading smoothly, without shifting the layout

RTBC+1

Adding recording for reference

Keeping "needs review" for more reviews and code verification

Thanks @bnjmnm for the suggestions. I have added the the no-script css and attached screen capture for reference

Thanks for that. That information will be most useful if it is in the issue summary rather than in a comment. This template → is normally used in that way.

OK "Steps to Reproduce" step by step (just did this with a fresh install of Drupal 10.2.6, PHP 8.1.16, Apache 2.4.38 Debian)

Step 1:
Go to /admin/config/people/accounts/fields
- Now add at least one field (I added 2 Number (integer) fields to be specific) with the "+ Create a new field" button.
For each field I set configuration as follows:
- Field Storage: Allowed number of values (Limited : 1)
- Set the Minimum value that should be allowed to: -1 (negative 1)
- Check on "Set default value"
- Set the default value to: 0
- Save

Step 2:
Go to /admin/structure/views
- Now add a view with the " + Add view" button.
Create the view with this configuration.
- Leave "View settings" default (Show: Content of type: All)
- Under Block settings, Check "Create a Block"
- Set the "Block display settings" to (Display format: Unformatted list of: fields)
- Set the "Items per block" to 1
- Click on Save and edit button

Step 2B:
Configure the view block and add the user account fields we previously created:
- Under the "Advanced" section (right hand view column) expand it open if it is not.
- Across from Relationships click on the "Add" button to add a relationship to the view.
- In the Add relationship dialog find under Title "User" where Category is "Content" and the Description reads "The username of the content author"
- Next click on "Add and configure relationships" button at the bottom of the dialog
- In the Configure Relationship: User dialog, Don't make any changes and just click the "Apply" button at the bottom of the dialog.
- Next also under Advanced across from "Contextual filters" click add
- In the Add contextual filters dialog find under Title "User ID" where Category is "User" and the description reads "The user ID"
- Next click on "Add and configure contextual filters" button at the bottom of the dialog.
- In the Configure contextual filter: User: User ID dialog Where it says "When the filter value is NOT available" check the "Provide default value"
- In the "Type" dropdown that appears select: "User ID from route context"
- Leave everything else as is and click the "Apply" button at the bottom of the dialog.

Step 2C:
- Now on the left column of the view display across from "Fields" click on the Add button.
- In the "Add fields" dialog find the field or fields you created in step 1.
- The "Category" should be "User" with a description that reads "Appears in: user." when you have it/them selected click on "Add and configure fields" button at the bottom of the dialog.
- In the "Configure field: User: Name of the Field" you can just hit the "Apply" button at the bottom of the dialog.
- When all field configuration is done and the dialog is closed click on the "Title" field listed under the Fields section above the field or fields you just added, when the dialog opens click the "Remove" button at the bottom of the dialog.
- Below fields (also in the views first column) where it says "Filter criteria" click on "Content: Published (= Yes) and when the dialog opens click on the "Remove" button at the bottom of the dialog to remove it.
- Next below that where it says "Sort criteria" click on "Content: Authored on (desc)" and when that dialog opens do the same as you did for the filter and click on the "Remove" button at the bottom of the dialog.
- Next under the views configuration and above the views preview area hit the "Save" button to save the view.

Step 3:
Create a new user as an authenticated user, no admin privileges and give value to the new account fields:
Go to: /admin/people
- Click the "+ Add user" bottom near the top of the page.
- Provide the "Username" and add a "Password"
- Under Roles "Authenticated user" should be checked by default and grayed out.
- Scroll to the bottom of the add user form and locate your added field or fields and give them values. (I set the first field of my two to "2" and the second number field to "4")
- Then at the bottom of the form hit the "Save" button.

Step 4
Place the view block on user account pages:
Go to: /admin/structure/block
- Scroll down to either a "Content" region or a "Sidebar" region (I used the right sidebar)
- When your at the region you want to use click on the "Place block" button to the right of the region name you are using.
- In the "Place block" dialog find the view block you created by name (using the search field and typing in part of its name should bring it right to you, its category will read "Lists (Views)" and under "Operations" click on the "Place block" button that is displayed to the right of the view block name.
- In the Configure block dialog under "Visibility" click on the "Pages" tab.
- In the Pages input field put /user/* and make sure "Show for the listed pages" is checked
- Depending on what you named the view and if you added a block name the "Machine-readable name" may be to long and you will have to shorten it to save the block.
- Finally click on the "Save block" button at the bottom of the dialog.

Step 5:
Now visit the users page:
Go to: /admin/people
- In the user list under "Username" find the user you just created and click on the name to go to their user account page (as admin doesn't matter if users can see each others account pages)
- You should be at: /user/2 (if there is only you the admin and 1 user account the path would be /user/2 otherwise it will be /user/[user-id].

What you will see is unexpected:
- Under the user account details you will see the two fields with the values you set
- However...The view block will only have the title of the view block and there will NOT be any field data and if you inspect the html the view content is empty. I would expect to see the same information displayed by the fields and clearly is not.

I'll include a screen cap of the new user account page at this point (fresh-install-same-issue.jpg).

Now if you want to give your new test user the ability to add an article or basic page you will also need to grant the "Authenticated User" role to allow it - if you do and you login as the new test user and create an article or basic page and then view their user account page admin or the user you will see the block then has the field information.
-> If you need instructions on how to do that let me know!

Couple of things to note (I did straight basic setup for the steps to reproduce) but there are reasons why I did a few things that you wouldn't get from this setup and may explain why I chose the view type I did for our use case.
1. I used a view to display content not user because for my use case I need content worked into this display seamlessly using attachments that also relate to the user and there content (which they may not have any especially when they are a new account)
2. The actual fields created on user accounts can only be set or updated by an admin or the corresponding module being developed to work with those fields on behalf of the user. The user has permission to view their field info (thus why it would be able to display in a view block), but they cannot change it. Furthermore the default fields are even hidden for our use case. As we just need it displayed in a block that does a lot more than just display the field info/data.

Any questions or problems let me know.

Some cases, we need to call importContent method without config directory. This patch file make more parameters for custom path

For anyone using a custom theme who is stuck with this, I was able to fix this using the below CSS:

article {
  width: fit-content;
}

I went through a lot of steps finding the issue. It turned out that the media was being added correctly, and while the image element itself was missing align: centre, but a few levels up the parent elements did get this attribute. I played in the browser a bit and found that by setting article to fit-content, it suddenly worked.

Updated the last patch to support the new filter "Only blocked"
I did this the same way it is done in "dev" if I'm right.
(This means it's display filter only, not a request filter)

The best way forward is to add validated steps to reproduce starting with a clean Drupal install.

All this conversation really feels like there is a need for a new module, maybe called "jsdoc" or something like that. Even if it might do the same as the "API" module for PHP modules, it definitely would do it with a whole different set of libraries, tools, etc, which no overlap with the "API" module in my opinion.

If we were to have this module, then it could be integrated in "api.drupal.org" as another module:
- "API" module for PHP files. All paths here start with "api/...".
- "jsdoc" for JS files. All paths here could start with "js/..." or "jsdoc/..." or whatever is best.

Then, via Drupal, we could easily add blocks to "connect" the two parts.
But all of this, without having a full-on Drupal module for JS parsing, feels like it's totally out of scope as it's not a quick task. We'd need to see how the new module would behave with several Drupal versions, what's the performance of it, etc.

Given that there was not much activity in a few years, I'm going to mark this as outdated. Creating a "jsdoc" module would be amazing and then we could look into integrating it, but not before that in my opinion.

Probably it’ll be 11 before this happens, but at least bumping to 10 for now

Comments were closed a few months ago, so the comments form went away.

This issue is in "needs review" 🐛 Restore link for filing a documentation issue Needs review and is for the new version of the site if somebody wants to review the wording.

For the short term, simply adding an ID to the checkbox label does the job; the use case is Simplenews subscriptions on user register page.

/**
 * Implements template_preprocess_form_element_label().
 */
function my_custom_theme_preprocess_form_element_label(&$variables) {
  $id = $variables['element']['#id'] ?? '';
  if ($id && str_contains($id, 'edit-subscriptions-')) {
    $variables['attributes']['id'] = 'edit-subscriptions--description';
  }
}

@fgm see this for the template adjustments: #3444792: Prepare for PHPUnit 10 → .

Seems like this just broke the current D11 (next major) Gitlab template. See e.g. https://git.drupalcode.org/issue/htmx-3447092/-/jobs/1591833

The problem is the use of the --no-interaction CLI flag, which no longer exists in 10.5.20

What @smustgrave spotted in #8 should probably be addressed - there is a momentary flash of the no-javascript buttons before they are processed into the familiar Views UI. These should probably just be hidden and exposed with a no-js stylesheet. Claro is already adding one here so you can build from that.

The gif in the original issue summary looks like there are additional JavaScript errors as that gif shows clicking the "Add" button reloads the page. If JS is executing properly, that should not happen as the click event is prevented. If there is a JS error, however, the event handler that does this might not be getting added

Believe I can see the issue when the page refreshes. On the "Page" tab. Some weird janky shift.

For good practice lets complete the issue summary.

Got it started.

There was a small typo in #14. Here is fixed patch without tests.

And this should include the file. :)

And this should apply with composer patches. :)

@alok_singh

checked the Site menu Broken by installing Drupal 8.9.20 with "drupal/yg_medical": "1.0.0-alpha1"

Before :

After fixing :

By providing the solution in file web\themes\contrib\yg_medical\css\style.css

#main-menu .dropdown ul {
display: none;
position: absolute;
background-color: #f9f9f9;
min-width: 160px;
box-shadow: 0 8px 16px 0 rgba(0,0,0,0.2);
z-index: 1;
}

/* Style the links inside the dropdown menu */
#main-menu .dropdown ul li a {
color: #333;
padding: 12px 16px;
text-decoration: none;
display: block;
}

/* Change color of dropdown links on hover */
#main-menu .dropdown ul li a:hover {
background-color: #ddd;
}

/* Show the dropdown menu on hover */
#main-menu .dropdown:hover ul {
display: block;
padding: 0;
}
#main-menu .dropdown:hover ul li{
list-style: none;
}

I tested the MR today and it works fine when I use the Images button (except the things discussed in the comments starting from #87).
I cannot get it working with the media library though. Is there anything that I need to keep in mind while testing it with the media library?

yoftahe.addweb → made their first commit to this issue’s fork.

Hi, #11 does not work for us. The preg_replace_callback regex only matches the first line.

Here is my attempt and I added some tests as well.

Not able to reproduce the issue. I have added screenshots for reference.
Can you please add more details

ahsannazir → made their first commit to this issue’s fork.

It is going on 10 years and there has been no further discussion here or an update to the issue summary. The function mentioned in the issue summary was removed in 2014, #2326891: Convert system_element_info() to Element classes → . And comment #2 was sure this was still relevant. Based on that I am closing this is outdated. I trust someone will correct that if it is wrong and there is work to do here.

Just running into this issue in a custom theme. Here is the code sample that generates the «Broken ARIA reference» error:

<!-- BEGIN OUTPUT from 'core/modules/system/templates/input.html.twig' -->
<input data-drupal-selector="edit-subscriptions-sip-n-savour" aria-describedby="edit-subscriptions--description" type="checkbox" id="edit-subscriptions-sip-n-savour" name="subscriptions[sip_n_savour]" value="sip_n_savour" class="form-checkbox">
<!-- END OUTPUT from 'core/modules/system/templates/input.html.twig' -->

<!-- BEGIN OUTPUT from 'core/modules/system/templates/form-element-label.html.twig' -->
<label for="edit-subscriptions-sip-n-savour" class="option">SIP n’ SAVOUR</label>

There's also this page https://www.drupal.org/docs/official_docs/local-development-guide → which which was originally written as part of an earlier initiative to be opinionated and brief. This page is currently linked in the top level "Resources" tab in the navigation. And I think provides a good foundation for the documentation that would get someone from zero to DDEV + Drupal running the fastest with the least amount of documentation duplicated from the official DDEV docs.

I think this page, or its content moved somewhere else, should be the page that we link to when we first tell someone to setup a local environment.

mmunjeti → changed the visibility of the branch 1797438-html5-validation-is to hidden.

mmunjeti → changed the visibility of the branch 1797438-html5-validation-is to active.

Commenting that I helped a mentored contribution table look into this issue. We were able to confirm the issue and we looked at the patches. Unfortunately this was happening later in the day and I think we all ran out of gas at the end. I'll review this in a few days if no one else from the group does and try to get it to RTBC so we might get some core credit for everyone's efforts.

@sakthi_dev I'll try to produce 11.x version in free minute... but can't promise when exactly.

Ups... I forgot about schema updates. So this is #49 + schema fixes.

Do folks think this could cause pages to show the same tabs to one node? This is happenning on mass.gov and on several other sites. See https://www.drupal.org/forum/support/module-development-and-code-questio... →

assert() is non-functional in Prod so I dont think that approach is as helpful.

Can the issue summary be updated to match the standard template?

See there is a test failure so maybe updating that will be enough coverage for the change being made.

Hello everyone,

I have been struggling with the same problem that was mentioned by stamina in https://www.drupal.org/project/default_content/issues/2698425#mr14-note2... 🐛 Do not reimport existing entities Needs review .

The way to reproduce the problem is:

- Create a layout
- Place an inline block_content with an entity reference field to one or several media images
- Export the node where the layouts was created (including its dependencies)
- If you try to import the node in a different environment, the block_content loses its references to the media entities. Media entities are created correctly but the entity_reference field in the block_content entity is empty.

I have created a patch file based on the current status of the MR!14 adding the fix that he suggested.

@gugalamaciek, could you please share the diff. I have created an MR for 11.x 2ith #49.

UPDATE : in the end the number of errors that appear in the logs seems to clearly decrease, so this clearly seems to be due to Drupal 9 pages being kept open on an old tab that requests CSS and JS files the old way not compatible with D10. So not much to do here, the errors should fade away progressively...

#50 is #49 extended with End date optional #153 ( https://www.drupal.org/project/drupal/issues/2794481#comment-14839868 ✨ Allow end date to be optional Needs work )

+ support

Discussion for core: 🌱 Call PHP native functions fully qualified (like \array_key_exists()) Active

External discussion in derivative standard: https://github.com/previousnext/coding-standard/pull/69

Improved patch which covers:
- adds all_day column in DB for datetime range fields. Set it as disabled for all existing data with datetime type
- allow to enable all day dates for datetime type & set default value for it in field settings
- widget to set all day, making sure that date is stored in UTC when all day is selected (in general timezone is ignored when all day event is set)
- GraphQL - share allDay property for datetime range fields
- formatter - for now only supported inn default formatter. You can specify date format for all day and non all day dates
- js - when you'll select all day, time is set to 00:00:00 for start & end dates

updated issue summary

This was fixed in Drupal 8

A commit was made for this issue back in Drupal 8.0 something and was set to Fixed in 2010. It was reopened the same day for a wee change but that never happened and I think is now outdated. But the request for change the links a bit is still ongoing, although it stalled by August that year. I am moving that to a new issue, 📌 Improve links on /admin/people/roles Active

Therefor, restoring the fixed status of this.

Based on the lack of feedback since #16 and given this is not unique to this class I can't see how this should be classified as a bug.

Swapping to a task, IMO we could/close this if no one can answer #16 within a couple of months?

Can be related

@kim.pepper

Even if the extension is enabled the message `{"message":"Starting upload...","percentage":-1}` will still appear when no upload process is available.

I think it's feasible that anonymous users would be able to see file upload progress, so I don't think it's an access thing. But I do agree we should check if the extension is enabled.

Created a MR.

kim.pepper → made their first commit to this issue’s fork.

Restating the problem as aparently the comment was insufficient for a response in support of a solution. I have the same problem.

BOTH the logo and favicon add functions fail.

The instruction reads:

Path to custom logo
filename.png
Examples: filename.png (for a file in the public filesystem), public://filename.png, or sites/default/files/filename.png.

Uploading in the field provided does not result in successful loading of either a logo or favicon (same instruction for each).
Adding the string to identify the file location (.png or .ico as appropriate) results in the error message:
The custom favicon path is invalid.
The custom logo path is invalid.

This presents the user with a situation in which it is easier to find an alternative theme than to configure a theme that does not permit display of the users logo or favicon.

PLEASE help.