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.
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.
-
tobiasb →
committed 52e18c90 on 3472851-phpstan authored by
jamsilver →
Issue #3293638: Fixes for latest version of migrate module
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.
-
megachriz →
committed c67ec85d on 8.x-1.x
Issue #3429338 by megachriz, Project Update Bot: Added Drupal 11...
mandclu → opened merge request !149
@tirupati_singh,
Yep, that looks to be spot on behaviour.
Great work!
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.
-
tobiasb →
committed 52e18c90 on 8.x-1.x authored by
jamsilver →
Issue #3293638: Fixes for latest version of migrate module
spokje → opened merge request !57
Alright. All checks are green! Merged.
-
megachriz →
committed eea16e9d on 8.x-2.x
Issue #3472853 by megachriz: Fixed PHPStan issues in tests.
-
rajab natshah →
committed e09bb599 on 2.0.x authored by
mortona2k →
Issue #2941227: Fix missing install/schema to support configs with...
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.
-
megachriz →
committed 061c6803 on 8.x-1.x
Issue #3472854 by megachriz: Fixed PHPStan issues in tests.
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.
dqd → changed the visibility of the branch 2.0.x to hidden.
-
tobiasb →
committed 5c128a55 on 8.x-1.x authored by
jamsilver →
Issue #3309559: Remove explicit mention of basic_html text format
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.
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 →
committed a3bd6ded on 8.x-1.x authored by
jurgenhaas →
Issue #3327614: Catch \League\Csv\Exception in validateImportForm to...
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.
-
drunken monkey →
committed 9f654bae on 8.x-1.x
Issue #3470166 by drunken monkey, berdir, catch, mstrelan: Fixed test...
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:
- 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 ).
- In the first such MR, also add attribute discovery for all our plugin types, but keep annotation support as well.
- 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.