🇨🇦Canada @joelpittet

Oh sorry, I was just trying to reproduce a bug but ran into this, if they are identical then yeah it doesn’t matter, sorry to bother. My bug was in environment_indicator in the end.

Thanks @harkonn for testing it out!

I guess I changed the code so Needs Review is appropriate, I deleted those CSS lines that were marked for removal

This still fixes an issue with gin compatibility (even without the JS) but I will re-roll.

Here is what it looks like before the patch:

Just bumping this fix as I see somethings getting committed

joelpittet → changed the visibility of the branch 4.x to hidden.

@jurgenhass thanks for fixing this I thought I needed to. I created this dupe 📌 Allow gin_toolbar 2.0 to install Active

Could you do a patch release when you get a chance? Thanks for updating this!

Sorry actually this is a duplicate 📌 Clean-up composer constraint for gin_toolbar Active

Sorry I miss read composer output, my bad...

joelpittet → created an issue.

We used MR 52 to explicitly fix this error in preview (usually I don't enable preview on nodes...)

This seems to fix the problem for us.

joelpittet → created an issue.

@Nick Dickinson-Wilde had the permission, gave me the permission, who in turn gave you the permission @smustgrave.

Welcome to the team.

I am hoping the composer and info.yml changes will deal with the new module dependency.

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

I looked and I don't have the permission to add new co-maintainers, maybe reach out to @shelane as they added me this year 📌 Offering to co-maintain quicktabs Fixed ?

Adding tag back from #245 as it I think it was accidentally removed.
We tested MR7501 and it will solve our immediate requirement.

@milos.kroulik we tried conditional_rendering and it doesn't seem to solve what this issue is trying to solve. It also only works for block_content so not other block types, or simple_block for example.

Thanks @vensires re #9, I came here for that. And thanks @berdir for diving into the deep-end on this problem.

Thank you @ramil g again. That fixes a bug where the class Date was reading from itself!

joelpittet → changed the visibility of the branch 3163197-allow-hiding-configured to hidden.

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

Thanks again @lavanyatalwar I have merged the MR.

Yes, “reorganizing the entire admin menu” is definitely out of scope! 😄 The issue largely stems from contrib modules adding their own admin pages under existing ones or creating nested subpages (but core too as screenshoted in #44 🐛 Second level menu items can't be reached if they have children Active ). Addressing this by fixing contrib would likely require more effort and education than working with the existing patterns commonly used.

The article raises valid concerns about split buttons in navigation, it might overstate their universal unsuitability. Instead of relying solely on these arguments, we should test those concerns ourselves, perhaps against @scott_euser propposal in #6 🐛 Second level menu items can't be reached if they have children Active , to see how they hold up in practice. A balanced approach that evaluates context, user needs, and new design tricks might reveal a more nuanced view of this pattern. Safe enough to try?

@lavanyatalwar That is great, yeah leave those, is there a way in style lint to explicitly ignore like phpcs:ignore? I'd also be happy to have them moved to a comment, as they are only there to document what is at your disposal

Thanks @megachriz, I was going to post there (I linked it as a parent issue) but I wasn't quite sure if it's related. The feeds_clean_list seems to trigger this issue in my case because it always starts fine. I unlock the feed, it seems to work for a bit, then starts with that error, then later this tempnam() keeps happening.

I feel like I am missing something in this and started a new issue as to not conflate the issues (yet) until I know for sure.

joelpittet → changed the visibility of the branch 8.x-1.x to hidden.

More context: this is stored in our private directory which is mounted NFS, outside the webroot and this is only happening on 1 or 2 feeds at the moment. The other feeds seem to be fine.

And it seems to happen on cron every hour after this error

Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '9-141838' for key 'feeds_clean_list.PRIMARY': INSERT INTO "feeds_clean_list" ("feed_id", "entity_id") VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1), (:db_insert_placeholder_2, :db_insert_placeholder_3); Array
(
    [:db_insert_placeholder_0] => 9
    [:db_insert_placeholder_1] => 141838
    [:db_insert_placeholder_2] => 9
    [:db_insert_placeholder_3] => 141914
)

The feeds are triggered every minute, though maybe the solution is to stop that...

joelpittet → created an issue.

Thanks for your help on this @lavanyatalwar

This looks great everyone, nice work!

Thanks for clarifying @wheelercreek

I’m exploring a potential solution by parsing the Styles plugin to dynamically add or update span elements. This would allow editors to define and manage styles more flexibly without creating a new plugin or allowing source editing workaround.

Would there be interest in pursuing this direction? Any thoughts or concerns?

The split button proposed by @scott_euser in #6 🐛 Second level menu items can't be reached if they have children Active seems like the most intuitive direction here. I also share the concerns raised about the additional ‘Overview’ injected links.

@ckina and @lauriii could you give this a second look?

This affects a number of modules I have co-maintainership of such as:

• Menu Position →
• Calendar → (by way of dependency Views Templates → )
• Feeds →

And simple_block as mentioned previously and core's Display modes all under Structure I might add. Overview seems to make sense for Configuration at a glance but not Structure. Though I believe the Split button approach is more versatile.

Thanks @scott_euser that is where I should have commented.

I am seeing what's been reported in #12 by @anruether and echo'd by @scott_euser in #19.

Boils down to second level parents are not possible to to navigate to because the entire item is intended to toggle the children.

The primary menu item parents are possible to navigate to, though you need to click twice as they open those items. One to open the children and on the header of the children.

Proposal: split button for the arrow? I was going to give you an example of a site I did, but just saw that I broke the JS on it while I was getting the link, lol... there goes my day...

@lavanyatalwar leave that commented code, don't change the indents or delete it, it needs to be evaluated to see if it's needed (beyond scope of this issue)

Back to RTBC, thanks for removing the test as well ivnish

joelpittet → created an issue.

@lavanyatalwar Thanks for taking this on. There is a lot of commented code, so don't worry if you don't get them all, any progress on this is great.

A tip: When working on Drupal issues, avoid assigning them to yourself unless you’re actively fixing them. Assigned issues can give the impression they’re in progress, even if they’ve been set aside. Instead, leave a comment (as you did) with your thoughts or progress, and make small commits to contribute towards a solution. This keeps the issue visible and encourages collaboration.

joelpittet → changed the visibility of the branch 3489746-phpcs to active.

joelpittet → changed the visibility of the branch 3489746-phpcs to hidden.

joelpittet → changed the visibility of the branch 8.x-1.x to hidden.

Thanks @ramil g, one less blocker!

I removed the authors as well because they aren't working on 1.x branch

joelpittet → created an issue.

Got most of the cspell issues resolved and everything else was added to the project words file to ignore.

Is this also for 2.x or 1.x? There is this reported for 🐛 Duplicate Events showing up when there are multiple event dates Active that sounds similar

Actually I will re-open this so I can attribute people that reported it.

joelpittet → changed the visibility of the branch 3489747-fix-and-require to hidden.

joelpittet → changed the visibility of the branch 3489748-fix-and-require to hidden.

joelpittet → changed the visibility of the branch 3489746-fix-and-require to hidden.

joelpittet → changed the visibility of the branch 3489745-fix-and-require to hidden.

joelpittet → created an issue.

joelpittet → created an issue.

joelpittet → created an issue.

joelpittet → created an issue.

joelpittet → created an issue.

@noregrebt, could you give me some minimal steps to reproduce this bug? I will gladly try this out to see what you are seeing.

This looks great, thanks @ramil g. I will drop Drupal 9 support because they technically need PHP 7 support and the match statement isn't available until PHP 8.0.0

This looks great, thanks @ramil g. I will drop Drupal 9 support because they technically need PHP 7 support and the match statement isn't available until PHP 8.0.0

A change to the query to avoid

Expression #1 of HAVING clause is not in GROUP BY clause and contains nonaggregated column 'db.users_field_data.mail' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

1. Accessing argFormat via a getter method:
   

   • The code now checks if the getArgFormat() method exists using method_exists(). This ensures compatibility with the patch in issue #2325899 while maintaining backward compatibility if the patch isn’t applied.

2. Providing default values for other date argument classes:
   

   • The method includes specific cases for additional date classes, such as WeekDate, MonthDate, and DayDate, providing appropriate formats for these cases.

   • It adds a sensible default ('Y-m-d') for any unhandled cases, ensuring that the method will always return a valid date format.

joelpittet → created an issue.

I thought we could keep committing to a merged MR similar to what I have done in gitlab but apparently not.

I have merged it though here https://git.drupalcode.org/project/calendar/-/commit/a026ab7b18fea50a16c...

With some cleanup with phpcbf in this commit
https://git.drupalcode.org/project/calendar/-/commit/69f417e1c26f5bfe6f1...

That closes out the need to have Tests added to the calendar module thank you @ramil g, @franceslui, for the commits and @Diego_Mow for reporting it on behalf of the "phpunit initiative"

Thanks @ramil g I think that answers the question.

I recommend 1.x branch instead of the 2.x branch because we are giving it more attention as it's a closer port to D7.

Thanks @ramil g I will merge the MR in a moment.

I am going to move ahead with this change while I have momentum. Now there is less conflict and more CSS points to hook into to and modify with a reasonable (looking) default.

I will close this issue when we have

@johnv I was thinking the same thing but that would mean it would only be added when the view has the CalendarHeader area in there... The MR looks better at this point but maybe there is somewhere a little less global we could add it?

@sagarmohite0031 that must be the patch, the MR should look like my screenshots.

joelpittet → changed the visibility of the branch 3196394-test to hidden.

That seems to fix it in my quick test

joelpittet → created an issue.

Shouldn't the granularity need to be seconds and not minutes (in the patch)

-      $form_state->setValue(\array_merge($valueParents, ['time_start']), '00:00:00');
-      $form_state->setValue(\array_merge($valueParents, ['time_end']), '23:59:59');
+      $form_state->setValue(\array_merge($valueParents, ['time_start']), '00:00');
+      $form_state->setValue(\array_merge($valueParents, ['time_end']), '23:59');

I would assume 23:59:59 would be the fix here?

This might be good to have a test case to cover this bug report?

Seems like a nice UI improvement, hides the occurrences button where there are none.

Just so nobody gets tripped up by this, I fixed the Drupal 11 composer mentioned in #19 issue in 🌱 Add Tests and enable gitlab-ci Active

There are lots of rough edges in the beta release. I am hoping to iron a bunch out and add some tests.

I am hoping this will do the trick, the default pager classes conflicts with too many other theming elements and Olivero goes it's own approach.

This makes the pager a bit closer to Full Calendar and could fairly easily be themed like that. I added some SVGs for good measure

There has been no response so I am going to close this as fixed but also can't reproduce as per comment #11 but I am glad you both agree and there is an ISO-8601 to back up the decision

This one is kinda funny PagerPluginBase overrides that with "Unknown" but "PluginBase" has "Settings".

Thanks again @marc.bau and @vensires

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