🇺🇸United States @mradcliffe

teknorah → credited mradcliffe → .

I guess on new installs it gets the new release so not Major. I think it could be a Minor to just ditch the extra dependency and bring in its classes into diff module.

It will remove the need for the hook_requirements, phpstan overrides, etc...

It seems to me that mkalkbrenner/php-htmldiff-advanced is pretty much abandoned. I don't think the diff module should rely on it. Since it's GPL-2.0, the 2 classes could be brought into this module and the dependency changed to a recent version of caxy/php-htmldiff.

I think this should be elevated to Major since PHP 8.4 is supported by Drupal 11.

I'm not sure all of these extensions are necessary for Drupal formatting, but I may be missing something.

I think a zip file of .vscode folder could produce conflicts depending on the work environment and project that someone is working on and may lead to a developer accidentally removing settings or extensions that they use.

recommendations might be a good addition to the mentoring project's extension that's currently in use with DrupalPod.

Thank you, alison.

I got an answer on the BoFs so I

Thank you for creating the issue.

I think a fix to 🐛 Checkbox not displayed when session cookie expires and Agreement page is shown again Active would probably resolve this as well.

Thank you for creating the issue. I'll try to resolve this week.

I attended.

+1 on RTBC. I've been using jsonlog 4.0.0 with this merge request applied.

I went ahead and just made the change in the merge request.

This proves the merge request works as-is with the 4.x branch on Drupal 10 and will work with Drupal 11 as soon as 📌 Automated Drupal 11 compatibility fixes for jsonlog Active is merged as well.

I think this should work for Drupal 10.3 and 11 compatibility for the 10.x branch.

I did not attempt to fix any other phpcs or eslint issues after I added in gitlab ci integration. I followed one of the core patterns for removing the deprecated ContainerAwareTrait (LoggerChannelFactory does the same thing).

This needs manual testing.

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

Thanks for reporting the issue. I'll start by adding a test.

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

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

Unfortunately it is a breaking change. The best we can do is update menu_link_content, path_alias and views. I think any other custom module or contrib module is out-of-scope.

Propose:

- hook_update_N to update menu_link_content entity (if menu_link_content installed)
- Maybe add a path alias for every menu_link_content entity affected (if path_alias installed)
- hook_update_N to update any path alias entity (if path_alias installed)
- post update to update view configuration (if views installed)
- Change record + release notes

This could be done in a new 2.0.x branch.

Testing locally and writing a test reveals that the plugins are listed appropriately on a new install and Posts to Xero is checked by default.

The warning still needed to be fixed though.

It would need to source env vars that are used in .gitpod/drupal scripts, not ddev itself.

mradcliffe → created an issue.

Thanks for your fixes on the merge request, @dlevchik.

The module currently does not have any unit or functional tests, but it still runs through phpcs and phpstan jobs in the pipeline. In the merge request, the Code Quality and Test summary collapsible sections show any current test or "test" result.

mradcliffe → created an issue.

I made progress on a DrupalPod quicksprint on my fork ("Option: Revive the DDEV Quicksprint project"), and I think this is a good fallback to "Option: Replace with a Gitpod-like system". We can't do "Option: Let contributors learn enough of Drupal.org and git to navigate contribution themselves, using their own local environment." for on-site contribution events because we'll destroy the network or get auto-blocked, but that option is the recommended development environment for experienced developers.

Anyway I'm able to run ./start_sprint.sh to spin up DrupalPod locally.

My to do list:

- I need to bring in my work from mradcliffe/docker-core-sprint to package up Docker images since the ddev images tarball is no longer distributed. These need to be both the amd64 and arm64 images (oof).
- Update documentation regarding system requirements.
- Rename sprint to contribution or contrib.
- Get some upstream hacks into DrupalPod (merge requests created) - 📌 Running project_core locally runs composer outside of ddev Active
- Clean up use of DrupalPod environment variables. It would be nice to contribute dot env support back to DrupalPod.
- Get more USB drives for the Mentor Box.

Unable to reproduce either issue on latest release.

Closing issue for unsupported release.

Closing issue for unsupported release. This is working as-is in newer releases.

Closing issue for unsupported release. This is working as-is in newer releases.

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

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

I created a merge request based on @dewalt's patch and committed with them as the author of the commit.

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

I updated the README and project page, but the README has more in-depth documentation to explain what a strategy is and how they're used in some examples in the merge request.

I think rather than do that, we can just change getEnabledPlugins to always return an array rather than be nullable.

I had a user report this in a contrib. module of mine outside of the recipes work flow. I don't have any additional steps to reproduce yet, but I think it could also occur not just in recipes install but some other fatal error on module install.

The test server vs local has me confused. I am not sure why it would not install on one and not the other.

The error references views and the optional view that comes with the module. I installed on a fresh commerce environment after ensuring 10.4 was up-to-date and I found no changes from the view after I was able to install the module locally.

Since the error is a warning, that may not be related at all to the WSOD. It may be a race condition in Drupal core.

There may be a different error in the PHP or Web server error logs. Maybe memory usage? I don't think that would matter unless it's trying to install Commerce, Address, State Machine, Xero and Commerce Xero all at once.

Thanks again.

Those instructions are outdated now that Drupal 7 is no longer supported and refer to the module from Drupal 7.

I think updating the README now that the module is mostly usable is needed and then updating the project page would be the next steps.

I linked to the project repository page on GitLab on the drupal.org project page. That page renders the README.md file and contains the same steps above, but more detailed.

I updated the project page with the newer terminology.

Let me know of any additional questions that need to be answered to clarify usage. I think that it may need to link to some contrib. modules that make use of Xero API or link to the xero_example module.

Thank you so much for creating an issue. Yes, Xero has changed their terminology over the past few years.

I think the instructions on the Xero Configuration form are up-to-date, if that helps you in the short term to get started. You should be able to visit or https://developer.xero.com/app/manage after logging into Xero. And "Web App" is the equivalent of a private application in the options.

1. Install xero module.
2. Visit the the Xero Configuration page from Administration > Configuration > Web Services
3. Copy the pre-filled value in the "OAuth 2.0 redirect URI" textfield.
4. Follow the link labeled "Xero's Developer Portal" in a new window or tab. Log into Xero.
5. Choose Web App and paste in the Redirect API for the Xero app.
6. Copy the Client ID and Secret back into your site’s Xero Configuration page.
7. Press the Save button
8. Press the Authorize button to grant the site access to the Xero application.

I hope this helps.

A week later than I mentioned I would get to this from the last meeting, I made Alison's and my edits to Kristen's branch, and merged into Chris' main branch.

The test failure is probably related to 📌 An existing .well-known directory (as for Let's Encrypt) can prevent ActivityPub module's webfinger from working Active in that documentation would help to clarify that web server configuration may be necessary to allow Drupal to handle ".well-known/webfinger" both at the root and potentially in a sub-directory. Probably out-of-scope for this issue?

Okay, my hypothesis is correct. Something to do with path-based negotiation.

Is the test still valid using query parameter negotiation?

The non-localized test still passes and the empty query array is the same URL assertion as previously.

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

mradcliffe → created an issue.

Passes tests.

mradcliffe → created an issue.

Adding credits and closing. Next scheduled meeting is 12 February 2025 20:00 UTC - 📌 Mentor Meeting - 12 February 2025 Active

mradcliffe → created an issue.

I added documentation about conflicting modules and paths to add those paths to visibility settings.

Added documentation about conflicting modules.

Closing as outdated. I'm sorry that this was never completely implemented in agreement 7.x-2.x. It is functional in later releases.

Changing this to Active and to a supported version.

Need to reevaluate the feature request before making any further progress.

Closing as outdated. There was a question about Multilingual capabilities that could be a follow-up for a supported version of agreement.

Closing as outdated. I was never able to reproduce this issue.

The merge request 10896 (#45) seems to be 1770 commits behind the target branch and needs a rebase. It's currently failing tests.

The issue is a little hard to follow and I think next if someone could address the Needs issue summary update tag that would be helpful to clarify proposed resolutions and remaining tasks.

teknorah → credited mradcliffe → .

This was merged in a while ago.

I'm sorry I never got back to you on this, but I think this is working correctly since 8.x-1.x and greater.

I'm sorry I never got to this in the many years of Commerce Xero with Drupal 7 support.

I'm sorry I never got to this. Currently this got switched to using the order entity id in 8.x-1.x and 2.0.x.

I forgot to change the ice breaker.

Moved mentor sponsorship form up into Who's attending since it's related.

Added lead roles. I didn't add links to avoid Slack link spam.

- Mentor Contribution Event Planning lead → - Mentoring room lead - The helps to recruit mentor leads, but also providing guidance for mentors that leads into recruiting. The main point of contact. We've split this role in recent years.
- Mentoring room lead →
- Mentor communications lead → - Send email and social media updates, updates event web site content
- First-time contributor workshop lead →
- Mentoring booth lead → - helps with recruitment of mentors.
- Community tools lead → - ensures tools are ready, coordinates technical issues on-site, if on-site.
- Novice issue triage lead → -
- Major issue triage lead → - We haven't had enough to really do this, and this sort of bled into working with initiative leads

I am not able to reproduce this issue.

Where does $stub property come from? Is this in custom code?

Thank you for the merge request, @vinayakamk47. Changes look good so far. There a couple of things to still to do:

1. Update .gitlabci.yml to support testing on previous major
2. Update link_selection_handler.info.yml

mradcliffe → created an issue.

Added some more details from previous meeting.

Closing, the final unclosed/uncredited meeting from the last 13 months.

Closing, finally.

Closing, finally.

I mixed up the April 10th meeting 📌 Mentor Meeting - 10 April 2024 Active with this one, the 24th meeting. Swapping credits to avoid as much spam as possible.

Closing, finally.

Closing, finally.

Closing, finally.

Closing, finally.

Added issue credits. Closing.

mradcliffe → created an issue.

Tests are going to fail on Drupal 11 until domain module has a new release since the one included in the tests doesn't have 📌 Fix newly reported phpcs issues in latest pipeline Active yet.

I added drupal 10 (Previous major) testing.

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

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

Guess not. It was worth a shot :D

Do you want to try checking if localize will pass now?

I'm pretty sure that we don't need to drupalLogout anymore before the test in webfingerResponseHelper:96.

Would it also be better to get a fresh $page = $this->getSession()->getPage(); after each drupalGet call?

Also it would be a good idea to fix up the use of dynamic properties:

Deprecated: Creation of dynamic property Drupal\Tests\webfinger\Functional\WebfingerLocalizedTest::$adminUser is deprecated in /var/www/html/modules/webfinger/tests/src/Functional/WebfingerTestBase.php on line 40                                                                                                                                                                        
                                                                                                                                                                                              
Deprecated: Creation of dynamic property Drupal\Tests\webfinger\Functional\WebfingerLocalizedTest::$authenticatedUser is deprecated in /var/www/html/modules/webfinger/tests/src/Functional/WebfingerTestBase.php on line 41                                                                                                                                                                
F                                                                                                                                                                                             
Deprecated: Creation of dynamic property Drupal\Tests\webfinger\Functional\WebfingerLocalizedTest::$adminUser is deprecated in /var/www/html/modules/webfinger/tests/src/Functional/WebfingerTestBase.php on line 40                                                                                                                                                                        
                                                                                                                                                                                              
Deprecated: Creation of dynamic property Drupal\Tests\webfinger\Functional\WebfingerLocalizedTest::$authenticatedUser is deprecated in /var/www/html/modules/webfinger/tests/src/Functional/WebfingerTestBase.php on line 41

Deprecated: Creation of dynamic property Drupal\Tests\webfinger\Functional\WebfingerTest::$adminUser is deprecated in /var/www/html/modules/webfinger/tests/src/Functional/WebfingerTestBase.php on line 40

Deprecated: Creation of dynamic property Drupal\Tests\webfinger\Functional\WebfingerTest::$authenticatedUser is deprecated in /var/www/html/modules/webfinger/tests/src/Functional/WebfingerTestBase.php on line 41
F                                                                  2 / 2 (100%)
Deprecated: Creation of dynamic property Drupal\Tests\webfinger\Functional\WebfingerTest::$adminUser is deprecated in /var/www/html/modules/webfinger/tests/src/Functional/WebfingerTestBase.php on line 40

Deprecated: Creation of dynamic property Drupal\Tests\webfinger\Functional\WebfingerTest::$authenticatedUser is deprecated in /var/www/html/modules/webfinger/tests/src/Functional/WebfingerTestBase.php on line 41

If I can get away with not doing a Nightwatch test, then that would be ideal. Kernel test coverage of the ECA Event process?

mradcliffe → created an issue.