🇨🇦Canada @joelpittet

joelpittet → created an issue.

I thought the Slack channels were public in some kind of archive system someplace... but my memory has failed me as I can't find that, so... yeah it's a "walled garden". And yeah, we won't solve that here. I miss IRC... but it had it's own challenges, they all do... sigh 😮‍💨

MR76 has a merge conflict and may have been resolved. So I opened up MR77 to add some tests to cover the different cases of first day of the week.

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

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

Thanks for everybody reviewing and contributing. I hope this change is a positive one. LMK if anything is awry.

Thanks for testing @loze, is this something you're looking for as well?

The MR 1 there is an untested AI generated port. Feel free to take from it, build on it or close it...

Hi @vijaycs85, yeah your right I haven't been to the conferences in some time, one day I'll be back!

The 2.x branch ready and added you as a maintainer, fill your boots!

Committed to the 4.4.x branch

Moving to the active branch and reroll

Everybody does cron different, this is mine for example, where I email if anything produces output:

MAILTO=security@example.org
PATH=/usr/local/bin:/usr/bin:/home/USER/bin

# Check composer security audit once a day.
35 8 * * * /home/USER/bin/composer_audit

And for drush in vendor bin with relative I have this in my dot files (zsh profile)

# https://github.com/drush-ops/drush-launcher/issues/105
function drush () {
  $(git rev-parse --show-toplevel)/vendor/bin/drush "$@"
}

Minor tweaks

@erutan good idea, I removed the D7 stuff and replaced it with

Note: While multiple 4.x minor branches are published and marked supported, only the latest minor release is actively maintained. Older minor versions remain available as to mitigate update status "unsupported" warnings but will not receive updates or fixes.

@ressa You summarized the problems really well in #5. The Slack thread is quite long, and I’m not sure everyone involved would want me to re-post it all. Thanks for turning my script into a docs page — that’s very kind of you! I will poke over there and have a look.

I think the core issue is infrastructure-related, but I’m hesitant to dig into that right now since the ongoing GitLab migration might address these problems anyway. Once we see how Drupal core interacts with those changes, that’ll be the right time to revisit.

You're welcome to port it, I have no plans. Do you want maintainership?

We don't need to make this change... yet, but we will for the views hooks. Postponing till this comes back as we have a solution. If you feel we should refactor now, please unpostpone. I'm taking a YAGNI approach here, only implement something that is an actual needed solution.

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

https://git.drupalcode.org/issue/calendar-3545207/-/jobs/6441023
Ghost in the machine? Not sure where these function calls are coming from. That was replaced a while ago... 📌 Replace deprecated node_type_get_names() calls with entity_type.bundle.info service Needs review

joelpittet → created an issue.

Updating the Issue summary because this doesn't improve week view. That one is currently pretty bad too. Here is screenshots showing D7 vs D11 with and without MR applied.
It's a different style but I think good and much better than the broken state otherwise.

I will merge soon, thanks @ramil g

D11 with MR applied
→

D11 without MR applied
→

D7
→

Putting it at Needs Review to get any eyeballs but I think it's pretty good at the moment. I will take some screenshots of before after before committing.

This is both a simple issue and really complex. I will ultimately leave it up to Graber to re-enable it or not, as he may have had reasons for it.

I've done the same and asked maintainers to re-enable versions (that I am on) for the sake of the implicit security issue of an unsupported version. Here is a long thread on the matter here: https://drupal.slack.com/archives/CJ93UNJP4/p1663006787389719

Basically, the d.o. project page can treat minors as majors (historical reasons). Even though we might be using semver and supporting 4.x. The drupal core update status will think it's unsupported when it's not shown up here. This might be worth trying to solve in core... but I took the stance earlier this year to disable the emails and replaced it all with a little cron job that did `composer audit` and email me on results.

Here is that script if anybody wants a better workaround (catches dependencies too):

#!/bin/bash

# Pull the latest changes and run a Composer audit.
# Exit code meanings:
# - 0: No vulnerabilities found.
# - 1: Vulnerabilities detected.
# - 2: Errors occurred (e.g., missing lock file, configuration issues).
/usr/bin/find /PATH/TO/ALL/YOUR/SITES/ -mindepth 1 -maxdepth 2 -name '.git' -type d -execdir sh -c '
    # Reduce HTTP concurrency to avoid transient Packagist timeouts.
    export COMPOSER_MAX_PARALLEL_HTTP=${COMPOSER_MAX_PARALLEL_HTTP:-2}
    git pull -q
    # Only run in repos that actually use Composer.
    [ -f composer.json ] || exit 0
    audit_output=$(composer audit --locked --no-interaction --no-dev 2>&1)
    result=$?
    case "$result" in
      0) ;; # No vulnerabilities found.
      1)
        echo "$(pwd):"
        echo "$audit_output"
        ;;
      2) ;; # network timeout: skip silently to avoid cron mail
      *)
        echo "$(pwd): unexpected exit code $result"
        echo "$audit_output"
        ;;
    esac
' \;

Set it on a cron with an email and voila, low-rent checks.

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

Sorry @gokul.jayan there is too much scope creep in this MR, please remove all unrelated changes to the role=tab issue.

Awww man, sorry my steps didn't reproduce the issue I reported. I don't currently have any additional context I could add to this and it looks like nobody else has run into it yet. I will close as can't reproduce until someone else stumbles this way, or I have more to offer.

It was tricky to trace back where the exception was happening, but the callstack was drawing me here 😉

Oh nice, thanks for the test coverage!

I saw it in the project page still. Not sure what happened, "Submission guidelines" under the Issues vertical tab still so removed it. Thanks for reporting that @gogowitsch

We could close this as duplicate or re-scope resolve the inevitable views.inc issue?

The main issue was fixed upstream in Drupal core 🐛 Avoid passing null from $entity->label() when no label key is defined in EntityListBuilder RTBC

joelpittet → changed the visibility of the branch 3549604-OgMembership-label to hidden.

Similar for sure but the fix here was directly related to the issue I mentioned. Though maybe the treatment can be the same?

joelpittet → created an issue.

The code committed so far is addressing a different deprecation but I think the crux of the issue is related to routing params were magical and now they are not? I am scouring diffs to see where this change might originate.

The code so far is mostly trying to address https://www.drupal.org/node/3483599 →

Thanks for your help ensuring I didn't break things with this refactor @ramil g

@finnsky Right, re #94 we’re on the same page: aria-labelledby and aria-label give equivalent results, so it’s good to confirm the principle.

The snag is in #97: with the current MR the block title is gone entirely. In navigation_menu.html.twig we dropped both the <nav aria-label="{{ title }}"> and the hidden <h4>{{ title }}</h4> so nothing else outputs the name. That leaves a single sidebar landmark full of unlabeled lists. I looped @katannshaw as she mentioned this earlier up and we really do need to surface that label somewhere... either by restoring the hidden heading or wiring the title into an aria-label/aria-labelledby — so each navigation block remains discoverable. Two landmarks is fine, but we still need names for the menus inside them.

In a (hot) minute I will do a test locally with the instructions for @katannshaw mentioned above as it clarifies what I couldn't sort out of what

VO means for keyboard shortcut
so VO + F1 means Control + Option + F1

That was throwing me when I tried to test this out the first time, I couldn't figure out VO meant.

Again, I am not an expert, but I also don't want to lose valuable information for those who need it, so if you can prove it's not needed, I’d be happy to hear that advice too. Just nobody mentioned the reason behind dropping it, from my scan of the comments.

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

Thanks for the twig coding standard fixes, sorry I can't mark them as resolved in gitlab @grimreaper.

@catch Thanks for taking a stab at figuring out why the menu title/label was dropped!

I suspect that’s exactly why the aria-label/heading disappeared, but the result is that each navigation block now renders as an unlabeled list “Shortcuts”, “Content”, “Create”, etc. never reach the DOM when the block label is hidden in config. We still need an accessible name for each block even if we drop the redundant , so I’d like to restore a hidden heading or similar so screen readers can differentiate those sections again.

I would like to end in that I am not an a11y expert nor do I use a screen reader, so feel free to overrule me if someone on this thread is, I just don't want things to unintentionally get worse for those who need it. I'll try to reach out to @katannshaw in Slack to get a take as that was very well described in #31.

@katannshaw in #3452724-31: Navigation side bar and top bar should have appropriate aria labels → #31 laid out that the title should persist very well and it looked like someone added it back as aria-label in https://git.drupalcode.org/project/drupal/-/merge_requests/11122/diffs?c... I didn't see where it got dropped again but just wanted to raise that is is gone and want to ensure that is intentional and not incidental.

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

Closing as there has been no update in 11 months from the questions in #4. Feel free to reply if there are more details or create a new issue with more clear steps to reproduce.

I am about to release a fix for repeat rules Closing this as fixed

This was fixed thanks @stevewilson for RTBCing this Nov 26, 2023 4bb4c259

Thanks again @ramil g and @franceslui for getting this sorted out. I will make a new release in a moment.

Thanks for following up @4kant and I am glad you got something working.

It's amazing to have Müller, I hope I get to see him play soon.

I hope to cut another beta shortly, maybe even today.

Tests working again

As maintainer I have been making steps to getting 8.x-1.x working for moving from D7. Is that the version you are all testing, and have you tried the dev branch? If you are referring to 8.x-1.x , can you update the version for this issue?

As maintainer I have been making steps to getting 8.x-1.x working for moving from D7. Is that the version you are all testing, and have you tried the dev branch? If you are referring to 8.x-1.x , can you update the version for this issue?

As maintainer I have been making steps to getting 8.x-1.x working for moving from D7. Is that the version you are all testing, and have you tried the dev branch? If you are referring to 8.x-1.x , can you update the version for this issue?

Thanks I am committing the changes. Looks good to give the args more context from the view/display.

Thanks @franceslui I have committed to the dev branch.

joelpittet → created an issue.

Fixed and backported to 3.8.x

@franceslui, I agree with your proposal to remove it. And considering it's optional, there is no clear commit around it's introduction, and D7 didn't use it, that seems like the right move. Can you create an MR and make that change, I'd be happy to review and commit that.

@konot, are you assigned to tackle implementing this? Thanks for creating this nevertheless! I ask because I tend to no use that field as people forget they are assigned, life happens, and it holds it up from progressing the issue.

joelpittet → created an issue.

💯 with @kristen pol. I am maintaining and jumping around and missing notification emails left and right. I use the user dashboard as a “catch-up" area to look at the most recent stuff — when I have time and declare bankruptcy on the rest!

Even if you can track the save button was clicked as a "flag" to the contribution was acted upon, and create a report on the un-acted upon, I think that would be immensely helpful as I can treat it like a catch-up list — again when I have a moment free.

@franceslui RE #6 Ah, that is clearly related, it split on the comma separated EXDATE values as if they were part of the same set.

Thanks for the explanation about the semicolon split!

joelpittet → created an issue.

RE #4 @franceslui, I appreciate the details and I’m inclined to agree that WKST=Array may be related, but I didn’t see how you arrived at that conclusion from the comment. Could you share the steps you used to determine the linkage vs. WKST=Array being separate issues? For example, did you remove the EXDATE/RDATE content from the rrule column and retest to see whether WKST is output correct or something like that?

You also mentioned the current MR !10 doesn’t fix the problem. I agree: as it stands it appears to emit EXDATE/RDATE on their own lines, but it doesn’t remove those values from the RRULE line.

I’ll get it back up to working (or perish trying)

joelpittet → created an issue.

joelpittet → created an issue.

joelpittet → created an issue.

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

Committed these on the 8.x-1.x directly by accident, here's the commit messages.

commit b1743b568fd8a34ef97448347c39ac31a7bf8606 (HEAD -> 3546011-replace-deprecated-node_type_get_names, calendar-3546011/3546011-replace-deprecated-node_type_get_names)
Author: Joël Pittet <pittet@cs.ubc.ca>
Date:   Wed Sep 10 09:32:54 2025 -0700

    Fix node_type_get_names() deprecation

commit 8460b451f22bef9a8460c67dffcb220cdebd45a4
Author: Joël Pittet <pittet@cs.ubc.ca>
Date:   Wed Sep 10 09:30:11 2025 -0700

    Update PHPstan and don't allow failures

joelpittet → created an issue.

joelpittet → created an issue.

Thanks, this one was a doozy, I have committed it to 2.x

Thanks a bunch @phenaproxima created that follow-up 📌 Refactor form to use getEditableConfigNames() and $this->config() instead of injecting config Active

joelpittet → created an issue.

joelpittet → created an issue. See original summary → .

Merging this in to fix the brittle tests. We can adjust the CONTRIBUTING.md later.

Oh what is the ruleset you don't have? You might be able to add it to your composer global if you can pick it out of the require-dev dependencies.

@maskedjellybean RE #20 I have been trying to get DDEV contrib to help make this question not a thing, but there is documentation here that is generic enough that should get you over the hump:
https://www.drupal.org/node/1419988 →

I will first try to get it into date_recur 📌 Add DDEV Drupal Contrib for ease-of-maintenance Needs review , then do the same thing here. Please do have a peek at that issue, especially if you are familiar with DDEV already for your local environment.

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

joelpittet → changed the visibility of the branch 3501637-add-a-group-index to hidden.

joelpittet → changed the visibility of the branch 2325899-10.3.x-refactor to hidden.

I rerolled, diffed the diffs after — no changes other than context lines (and index hashes). And diffed the MR 3751 against #213 🐛 UI fatal caused by views argument handlers no longer can provide their own default argument handling Needs work

Trying to help this along... next I plan to review the unresolved comments, so leaving as Needs Work.

I will hide the other MRs to keep the focus on that one.

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

Forgot to change to needs review after adding the tests and attempt to shore this up by moving the logic onto the plugins.

Thanks again for digging into this @ramil g.

Thanks, @ramil g. It sounds like a good point to allow other implementations—aka, let the wrapper wrap instead of always guessing. Marking fixed and pushed to the dev branch.

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

Nice 🚀and thanks for exploring that nuance with me @albeorte

Oh and please do try 8.x-1.x branch, I need to cut a new beta soon but there are lots of improvements in there (and tests to back them up now).