Live feed

shaesen → created an issue.

Latest bootstrap 5.2/5.3 only works with module v5.5. Reason seems to be classes named with „bs“ and only 5.5 has a correct template.

Looks like interface is required now.

https://www.drupal.org/node/3417034 →

Hello,

I do have the same issue. I just installed drupal (clean) so I do not have any other date modules and still the same issue.

+1

Can anyone provide the fix ?

Have seen the same issue and not found a solution yet.

mamoruua → created an issue.

marc.bau → created an issue.

The possible values are "before", "after" or "invisible" so it needs constraint and update hook to populate default value (BC)

Some warning should be visible in logs if update is not executed so UI should also warn about unconfigured option

PS: Left few comments in MR

oushen → opened merge request !2

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

After the release of Feeds 8.x-3.0-rc1 → , tests now pass. Merged the code!

I'm leaving the issue open for possible future automated fixes.

It would be good to test Commerce Feeds manually with the new Commerce 3.0.0-alpha1 release → before creating a new release.

mandclu → opened merge request !149

@tirupati_singh,

Yep, that looks to be spot on behaviour.
Great work!

mandclu → created an issue.

Hello @sime,

One solution is to work with Storybook and pre-design and test the styles outside of Drupal.
So Tailwind can compile them and the Tailwind classes you want to make available to CKEditor are available.

spokje → opened merge request !57

Alright. All checks are green! Merged.

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

spokje → created an issue.

Automatically closed - issue fixed for 2 weeks with no activity.

#30 is right and the way to go. Exactly. Still I think for the results it might be seen as (at least ux) bug (WSOD)

Most important is, that this doesn't cause a WSOD and non-technical users are entirely blocked...

Faced issues with Recipes and simpleConfigUpdate action.
📌 Fix Varbase Editor Default Recipe to Import/Update Configs and Follow Schema with Configuration Inspector Fixed

doing something like the following in a recipe will not work

config:
  actions:
    ace_editor.settings:
      simpleConfigUpdate:
        theme: idle_fingers
        syntax: html
        height: auto
        width: '700px'
        font_size: '9pt'
        show_invisibles: false

All checks are green! Merged.

Automatically closed - issue fixed for 2 weeks with no activity.

anybody → created an issue.

For the records: The approach taken here by crowdsec might also be interesting: 📌 Change scanning detection method to also work with Fast404 and other handlers Fixed

For the records: The approach taken here by crowdsec might also be interesting: 📌 Change scanning detection method to also work with Fast404 and other handlers Fixed

megachriz → opened merge request !57

socialnicheguru → created an issue.

Since https://www.drupal.org/project/drupal/issues/2766135 → was added to D8.9 and upwards, we aren't breaking BC since this module supports coree 9/10/11.

We can drop the DI of the $database in \Drupal\entity_reference_revisions\EntityReferenceRevisionsOrphanPurger::__construct.

I tried to follow the deprecation policy, but am better at that in core than in contrib, so I might be overdoing it and/or making mistakes there.
I didn't add union-typing to the constructor, since that's only PHP 8+.

megachriz → created an issue.

megachriz → opened merge request !18

Someone in another issue posted that http://drupal.org/project/message_ui already defines permissions.

It is odd that a ui module would define permissions.
If you were to disable it would the permissions also go away?

Maybe there should be a change in that module to move permissions into the base message module.

megachriz → created an issue.

could you see if there is a current language and then use default language if there is no current one?

@cilefen re #26 is there a related issue in that project or was that fixed in the meantime?
Eventually related to 💬 The following theme is missing from the file system: jquery_ui_draggable Active ?

Ah, the spelling isn't a mistake, it's because I'm not an American!

Ah okay. I'm not American either. But I'm also not English. I just happen to see that the MR failed cspell tests. I think that the standards on drupal.org are American English. For example, elsewhere I see that the word "color" is used instead of the British "colour". So I think we should follow the American English spelling here.

I'll see if I can find time to write the tests but I'm quite likely not to get around to it due to all the other things on my plate, sorry.

I understand. Then this issue will likely hang here for a while. My plate is also quite big and I do my best to prioritize Feeds issues. Currently I think there are many issues with a higher priority than this one, so this one then will have to wait.

tobiasb → created an issue.

dqd → changed the visibility of the branch 2.0.x to hidden.

Ah, the spelling isn't a mistake, it's because I'm not an American!

I'll see if I can find time to write the tests but I'm quite likely not to get around to it due to all the other things on my plate, sorry.

Heyya
I've combined the feedback.

Are you able to test PR 97 please.

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

Automatically closed - issue fixed for 2 weeks with no activity.

This looks like a good approach.

It does require fixing to tests and spelling:

• "initialise" should be "initialize". See https://git.drupalcode.org/issue/feeds-3444986/-/jobs/2639453
• LazySubscriberTest should be updated. See https://git.drupalcode.org/issue/feeds-3444986/-/pipelines/272937/test_r...

And I think that this requires test coverage:

• Add a test case to \Drupal\Tests\feeds\Kernel\UpdateNonExistentTest that demonstrates that content is cleaned when the source is empty.
• Add a test case to \Drupal\Tests\feeds\Kernel\UpdateNonExistentTest that ensures that content is not cleaned when there is a fetch error. For example when the HTTP Fetcher receives a 403. Perhaps this case can be simplified with a custom fetcher that throws an exception of some kind. I think that a \Drupal\feeds\Exception\FetchException gets thrown on a 403.
• Add a test case to \Drupal\Tests\feeds\Kernel\UpdateNonExistentTest that ensures that content is not cleaned when a fetch resulted into a case where no data changed. The HTTP Fetcher receives a 304 in that case and throws a \Drupal\feeds\Exception\EmptyFeedException. Perhaps this case can be simplified with a custom fetcher that just throws a EmptyFeedException.

Automatically closed - issue fixed for 2 weeks with no activity.

almunnings → opened merge request !97

anwar_max → opened merge request !4

Automatically closed - issue fixed for 2 weeks with no activity.

anwar_max → created an issue.

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

Changed the ExcerptFieldTest fix to use a custom key-value store, as suggested. CI passes, so I merged.

Also, the Core issue ( 📌 sebastianbergmann/comparator:5.0.2 Introduces (for Drupal) breaking changes Fixed ) has been fixed, so once the MAX_PHP_VERSION test uses a Core version with that change included, we can get rid of our custom override to ViewsDisplayCachingTest::assertViewsCacheTags().
I created 📌 Remove our custom ViewsDisplayCachingTest::assertViewsCacheTags() override Postponed as a follow-up to do that.

Thanks for the offer, very kind of you!
At this point I’m just not sure I even want to make that change – would it help more, or be disruptive itself? As I haven’t really had people complain about this, as far as I remember, I’m currently leaning more toward the latter and closing this as “won’t fix”, but I’ve asked for feedback via Slack.

I agree, thanks a lot for weighing in!

A test is failing now, someone please needs to take a look. Thanks!

Actually, in D11, all but one or two of the Core plugin types have been converted to Attributes already, and those few are being worked on.

I’m aware of that, but that doesn’t help us at all as long as we support Drupal 10 (which we will for quite some time). I sincerely hope Drupal 11 won’t remove plugin discovery by annotations as long as they support versions that still rely on annotations for some Core plugin types, as that would be an absolute nightmare for a lot of contrib maintainers.
Or do you know if that is seriously being discussed? If so, is there a particular issue for that?
As far as I can see, annotations remain to be supported for all plugin types (except those added in Drupal 10.3+) even in Drupal 11.x HEAD.

I also don’t quite understand your reasoning for wanting the addition of attributes to be restricted to a 2.x branch of the module. If we keep support for annotations, too (which we definitely will as long as possible), then what is the problem of adding the attributes in a minor release? You can depend on that in your modules just as easily as on a major release.

To summarize, I propose the following:

1. Any time we upgrade our minimum supported Core version, convert all our plugins to use attributes where supported by that Core version. (I.e., I think for all except entity types once we depend on Drupal 10.3 in December 2024, and then convert the entity types once we depend, probably, on 11.1 (depends on when Core completes 📌 Convert entity type discovery to PHP attributes RTBC ).
2. In the first such MR, also add attribute discovery for all our plugin types, but keep annotation support as well.
3. Only when necessary to support the latest Drupal version (shortly before Drupal 12.0 gets released, I assume, if that drops annotation discovery support) drop the annotation discovery from our plugin types. (Or maybe not even then, if easy to support using DeprecationHelper. In that case we’d only drop support once our minimum supported Core version doesn’t support it anymore.)

Please tell me if you see any problem with that approach.
If not, it would be a great help if you could already work on that first MR that depends on Drupal 10.3, yes. (I’ll gladly help keep it up-to-date until we can merge it in December, but I don’t foresee many changes would be necessary.) Or, I guess, we can also do a first MR right away that only transforms our own plugin types, if you prefer.

tobiasb → closed merge request !1

No : since D8, you no longer need a module like this one: everything needed is pretty much already in core.

Automatically closed - issue fixed for 2 weeks with no activity.

Automatically closed - issue fixed for 2 weeks with no activity.