🇮🇪Ireland @markconroy

Working within the local government sector _a lot_ of councils (at least in UK and Ireland) request a "Glossary of Services", so I think the glossary is quite often used.

Here's some samples (not necessarily Drupal sites):

• https://www.colchester.gov.uk/council-services/
• https://www.nhs.uk/service-search/other-health-services/
• https://libraries.essex.gov.uk/digital-content/az-of-library-services
• https://www.royalgreenwich.gov.uk/homepage/186/services
• https://education.southwark.gov.uk/send/send-service-a-to-z

I'd like to opt in

1. https://www.drupal.org/project/content_access_by_path →
2. https://www.drupal.org/project/sa11y →
3. https://www.drupal.org/project/mgv →

@finn lewis I have an MR ready now to add div.dialog-off-canvas-main-canvas as the default region, same as sa11y.

However, I note that Editoria11y is for "editorial" work, so it doesn't seem to scan for issues like colour contrast that sa11y does. Maybe it's work using having both of these available, for different user roles/audiences.

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

@millnut Maybe it would be best to declare that dependency, since in the .module file we are adding permissions to a role that might not exist without a dependency on localgov_core:localgov_roles

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

+1

I think this would definitely qualify as a "Needs framework manager signoff" issue.

+1

+1

Fixed. Tagging new release.

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

typo

+1

I'm going to close this issue for two reasons:

In the linked issue ✨ Add "view unpublished $bundle media" permissions for each media bundle Postponed , the comments are quite explicit that we do not want generic permissions like "view any unpublished media".

If that's the case, the alternative is "View unpublished $bundle", in which case this is a duplicate of the linked issue. ✨ Add "view unpublished $bundle media" permissions for each media bundle Postponed .

If I've made a mistake, please add more details and reopen the issue.

Great work, thanks @vasantha deepika.

Marking RTBC

markconroy → created an issue.

I think it would be better to get a new release of this module, rather than pinning our composer.json files to a specific git commit hash.

Let's see if we can get the ball moving on this.

markconroy → created an issue.

Hi @smulvih2

Do you have any update on this? Are you using this project/patch on a Drupal 10/11 website?

I think I might need a redaction feature soon and it would be great to be able to use this module rather than writing a new one.

+1

+1

This looks fine to me. RTBC.

Marking this as postponed until we either

1. Have more info, or
2. 🌱 Should we deprecate Stable9? Active

Thinking about this further, if the future way to create themes is the starterkit method, then my "create the bare minimum and just overrides the templates that you want" is a moot point.

So I guess this proposal to deprecate Stable9 and move it to contrib has my approval (as subsystem maintainer).

Removing "Needs subsystem maintainer review" tag.

+1

markconroy → created an issue.

Fixed by: https://git.drupalcode.org/project/localgov_editoria11y/-/merge_requests/1

Thanks @finn lewis

Change target version.

1. I think this has been fixed. You can use the manage display page settings now for all the view modes. This was a requirement as far as I remember for the profile being unhidden.
2. I'm not sure how we get around this when developing something as specific as a recipe magazine.
3. I don't think this is an issue. Looking in the images folder, all we have is icons from the old classy theme, and some SVGs (like the chef's hat for our recipes page).

Some of my thoughts on the 3 items in the IS ^

+1

markconroy → created an issue.

@chakkche it looks like there are still a number of failing tests, such as:

testUninstallingThemes()
InvalidArgumentException: Input "admin_theme" cannot take "stark" as a value (possible values: "", "claro", "olivero").

AddedStylesheets
The link Set Stark as default theme was not found on the page.

StandardPerformanceTest
Failed asserting that two arrays are identical.

Drupal\Tests\navigation\FunctionalJavascript\Performance
Failed asserting that two arrays are identical.

I wonder should we leave Stark as an available theme on the Appearance page, or should we update these tests? Given the point of Stark, it looks like the tests should remain as is and use it, but I'm not sure how to get around that being the case _and also_ hiding it from the Appearance page.

markconroy → created an issue.

+1

I'm also starting to think if we want this, it should be a standalone module rather than part of the Modules List module. I'm not sure this json feed has much to do with "Modules List".

markconroy → created an issue.

markconroy → created an issue. See original summary → .

This was originally requested as part of a Tech Drop-in chat for LocalGov Drupal.

Let's hope people are careful about what users can view this data - we don't necessarily want _everyone_ knowing what out-of-date version a a database you are using for example.

markconroy → created an issue.

Judging by the stack trace, the error send to be with the Tac Lite module.

line 77 of modules/contrib/tac_lite/tac_lite_create/tac_lite_create.module)

Can you confirm if the error is in that module or this module?

aaron.hirtenstein → credited markconroy → .

+1

@chakkche Let's keep Stark as the theme we want to use for the tests. But update the tests.

Also, let's have a read of the linked issue that this issue was spun off from to see some of the approaches that have been made towards this already. 📌 Discourage use of Stark as a base theme (and possibly mark it internal or hidden) Needs work

Follow up issue created to remove Stark from the Appearance page UI: 📌 Hide Stark from the Appearance page UI Active

markconroy → created an issue.

Hi @guaneagler,

You can try something like this in your token to see if you get the URL of the original image.
[node.field_main_image.entity.field_media_image.entity.uri.value]

markconroy → created an issue.

Done.

markconroy → created an issue.

markconroy → created an issue.

Fixed via: https://git.drupalcode.org/project/netcall_converse_queue_data/-/commit/...

markconroy → created an issue.

Fixed via: https://git.drupalcode.org/project/netcall_converse_queue_data/-/commit/...

markconroy → created an issue. See original summary → .

Thanks for all the help with Umami over the years Gareth. Much appreciated.

Thanks for all the help with Umami over the years, Ofer. Much appreciated.

Updating issue summary.

+1

+ 1

We don't seem to have reached consensus on this, and we haven't had a reply to it in over 8 years.

My take is that 'sidebar' - for better or worse - is the generally accepted name for these "things" in web nomenclature and we might as well go with what is being used. There are lot of things with names that could be better - radio buttons for example, when no one has radios like that any more; headless - really?

Sidebar seems like a good name to me. It implies it's a sliver of "stuff" beside other content. Which it is on large screens at least.

After all this time we are still using "sidebar" in our core themes, so that seems to at least be some sort of consensus that we will keep doing so.

I'm going to mark this as "Won't fix", re-open if you think we should still work on it.

Can we get the MR for this updated. The current one says it has over 1,500 commits to it. I doubt we did that much work to this issue :)

Looking at the specific example from the account settings form, the <em> is only around the email address and not the text.

'#description' => $this->t("The email address to be used as the 'from' address for all account notifications listed below. If <em>'Visitors, but administrator approval is required'</em> is selected above, a notification email will also be sent to this address for any new registrations. Leave empty to use the default system email address <em>(%site-email).</em>", ['%site-email' => $site_config->get('mail')]),

If this is still an issue, let's get a list of where we need to change it so we can work on it.

Can someone confirm if this is still an issue?

If so what operating system are you using?

I'm testing on Mac Sequoia and Firefox 140 and seems to be working fine.

For LocalGov Drupal's base theme we created some theme settings for "Add pink background to unpublished items" and "Add "Draft:" to the title of unpublished nodes.

I'm not suggesting we create theme settings here, but the approach of prepending "Draft" to titles has worked very well for councils, and does not affect the length of the title very much. So instead of a node title like "Council Tax" you get "Draft: Council Tax", with the option to also add the pink background (which is a CSS variable so you can put whatever colour you want in via CSS).

Removing 'Vienna2017' tag.

It looks like we haven't made very much progress on this issue in a number of years. We also do not have a consensus on whether to show or hide Start on the Appearance page.

With that being the case, I'm attaching an MR that at least updates the description of the Stark theme to discourage it's use (taken from the last patch in the comments) and updated the link to the theming guide from the Drupal 8 guide to the current guide - https://www.drupal.org/docs/develop/theming-drupal →

I think this at least encourages people to not use Stark as a base theme, and we can continue to figure out whether we want to hide it or show it (my preference would be to hide it).

If this is going anywhere, I don't think it should be going to media.

The _actual_ request seems to be "As a site builder, if I add a link field to an entity, I want the option to have that link open in a new tab". Is that accurate?

If so, I think this should be tagged with 'link.module' instead of 'media system'.

2 things from me on this issue:

1. I think it should be closed as "Works as designed"
2. If keeping it open, both approaches in #3 are incorrect. At minimum, create a variable in hook_preprocess, and use that variable for the href on the wrapping a tag.

And one friendly tip: when pasting code, please put it inside "" tags.

Do we want to close this issue? README is available at https://git.drupalcode.org/project/username_enumeration_prevention/-/blo...

+1

I haven't tested this, but as an Umami maintainer I have no problem with us showing the warning messages on the navigation on all pages rather than just admin pages.

The reason it was on admin pages only was - iirc - so people wouldn't start site building on top of Umami.

So instead of adding to core would this make sense as a contrib module, maybe even in twig_tweak?

I came here to say the very same thing.

If spaceless is deprecated in Twig officially and we are not using it in core any more, and our fix is just to solve issues that _might_ arise in contrib, this seems perfect to become a contib module (or a Twig Tweak - as you suggested - feature).

markconroy → created an issue.

markconroy → created an issue.

markconroy → created an issue.

For Umami we had a similar (kind of) problem with all the articles being created with the exact same datestamp. We solved it by adding a call in the install hook to set each article to have a day between them.

🐛 Umami content is all created in the same second Active

Hi @ded

Thanks for filing this issue, let's get it fixed.

I'm going to downgrade it from Critical to Normal and from Bug to Task.

Reading the code in netcall_ai_widget.module, there is indeed that typo but the place it's called (a few lines later) using the same spelling. It looks to me like this is just a general 'task' rather than 'bug'.

Hi @julio_retkwa

What further review is needed on this? Looks like the issue is already marked as RTBC.

If there is more review needed, can you mark the issue as "Needs review" or if there is more work needed mark it as "Needs work".

I've just now also merged the latest 11.x into this branch.