🇧🇪Belgium @swentel

Running that version of the patch now, no errors so far, so works for me!

Hmm, more or less related or not? We're getting "AVIF image support has been disabled" in our logs, which seems to be a warning from PHP. cf https://bugs.php.net/bug.php?id=81217

Status page at Drupal does say it's supported: Supported image file formats: GIF, JPEG, PNG, WEBP, AVIF

Kind of annoying the watchdog is now being filled with these logs. Not sure what approach is best here for better testing it will actually work :)

Bitten by this one too and running the same patch locally.

Apparently this happened from #3204862: Backport tabledrag.js for Drupal 8.8+ → . This is annoying. Not everyone uses Gin, or will use Gin in the future if it's in core (we often don't for instance).

Darn, this is annoying. It's likely safer to go forward with 🐛 Child fields moved from disabled groups retain parent relationship Active then yes. We really don't want to add a dependency on an admin theme for this.

• Re: dependency: tabledrag library is added by drupal_attach_tabledrag() which is a helper function in core.
• Re: region value which are nested: this is probably (but I'll try to confirm over the weekend), in combination with Display Suite. It's been too long since I created this issue.

Yeah, removing this isn't really an option tbh, I'll have a look at this over the weekend.

Rereading everything again, I'm still rather a fan of fixing this in tabledrag JS and see if we can get 🐛 TableDrag JS :first-of-type issues Needs work forward (if possible of course), where, afaics, the fundamental problem lies. Only fixing it in core for field ui, would still leave problems for other UI's (although I'm not sure how many other's have nesting and multiple regions, but oh well).

Also 🐛 Nested field groups improperly display as "Disable" in the admin UI Active is a duplicate - where someone also reports that 🐛 TableDrag JS :first-of-type issues Needs work might fix things.

Will debug some during the weekend to get a clearer view.

I'm not sure if it was really off track, as far as I can see. It's been a while since I've found the energy to dive into this one as it's tricky :) There are basically two problems (in core) with tabledrag:

- not changing the parent, tracked in 🐛 TableDrag JS :first-of-type issues Needs work . Some people report that it fixes the issue.
- (re)setting the region value, tracked in 🐛 Tabledrag is resetting the region value if items are nested Needs work - but it might be obsolete by the previous one.

Again, it's been a while, so I feel like there's actually too many issues open now, which makes it even more off track :)
Ideally, we can fix this in core. But I would be ok if we are able to fix this in field group, without having to rely on a core patch.
(it would be even better if FG just goes into core of course haha)

Note: I'm less involved nowadays, but I know this issue is tracked in couple of other issue, so I'd rather leave this one open as the 'canonical', thoughts?

(There was also a conflict of DS which gets in the way in although that should have been fixed already by 🐛 DS resets all the rowHandlers to field Fixed though)

Related with #1810394: Site configuration with domain based language negotiation results in redirecting authenticated users to a different domain when accessing a content entity route for translation language different from the interface language → - when you go to admin/content, the edit links will also point the other domain instead of using the "Content language detection" query param. It's so frustrating to no be able to decently configure this for webmasters/admin users!

Hmm, this is still disabled at the moment. I implemented a form alter to remove the #disabled property. AFAICS, that doesn't really have any implications, or are there any?

Alright, merged and will push a new release in a couple of minutes.

Changed the PR a bit to make sure it also works for 10.4.x .. I think that looks fine.

Hmm, that won't work on 10.4.x I guess?
Also we can use an import instead of the full namespace no?

Seeing the same behavior from #38, checking if I can alter the behavior.

Actually, reading again, it's not the same, sorry!

Isn't this the same as 🐛 Display status message on configuration forms when there are overridden values Fixed ?

swentel → created an issue.

Also, I can confirm, CWSmith@hybridized-concepts.com can be found on mastodon.

Moving to webfinger module, it would be great indeed to have documentation what can or can not be in an Nginx configuration file!

The folder doesn't even have to exist, path is defined by the webfinger module, cf https://git.drupalcode.org/project/webfinger/-/blob/2.0.x/webfinger.rout...

It is served by Drupal.

.htaccess is only apache afaik, so yeah, that would be a bad pointer.

I see this in the nginx though, which, If I understand, will block calls to it and not redirect to drupal.

location ~ /.well-known/webfinger {
add_header 'Access-Control-Allow-Origin' '*';
if ($arg_resource = "") {
return 400;
}
try_files /profiles/$arg_resource.json =404;
}

Maybe the block with try_files line could be removed completely?

More info can be added in ActivityPubUtility::alterNodeInfo

Question is of course: how do we define MAU: unique users who have posted something? That could work for me.

While we're at it: maybe we should change the name of the software and the version too (but not the Drupal version, I don't want to expose any Drupal version which might be vulnerable).

This looks like a problem with the .well-known directory. Normally this should work:

https://hybridized-concepts.com/.well-known/webfinger?resource=cwsmith@h...

But it returns a 404. There is an issue at 📌 An existing .well-known directory (as for Let's Encrypt) can prevent ActivityPub module's webfinger from working Active where people change something to .htaccess which existed in their .well-known directory, so that's maybe a pointer? Or maybe an nginx configuration issue?

e.g, for my server (running apache), this call to the webfinger to find my resource works fine and returns a json response:

https://realize.be/.well-known/webfinger?resource=swentel@realize.be

I do have an existing webfinger directory, so it doesn't sit in the way if it exists.

Merged in, thanks!

Merged, thanks!

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

Hmm, tests are failing with 2.0.3 webfinger too, but maybe it's a bot thing?
Will run then locally to double check.

Can you tell me your handle? (user@domain) .. then I can have a look.

Wow, what a template! :)

Not a fan of the duplication of the microsub function, will look at that one of the following evenings to remove references of microsub at this place, since that's more of an indieweb thing.

right, makes sense. I guess we can use str_contains instead of the strpos call (and replace the rest as well)

Alright, new release out, triggered ci for the tests.

Interesting although I can't reproduce it at this point, but fair enough to fix it of course :)
I've changed it to use !empty() call instead of casting it to a string.

Thanks for the report!

Regarding different templates: maybe it's better to have one template with a lot of if statements which is able to render urls, content, video images etc and then add suggestions based on $activity->getType(). cf Reader::buildMicrosubItem for inspiration.

Do you think that will be useful, a way to render non comment inbox (like "Create") activities? Or in this use case a new plugin to process inbox activities to nodes will make more sense ?

I think it's very useful to have rendering of this out of the box!
Currently, I'm using the reader module to view all incoming activities, but this should be possible with this module too.

Not a fan to create nodes from these though. I think we can use a viewBuilder class and than use inspiration from Reader::buildMicrosubItem to render inbox activities, and maybe have different templates depending on some logic: e.g. Inbox -> like template, Inbox -> Create template, Inbox -> Announce template, Inbox -> Follow template and a 'default' one which does something clever with the payload although I have no idea what yet :)

The view builder class should split rendering between inbox and outbox, especially when 📌 Allow like/announce not having to map to entities Active is resolved. (I briefly had the idea to maybe use bundles for inbox and outbox, but view builder classes can't be split in core for now).

That looks very, very, very cool! I wonder whether we can create our own ckeditor plugin instead of having to rely on getting that merged into ckeditor itself. That's just a thought because I have not dived into Ckeditor plugins yet, a bit too scared :)

Maybe the escape isn't that necessary, but maybe wildcards are?

Merged ✨ Make endpoints unlocalized Active - would the tests pass (in case you use dev require of webfinger?)

Merged in thanks!

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

Hmm, I wonder if we also should escape the query as done in the 'search' part in baseQuery, or is it good enough for your use case?

I need this as part of 📌 Allow like/announce not having to map to entities Active - working on that one now, marking this duplicate.

Merged, thanks! Simplified the patch a little, no need for inline twig template.

These are not necessarily linked indeed to AP, and are not a problem in itself. Marking duplicate of #3174746: Add more responses for various crawlers → - which has a link to a Github issue where I was tracking all potential calls which start to come in once a site is connected with the fediverse.

Merged

Oh, nice catch! Merged, thanks!

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

Even better message indicating this needs to be configured in settings.php

I guess we can do this.

So third time it worked, so probably some issue on the mastodon side (username ending with underscore)

Ok using aliases makes this work as far as I can see, finally!

Not needed anymore at this point.

Marking duplicate of 🐛 indieweb_indieauth - not working with indielogin.com Active

swentel → created an issue.

Merged, thanks!

nvm, was able to create a merge request myself

Ha, funny! Could you create a merge request from that, the fix is working indeed!

swentel → created an issue.

Display Suite relies on the core plugin since a very long time now, and no issues are reported on that integration. I'm fairly sure the others are fine as well, so this can be closed imo.

Updated version fixing the explode

indielogin.com seems to work for me with patch 3

getting a notice though: Deprecated function: explode(): Passing null to parameter #2 ($string) of type string is deprecated in Drupal\indieweb_indieauth\Entity\IndieAuthAuthorizationCode->getScopes, so will fix that while we're at it

Hmm the invalid state is on indielogin.com? Haven't tested that patch yet, but I'll double check somewhere next week!

New patch, suble change where the 'me' optional, but, in case it's there muse validate. Fixes the tests as well.

Thanks for the detailed report! I'm pretty sure I've tested this at some point in time where it probably worked, but indeed, now it doesn't. I did a quick test with https://micropublish.net/ too for instance, and nothing, so either the spec has been changed, or it's more relaxed, hard to say.

However, attached is a patch which made me able to authenticate on indielogin.com and micropublish.net. From a security point of view, it doesn't seem to be less secure not validating me, so I think it's fine.

Tests will probably fail, need to look at this (locally, they don't run anymore on the DA test infrastructure due to https://www.drupal.org/project/drupalci_environments/issues/3387737#comm... 📌 Split PHP image into php(cli/apache) and yarn(node/nightwatch) Needs review ), but it would be great if you could verify the login works now.

Thanks for all the maintenance love too! :)

I'm amazed the module usage is still so low, because it really is wonderful, so thank you for all the fantastic work!

@andreas no, just regulary entity forms, created an issue at 🐛 Entity translation does not necessarily exist Active

Pushed! (sorry, needed patches file for composer.patches for a couple of projects quickly, so did that first :)

Hmm, change record says 10.2.0, and in 10.4.x branch of DC too: https://git.drupalcode.org/project/drupal/-/blob/10.4.x/core/modules/fil...

Also, those validations area introduced in 10.2.0, so it's fine no?

10.2.x is EOL, so just up the constraint of the module to 10.3 - that's good enough imo. A new branch seems way overkill for that.

swentel → created an issue.

Ah crap, that was stupid sorry :) New patch.

swentel → created an issue.

better title

swentel → created an issue.

There's actually no guarantee there is a translation too for the entity. If not, it will crash

This is the current fix I have for now, but I'm not sure if it's the proper one. But at least it doesn't crash for now.

(which reminds me I should make a follow up for the formatter_settings crash, but close on a deadline atm)

diff --git a/src/Plugin/CustomFieldWidgetBase.php b/src/Plugin/CustomFieldWidgetBase.php
index 51e544cdf..00e5b26ea 100755
--- a/src/Plugin/CustomFieldWidgetBase.php
+++ b/src/Plugin/CustomFieldWidgetBase.php
@@ -112,7 +112,7 @@ public function widget(FieldItemListInterface $items, int $delta, array $element
       $langcode = $this->languageManager->getCurrentLanguage(LanguageInterface::TYPE_CONTENT)->getId();
       $is_default_translation = TRUE;
       $is_translatable = $field_definition->isTranslatable() && $field->getWidgetSetting('translatable');
-      if (!$entity->isNew()) {
+      if (!$entity->isNew() && $entity->hasTranslation($langcode)) {
         $entity = $entity->getTranslation($langcode);
         $is_default_translation = $entity->isDefaultTranslation();
       }

New release will install. It means the testbot won't be able to run anymore, but that's ok for now. See 📌 Allow lcobucci/jwt 4.3.0 for PHP 8.3 support Active

Remove the sodium replace and compat, but that means the testbot will fail always now

Actually, I've released 8.x-1.25 :)

Let's meet in 📌 Allow lcobucci/jwt 4.3.0 for PHP 8.3 support Active for the sodium extension.

Laste update: it's actually another commit that is still in dev that updated composer.json, that one is not in a release yet. Sorry for the noise!

Note: dev release indeed has support for D11 (added in 📌 Automated Drupal 11 compatibility fixes for indieweb Needs review ), but not release yet, need to fix the sodium stuff :)

More or less duplicate of 📌 Allow lcobucci/jwt 4.3.0 for PHP 8.3 support Active - I thought the sodium polyfill could work, but I have to double check again.
I /think/ it should work locally, but the testbot has a problem installing it, so it's kind of a chicken/egg problem.

Sorry for the delay, last commit, or attached patch should do it! Test (which I can only run locally for some reason) has a subtle change which indeed failed, but with the changes in Expert.php then passes!

yes, running 3.1.3

Using the debugger, it happens on the formatter settings for a file, using the file_default formatter.

Looking at the code, it looks like this line is the problem: https://git.drupalcode.org/project/custom_field/-/blob/3.1.x/src/Plugin/...

It's totally possible that $settings[$name] does not contain the formatter_settings key, which happens in this case for a file.

Getting an error which is related:

TypeError: Drupal\custom_field\Plugin\Field\FieldFormatter\BaseFormatter::createOptionsForInstance(): Argument #3 ($formatter_settings) must be of type array, null given, called in /home/drupal/web/modules/contrib/custom_field/src/Plugin/Field/FieldFormatter/BaseFormatter.php on line 463 in Drupal\custom_field\Plugin\Field\FieldFormatter\BaseFormatter->createOptionsForInstance() (line 101 of modules/contrib/custom_field/src/Plugin/Field/FieldFormatter/BaseFormatter.php).

diff --git a//src/Plugin/Field/FieldFormatter/BaseFormatter.php b//src/Plugin/Field/FieldFormatter/BaseFormatter.php
index 4cd0936e5..0e351ac0f 100755
--- a//src/Plugin/Field/FieldFormatter/BaseFormatter.php
+++ b//src/Plugin/Field/FieldFormatter/BaseFormatter.php
@@ -460,7 +460,7 @@ protected function getFormattedValues(FieldItemInterface $item, string $langcode
         $format_type = $formatter_settings['format_type'];
       }

-      $options = $this->createOptionsForInstance($custom_item, $format_type, $formatter_settings['formatter_settings']);
+      $options = $this->createOptionsForInstance($custom_item, $format_type, $formatter_settings['formatter_settings'] ?? []);
       $plugin = $this->customFieldFormatterManager->getInstance($options);
       $value = $plugin->formatValue($item, $value);
       if ($value === '' || $value === NULL) {

Hmm is it a change in core, or in field_group that triggers this error?