@jpoesen

borisson_ → credited jpoesen → .

Patch in #10 applies cleanly and works perfectly (D10.4.4, menu_export 1.4.0).

Thanks!

@volkswagenchick: Thanks for acknowledging this issue. I'm looking forward to hear the CWG's point of view and recommendation on this.

To recap:

- leaving X/Meta properties, but in a wider context and to avoid having this discussion when Bluesky inevitably goes the X/Twitter way: transparent ethical criteria / rubrics for evaluating community-oriented tools.

- ceasing activity (including message mirroring) on bad platforms but maintaining presence and signposting to new alternative hangouts.

As a nice to have it might also be nice to indicate which accounts are active vs unattended mirrors so people don't get frustrated by lack of response. One-way channels are fine if they're marked as such.

Thanks @darrren-oh. I contacted a few people when I created this issue, was told it had been mentioned informally, and would likely be discussed at the next CWG meeting. Unfortunately it seems two monthly meetings have come and gone since then.

I do agree that the account names should be retained to prevent cybersquatting and/or abuse. Having those accounts signpost to new accounts elsewhere makes a lot of sense.

There's some great feedback here (thanks everyone!), but it seems clear that the CWG is unable or unwilling to participate in this discussion, with the exception of @gdemet's comment on not linking to members-only social networks.

I wouldn't have thought it would be so hard just to have *a conversation* about whether sticking with X/Twitter is a thing the Drupal project should do. If this isn't the place for that discussion, we'll hold it elsewhere.

See also: ✨ Add support for custom dimensions Needs review

Patch in #14 (28 November 2024 ) (https://git.drupalcode.org/project/matomo/-/merge_requests/46.patch) applies cleanly to module version 8.x-1.19 on D8.8 (I know, still on D8 for reasons).

Form saves even if URL validation fails.
New toggle to skip URL validation works as expected as well.

Thanks!

To provide context to @neurer's comment:

When you encounter a Server 500 error, you are pointed to the @drupal_infra X/Twitter account to learn more about the status of drupal.org's infrastructure.

This indicates that @drupal_infra on X/Twitter is Drupal's official infrastructure-related communication channel.

However, since the link is to the X/Twitter account (and not to a specific status tweet), visitors are redirected to X/Twitter's login before they get to see the @drupal_infra feed.

No mention of the team's active @drupalinfra@mastodon.social account though.

--> this one seems to have an easy solution: update the error message and point to @drupalinfra@mastodon.social instead.

For what it's worth: patch #86 also applies cleanly to 10.4.2 and seems to work correctly.

jpoesen → created an issue.

@kreynen Thanks. It's even more than a geographic restriction: only official French government agencies are allowed to use the theme.

Edit: change title to be more solution-oriented.

Edit: added a link to a personal post on ethical vendor selection criteria as a starting point to constructively move forward.

Thanks @jr_kthor.

I understand decisions like these take time, and rightfully so.

On the other hand, this is not the time to spend weeks and weeks determining what action to take. The US is dragging the world into its crisis mode, and Musk and X are right at the center.

The community needs Drupal Leadership to have an open discussion and take a position.
This thing is only going to get worse. Watching from the side lines is not an option.

@jr_kthor, thank you for sharing the DA's point of view.
Is this the DA's full and official position?

It would make sense for the CWG / Community / ... to draw up a set of values / ethical requirements that social media platforms must adhere to, similar to and derived from the CoC and the Drupal project's values.

Having an such an "ethical checklist" could be a clear and objective instrument to drive the decision on which platforms to (remain) active, especially if platform policy changes automatically trigger a review on our side.

jpoesen → created an issue.

Thanks, @socialnicheguru. Closing this in favor of the D11 compatibility fixes.

avpaderno → credited jpoesen → .

Unless you're offering to step up as a co-maintainer, or have organized for someone to step up (free or sponsored), I don't see how this kind of tone and language is constructive.

Opensource software is made by those who show up and do the work. Maintainers owe the users of their software nothing.

I get that being stuck without the resources to get unstuck is frustrating, but your choices are clear: (learn to) fix it yourself, pay someone else to fix it, or stop using the software.

Either way, insulting the person who's been working on this for free is not what we do around here, and violates the code of conduct. Please be better.

This looks like a duplicate of https://www.drupal.org/project/adaptivetheme/issues/3372322 🐛 Deprecated function errors, possibly related to PHP 8.1 Needs review , which also provides a patch.

@tokesefi, could you try that patch and report back in that thread?

Updating the PHP Debug extension's marketplace URL to the official Xdebug extension (the old URL redirected to this new one).

Small clarification to avoid confusion.

Confirming #14 and #15: same scenario (ckeditor5 with layout paragraphs); patch in #9 works.

In my case: I subthemed Claro and added the z-index style rule.

This was pretty much the only example code I found, and it works great (other than adapting the code to use the right layout/region names for my purposes).

Thanks, @ben.hamelin!

Thanks @coderdan.

Using D9.5.11 with entity_reference_hierarchy 1.0 beta3:
at first glance this patch seems to work with no side effects.

Will report back if I find any issues.
J.

At present there doesn't seem to be a built-in way to track this.

I've solved this in my project by adding an entity reference field named "field_source_entity".
That field that stays empty on entities that get cloned, and automatically gets populated on cloned entities through a custom EventSubscriber that listens to the 'entity_clone.post_clone' event and sets $clone->field_source_entity to $original->id().

September 2023 - this issue has surfaced again for several of our team members at once, in separate physical locations.

MR 18 containing patch https://git.drupalcode.org/project/markdown/-/commit/02425a6ef054376c0d8... still applies for markdown 3.0.0 and still fixes / works around the issue.

Small sentence/grammar fixup.

Confirming that those config values (in #4) in combination with dummy values in /admin/config/stripe seem to work perfectly.

Thanks, @vonFrakas.

Confirmed: patch fixes the error on:

- D9.5.1
- gin_login 2.0.0

Thanks, @MukhtarM!