Live feed

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

I think this is done, will continue the goverment use case on https://www.drupal.org/project/ixp/issues/3507630 📌 IXP for Government Active

ramil g → created an issue.

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

Hi all, I don't use Commerce myself, and so testing this always proves to be a big hassle. This ticket is also marked for 8.x-1.x, which is two versions back. @dahousecat is your patch for 3.0.x? If so, please update the ticket. If someone can provide some steps to repeat and test the patch, I would appreciate it.

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

@camoa Please assign credits

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

@camo please assign credits

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

Reviewed and is working as expected

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

@camos Plese assign issue credits

pdureau → opened merge request !108

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

Thank you @shane-birley for reporting this issue and taking the time to provide clear reproduction steps. Your detailed report made it easy to identify and resolve the problem.

I've investigated the issue and created a patch that addresses the block configuration save problem. The attached patch resolves the issue where countdown block settings were not persisting after saving.

Could you please apply the attached patch and test it in your environment?

Applying a patch
Download the patch to your working directory. Apply the patch with the following command:
git apply -v [patchname.patch]

Here's how to test:

1. Apply the patch to the module
2. Clear your site's cache (drush cr)
3. Edit an existing countdown block or create a new one
4. Make some configuration changes
5. Save the block
6. Edit the block again to verify your changes were saved

Please let me know if this resolves the issue for you or if you encounter any other problems. Your feedback is valuable to ensure this fix works properly across different use cases.

Thank you again for your contribution to improving the Countdown module!

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

Downgrade to 1.11 resolved my issue for the time being. I'm still curious if something can be done to make sure these fields are turned on, rather than off.

OK, I've got a fix for this and will push to the issue branch shortly. There were a few things going on:

• Drupal core and H5P core libraries were getting added to the aggregation that didn't need to be there.
• Excluding the `h5p.content` library solved this, but errors were still appearing in the console.
• Turning off aggregation resolved those errors.
• I don't fully understand this, but think it's a good idea anyway because this seems to be what the h5p.js init code for iframes is expecting./li>
• ...further, I've seen cases where specific H5P libraries inspect this array (see: https://github.com/otacke/h5p-game-map/blob/f8631762f36d794823ee296d92b5...).

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

Lo he revisado y funciona correctamente

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

Yeah, the Remove checkboxes have display: none in the views_ui module and in Claro.

Claro then overrides that with .form-boolean. It's probably an accident because it's a generic selector. I haven't checked Gin.

I think there's a bigger issue of whether they should be visible at all, but I'm planning to give them a hidden label due to 📌 Test that all form elements have a title for accessibility Needs work (which will require a #title property).

alphex → created an issue.

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

Procedo a subir evidencia de la publicación y dar cierre al issue

dmundra → created an issue.

I'm experiencing a similar issue in D-10.4.8, and patch #9 doesn't seem to resolve the issue. I have both 'Media File Delete' and 'Media File Delete - Entity Usage' enabled. I'm not sure if this helps, but the problem may be more of a cache issue. At deletion, the file isn't deleted because it recognizes itself. After deleting the media item, I immediately check in Files and it still shows a usage. Then I clear cache and the usage becomes 0.

Tested this and it works as expected. The class defining the ActivityAnswer should implements the buildConfigurationForm of the \Drupal\Core\Plugin\PluginFormInterface interface.

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

MR 1 is committed, MR 2 is in progress, the add template dialog works but needs some loading spinners for the view modes request, and the form isn't quite what I'd expect if I choose a content type that already has a template assigned to the "full" view mode.

It should be jump-onable by folks in other timezones - it all works and the TypeScript is sorted out, but needs some refining. The dialog props were set up knowing it will evenually be opened by a bundle's contextual menus, too.

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

Thanks @joelpittet! This is a nice improvement. Merge train started!

A quote from the IXP:

"It's been an immersive experience that has not only solidified my technical skills but also instilled in me the confidence needed to navigate the professional realm of software development."

I think all the tests should pass now, re #7, I think we should merge this ASAP and then continue working on the rest of the tests

All of my redirects are now "off" after the update. I have to downgrade so that my existing redirects can work. All redirects appear to be "Off" in the new Enabled field. There are 1000s of redirects in place so I can't just manually turn them all off.

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

I've checked it in the recent version, on a clean Drupal installation, and everything looks good. Even an ordinary link with a URL doesn't lead to closing the drawer.

I had the same issue, the cause was a misconfigured set of variables.

bnjmnm → opened merge request !38

joelpittet → opened merge request !49

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

Merged.

dmundra → created an issue.

rraney → created an issue.

Saw that tests failed.

Regarding phpunit

If I’m reading this right, it failed at line #159 in FeedsExecutable.php, which is where I removed what I thought was an unnecessary if statement that checked if owner_id was set, as in my testing, I could not create a Feed type with this field empty, the default Anonymous user was always entered if I did not manually enter something. Presuming this is indeed the cause of the “Call to a member function getProcessor() on null” error. What am I missing here?

Regarding the next phpunit (next minor)

It looks like this also failed at line #159, so same issue.

Regarding the next phpunit (previous major)

It looks like this also failed at line #159, in addition to failing elsewhere.

Regarding the next phpunit (previous minor)

It looks like this also failed at line #159.

So it seems like adding back the if statement I removed would fix these things, but I would like some clarification as again, I could not create a Feed type with no value in the owner_id field. Want to make sure I’m looking in the right places…

Yeah.

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

Hi janc48 , thanks for reporting it.

Regarding the second-level menu in the drawer, I've checked it in the recent version, on a clean Drupal installation, and everything looks good. I don't have the issue you mentioned.

Also, the documentation has been updated recently :)

Thank you.

This happened to me and some people noticed redirects not working anymore. I investigated and found they had an "Enable" checkbox which was not selected. Is the "Enable" box new? That's a separate issue, but related to the update. Opening another issue if it's not already reported.

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

Thanks for your support and cleaning up legacy code.

dmundra → created an issue. See original summary → .

zengenuity → created an issue.

Testing on Testing engagememnt issue template 📌 Testing engagememnt issue template Active

Final proposal:

-- Review Engagement

Description:

This ticket tracks the review of IXP engagement [CASE NUMBER] for final approval and credit award processing. The engagement has entered "Final Review" state and requires verification that all program requirements have been met.

Engagement Details:

• Organization: [ORGANIZATION NAME]
• IXP Name: [IXP NAME]
• Start Date: [START DATE]
• End Date: [END DATE]
• Total Hours: [TOTAL HOURS]

Review checklist

• [ ] Progress Reports Complete - System shows sufficient bi-weekly progress reports based on engagement duration
• [ ] Final Reports Submitted - Both company and IXP final reports are complete and submitted
• [ ] Required Links Present:
  • [ ] One public blog post by the IXP documenting their experience
  • [ ] At least three contribution links showing the IXP's work on drupal.org
• [ ] Minimum Hours Met - Engagement provided minimum 160 paid hours of work
• [ ] Mentorship Requirements Fulfilled - Documentation confirms mentorship was provided at required ratio (1 hour per 10 hours worked)

Notes

[Space for reviewer to add any observations, concerns, or additional context]

Final Resolution

• [ ] APPROVED - All requirements met, ready for 250 contribution credits award
• [ ] NOT APPROVED - Requirements incomplete, engagement state changed to "Needs Information"

Required Actions

[List specific items that need to be addressed before resubmission]

-- Other

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

The status is Postponed because we are waiting for a reply.

Please post a comment after 14 days, if your offer has not been declined. It will show you are still interested in maintaining this project and it will serve as reminder an action is required for this offer.

This is the message I sent.

Hello Wilfrid,

I am contacting you because Dieter ( https://www.drupal.org/u/dieterholvoet → ) offered to become co-maintainer for Form Mode Control ( https://www.drupal.org/project/form_mode_control → ), a project you created for which you are project owner and maintainer.

May you post a comment on https://www.drupal.org/project/projectownership/issues/3542611 💬 Offering to co-maintain Form Mode Control Active about accepting or declining the offer? Please do not reply via email; we need a reply on the offer issue.
Without a comment posted on that issue in the next 14 days, Dieter will be probably made co-maintainer.

Project moderators will not remove the existing maintainers/co-maintainers; the project owner will not be replaced either. Maintainers cannot change the project owner; co-maintainers/maintainers can only be removed/added by people who have the permission to administer co-maintainers/maintainers.

As last note: This offer is about being co-maintainer, which is different from being a maintainer. A co-maintainer is a person who does not have all the drupal.org permissions on a project. Even though being co-maintainers could mean having just a single permission, we expect a co-maintainer to have the following permissions on the project: Write to VCS, Edit project, Maintain issues, Administer releases.
If there is any reason for not giving all those permissions, please explain that on https://www.drupal.org/project/projectownership/issues/3542611 💬 Offering to co-maintain Form Mode Control Active . We need this to know it was intentional and not a misunderstanding on what the offer required.

Best regards,
Alberto Paderno
-- Drupal.org project moderator
-- Drupal.org site moderator