🇮🇪Ireland @markconroy

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.

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

markconroy → created an issue.

markconroy → created an issue.

markconroy → created an issue.

I attended.

finn lewis → credited markconroy → .

I think this is a good example of when we would use !important.

In this instance, it's !important that when the class .js-hide is present that the item concerned is hidden.

Perhaps we can use !important just for the hiding part and not for the showing part. For .js-show we may not want display: block all the time (sometimes we might want flex/grid/inline-block/etc) so !important should not be used for that.

After that I think @godotislate "double class" idea is probably best. .js-hide.js-hide. If we use .js-hide[class] it might affect other classes if they are present.

@smustgrave I think this can be closed as "works as designed".

So what I finally did was to also install the contributes stable theme.
Probably that was the intended way to go in the first place.

Fixed via ca7c187f0b787fe3a24c1915b56f86e46407604f

markconroy → created an issue. See original summary → .

Fixed via ca7c187f0b787fe3a24c1915b56f86e46407604f

markconroy → created an issue. See original summary → .

Thanks @kevinfunk for this MR.

@opdavies I think it would be great to have a test to catch this. Thanks.

I was there!

I'm not totally against this idea, but I'm also not totally for it either. As @nicxvan said, I created the issue to track @catch's discussion and so that it wouldn't get lost in the Slack history.

markconroy → created an issue.

I think that's everyone.

When creating custom themes, I quite like the process of just creating the bare minimum

• theme.info.yml
• theme.libraries.yml
• CSS + JS + templates as needed
• everything else inheriting from Stable9 or some other base theme

This means the custom theme directory is as small as possible and very easy to find your way around. Removing Stable9 would mean a change to this process. I'm not against that, but I would guess there are others that have the same process and maybe do not want a copy of every template, for example, in their custom themes.

markconroy → created an issue.

I attended.

Adding credit.

markconroy → created an issue.

markconroy → created an issue.

Adding in credit for company and client.

@liampower is it okay if I tag The Confident as my company for the credit?

liampower → credited markconroy → .

markconroy → created an issue.

markconroy → created an issue.

Adding credits.

markconroy → created an issue.

Adding credits.

markconroy → created an issue.

finn lewis → credited markconroy → .

Thanks @bbrala, MR open now.

Hi @smustgrave

Yes I've read that document and am aware of the duties of a core maintainer.

I'm also core maintainer of the Umami profile.

Mark.