🇺🇸United States @laryn

Seems like a good idea to me. Here's an approach I used in the Backdrop version which would be easy to port back to Drupal 7 if desired:

https://github.com/backdrop-contrib/views_contextual_filter_query/commit...

The port was very quick and easy -- I'll probably make an initial release today.

https://github.com/backdrop-contrib/views_contextual_filter_query

laryn → created an issue.

Looks good to me, too.

I think I'm far enough for an initial release. Work will continue here: https://github.com/backdrop-contrib/linked_field

laryn → created an issue.

An accessibility review flagged this for me in the Backdrop version of this module as well, prompting me to find this issue in the Drupal queue. Here's the commit that fixed it for Backdrop:

https://github.com/backdrop-contrib/back_to_top/commit/fd2e03c2227fd2c02...

I went with the nav plus the aria-label for context on the nav (and we also have it on the button -- I'm told it's correct to have it in both places).

I've made an initial alpha release for Backdrop and will work from there. I've pulled over some of the improvements you've put into the D10 version -- thanks again for all your work on this! The invitation above is a standing invitation. ;)

https://github.com/backdrop-contrib/google_translator

laryn → created an issue.

I've made an initial alpha release with the noted adaptations:

- https://github.com/backdrop-contrib/composer_manager/releases

Work in progress here:
https://github.com/backdrop-contrib/composer_manager

laryn → created an issue.

Work is well underway here:
- https://github.com/backdrop-contrib/book_made_simple

Thanks to all involved in this issue over the years.
Merged in the actively-being-ported Backdrop version.

laryn → created an issue.

@jenlampton It was un-deprecated by @herbdool:
https://github.com/backdrop-contrib/date_repeat/commit/ad89379aa76cbc8f6...

Should `ConditionInterface` be `QueryConditionInterface`?

laryn → created an issue.

The work of porting is well underway -- and I've made an alpha release for testing.

https://github.com/backdrop-contrib/entityreference_view_widget

laryn → created an issue.

The work-in-progress is going on here:
- https://github.com/backdrop-contrib/fuzzysearch

laryn → created an issue.

I've recently pulled in all the latest commits to the Backdrop version and have functional tests all green. I came to say that I'm grateful to the team here for all the work over the years and I found this issue -- I'll mark it as fixed at this point.

Looks good to me.

I'm working on the Backdrop port of this module 💬 Backdrop CMS Port? Fixed and I don't get a fatal error but the patch looks right. I've tested it and am including it there -- thanks @mvc!

https://github.com/backdrop-contrib/seckit/commit/915f914a68dc75ccf1e21a...

I am working on the Backdrop port. I should have an official release this month.

If any of the maintainers for Drupal are interested in maintaining or co-maintaining for Backdrop, you're more than welcome. Just let me know -- and thanks for all the work on this module over the years!

https://github.com/backdrop-contrib/seckit

I've started work on this port and in the next few days I hopefully will release an initial alpha version to encourage testing and continued development:

- https://github.com/backdrop-contrib/cer

I'm working on something similar for the Stripe module for Backdrop CMS (which has incorporated this module's functionality into it). The direction I'm going is that if there is a zero/empty value for the payment amount, then it skips the credit card popup and just submits the webform normally. (This zero value could be provided by one option in a selection, the results of custom processing in the provided hook, etc. and makes an optional "pay what you can/want" functionality possible.)

I have a PR that is working in early testing on Backdrop. @joelstein, if you are interested I can probably submit a substantially similar patch here. Take a look and let me know if you think it's a good direction:

- https://github.com/backdrop-contrib/stripe/pull/30/files

I've made an initial release for Backdrop, marking complete.

I needed this module in a Backdrop project and as part of porting it, I've tested and confirmed this patch, which is included in the Backdrop release:

- https://github.com/backdrop-contrib/field_collection_feeds/commit/252d7a...

Thank you both!

I'd love to hear your thoughts after you spin up an experimental site.

Sorry to see you go and wish you the best.

The situation you describe strikes many of the same chords that led to the fork of Drupal known as Backdrop. I'm curious if you heard of (or explored) that option of staying in the wider Drupal family via Backdrop, as you were deciding which direction to go?

I'm looking at this in the Backdrop version, where a contributor has made the following comment:

> I don't agree with the fix there. It makes more sense to define property $tags, since it's integral to the functioning of the class.

There is a PR on the issue to do so in Backdrop, which could easily be ported here for Drupal 7 if you agree:
https://github.com/backdrop-contrib/search_api/issues/57

I made an adjustment.

I've added a MR here, and I'm attaching a screenshot to compare to the original.

laryn → created an issue.

Patch attached.

laryn → created an issue.

nicxvan → credited laryn → .

Work in progress here: https://github.com/backdrop-contrib/field_collection_feeds

laryn → created an issue.

The port to Backdrop is located here:

https://github.com/backdrop-contrib/views_fieldsets

laryn → created an issue.

Sorry, my editor "fixed" something and I didn't realize it made it into the first patch. Here's a clean version.

Here's a patch that doesn't immediately strip_tags on the result, only if it is not empty.

laryn → created an issue.

Agreed that the patch does what it should. I am working on the Backdrop version of this module and have merged the patch after testing there.

Thanks @gresko8! The patch looks good and applies cleanly.

@hargobind, are you able to do some testing on your sites?

Content Access is specifically mentioned in the security advisory for ACL 1.4: https://www.drupal.org/sa-contrib-2023-034 →

I maintain the Backdrop version and what I've done there is along the lines of what ACL has done in switching from using `serialize` to `json_encode` -- so it requires an update hook to convert any Content Access settings saved in the database from serialization to json_encoding, as well.

Here's the relevant commit: https://github.com/backdrop-contrib/content_access/commit/4a45c548414df6...

Would you consider expanding this issue and patch to include that sort of change for security hardening?

laryn → created an issue.

laryn → created an issue.

I've merged a fix for this into the Backdrop version, based on the work here. Thank you to whthat, Aaron Wolfe (awolfey), Tess Bakker, candelas, Thomas Slott (bigslott), and Esben von Buchwald (esbenvb)!

I made a few additional tweaks to the latest MR from whthat for more performance gains:

- Don't use `image_path_flush` but break out a piece of that function so we can target the specific image and a specific style in the path.
- Unset the styles that have no changes along the way so that `manualcrop_save_crop_data` is only called on the styles that need it.

You can see that commit here if interested:

- https://github.com/backdrop-contrib/manualcrop/commit/8d71b5ddf45b2ad1be...

> The main issue is that moving from v0.9 to 1.0 imgAreaSelect adds a pixel to the lower right corner in setSelection() which ultimately caused the initial selection of ManualCrop to be empty.

I am not using the Drupal 7 version anywhere so I can't fully test this patch, but I can confirm that when using v1.0.0-rc.1 of imgAreaSelect in the Backdrop version, this trick of subtracting the pixel from x2 and y2 does seem to be necessary to get the selection to show up on initial load. (Thanks @peximo!)

I took the patch from #11 and manually worked it into a PR for the Backdrop version of this module and can confirm that the basic logic works well.

laryn → created an issue.

I was running into this issue on a Backdrop site and have tested a slightly modified patch over there (only modified for Backdrop-specific details like config instead of variables, authmap function name change, etc.) and it seems to be working great.

I've duplicated this issue and filed the derivative PR here:
https://github.com/backdrop-contrib/simplesamlphp_auth/issues/24

One minor textual suggestion. @codebymikey on this line:

> Note that the option to allow the login and external accounts should only be used...

Should it rather be the following?

> Note that the option to allow the login and link accounts should only be used...

Here is where the work is happening: https://github.com/backdrop-contrib/duplicate_images

laryn → created an issue.

@candelas The Backdrop version has a stable release so if you upgrade your D7 site to Backdrop the module should continue to work. Or maybe I'm misunderstanding your question?

I installed Open Atrium locally and took a screenshot. It does seem like there's something awry here that we'll need to dig into.