🇺🇸United States @daggerhart

Ran into this while working on Radios in a table.

I looked into the form processing a little bit, and confirmed #12 🐛 Radios and checkboxes not rendered correctly when nested inside other render arrays Active . \Drupal\Core\Render\Element\Radios::processRadios was not being run on radios elements within a table.

My temp solution was "whatever it takes" to get the radios working and I ended up with this method:

/**
 * Takes a normal render array for a radios element and makes it work within
 * a rendered table element. This solves a core Drupal bug where Radios are
 * not rendered at all within a table.
 *
 * @link https://www.drupal.org/project/drupal/issues/3246825
 *
 * @param array $radios
 *   Normal radios render array.
 *
 * @return array
 *   Fixed render array with child Radio (singular) elements.
 */
public function fixNestedRadios(array &$form, array $render_parents, string $render_name, array $radios): array {
  // First item in the parents array is the "tree name".
  $tree_name = reset($render_parents);


  // This container contains a hidden field that registers the $tree_name with
  // the $form_state. This trick allows our custom-rendered radios to be found
  // in $form_state->getValue($tree_name);
  if ($tree_name && !isset($form[$tree_name])) {
    $form[$tree_name] = [
      '#type' => 'hidden',
    ];
  }

  // Build the <input> element names and ids we'll need.
  $parent_names = $render_parents;
  $parent_name = array_shift($parent_names);
  if ($parent_name && $parent_names) {
    $parent_name .= '[' . implode('][', $parent_names) . ']';
  }

  $child_name = $parent_name ?
    $parent_name . "[$render_name]" :
    $render_name;

  $radios['#id'] = $radios['#id'] ?? Html::getUniqueId($child_name);
  $radios['#title_display'] = $radios['#title_display'] ?? 'visible';
  $radios['#description_display'] = $radios['#description_display'] ?? 'visible';
  $radios['#default_value'] = $radios['#default_value'] ?? FALSE;
  $radios['#attributes'] = $radios['#attributes'] ?? [];
  $radios['#parents'] = $render_parents;

  // Render each of the radios options as a single radio element. Neither
  // $form nor $form_state are actually used in this process, just required.
  $form_state = new FormState();
  $radios = Element\Radios::processRadios($radios, $form_state, $form);

  foreach (Element::children($radios) as $index) {
    // Radios::processRadios() doesn't set the #value field for the child radio
    // elements, but later the Radio::preRenderRadio() method will expect it. We
    // can set these values from the $radios #default_value if needed.
    // - '#return_value' is the "value='123'" attribute for the form element.
    // - '#value' is the over-all value of the radios group of elements.
    $radios[$index]['#value'] = $radios[$index]['#value'] ?? $radios['#default_value'];

    // Some other part of the rendering process isn't working, and this field
    // rendered as an <input> ends up not having a "name" attribute.
    $radios[$index]['#name'] = $child_name;
  }

  return $radios;
}

Maybe these things I had to do to make it work can be a clue for someone more familiar with the how forms -> render arrays -> forms work.

Ran into this same problem today and the real issue is that the UI is terrible. There is a hidden "Custom menu link" section that appears once you check the top-level box. Then you have to go into that newly-visible section and check another box to make it actually translatable. This is true for all entity types.

Patch applies and looks good. Thanks!

daggerhart → created an issue.

Hi @rossb89,

Thanks for the help! Reviewed, tested, and merged: 3844975c.

Reviews, tested, and merged. af1a0b

Thanks for the help!

Thanks for the offer! Happy to have all the help I can get.

I've added you as a maintainer with VCS and release control. I'll spend some time in the near future on the module's page and any documentation I can add.

DamienMcKenna → credited daggerhart → .

I know it's not ideal for me to mark RTBC since I rolled the last patch, but I didn't really do that much so maybe it's okay. You decide.

This is working well w/ module 1.7.

My config:

  $settings['container_yamls'][] = 'modules/contrib/redis/example.failover.services.yml';
  $settings['cache']['default'] = 'cache.backend.redis';
  $settings['redis.failover'] = TRUE;
  $settings['redis.connection']['interface'] = 'Predis';
  $settings['redis.connection']['host'] = 'redis_primary';

Tested:

1. Visited the site and pages loaded fine.
   • No error messages in dblog.
   • No values in the `cache_render` db table.
2. Shutdown my redis server.
3. Visited the site and pages loaded fine.
   • (expected) Error messages in dblog says "Couldn't connect to redis, using failover" or similar.
   • (expected) Values were populated in the `cache_render` db table.

Reroll of #20 against 8.x-1.x branch. Only conflicts were in the README.

volkswagenchick → credited daggerhart → .

volkswagenchick → credited daggerhart → .

volkswagenchick → credited daggerhart → .

#20 patch works great for me against the module 1.5 and 1.6. The patch does not apply to 1.7 unfortunately.

My config looks like this:

  $settings['container_yamls'][] = 'modules/contrib/redis/example.failover.services.yml';
  $settings['cache']['default'] = 'cache.backend.redis';
  $settings['redis.failover'] = TRUE;
  $settings['redis.connection']['interface'] = 'Predis';
  $settings['redis.connection']['host'] = 'redis_primary';

I'll see if I can re-roll the patch, but may run out of time and have to stick w/ 1.6 for now.

volkswagenchick → credited daggerhart → .

volkswagenchick → credited daggerhart → .

volkswagenchick → credited daggerhart → .

volkswagenchick → credited daggerhart → .

volkswagenchick → credited daggerhart → .

volkswagenchick → credited daggerhart → .

volkswagenchick → credited daggerhart → .

volkswagenchick → credited daggerhart → .

volkswagenchick → credited daggerhart → .

volkswagenchick → credited daggerhart → .

volkswagenchick → credited daggerhart → .

volkswagenchick → credited daggerhart → .

volkswagenchick → credited daggerhart → .

volkswagenchick → credited daggerhart → .

volkswagenchick → credited daggerhart → .

Updating Asheville details

The Asheville NC camp information was ~ 6 years out of date.

Removing unused local properties. Better parameter description.

more grammar

Grammar and clarity

Fixed.

MR is merged.

And the developer guider → is updated with new enabledByDefault annotation property.

adding clarity in hook_preproces_hook example

Fixing silly mistakes in the example funding provider

Updateing examples with new enabledByDefault property per ✨ Annotation: Allow each FundingProvider to determine if it's enabled by default Fixed

daggerhart → created an issue.

Wording

Formatting

Moving page further down the guide (menu weight)

Moving this lower in the guide (menu weight)

Templating system documentation.

Fixed.

Removed from code. Struck-through on the main project page. Not found on any guide pages.

daggerhart → created an issue.

daggerhart → created an issue.

Fixed.

Resulting output:

daggerhart → created an issue.

Cleaned up some styling things that were bothering me.

Results for first stable release:

If someone would like to propose other styles, I'm wide open to it. Please open a new issue with your mockups / MR.

Fixed. Using the example I created, I updated the providers that were producing the wrong urls.

Made a testing github funding yaml page (https://github.com/daggerhart/funding) and updated all the urls in the table above.

daggerhart → created an issue.

daggerhart → created an issue.

Postponing for now. I suspect the style will be very similar across dorg sites and that once we solve this once in ✨ Styling support for Drupal.org Active .

Postponing for now. I suspect the style will be very similar across dorg sites and that once we solve this once in ✨ Styling support for Drupal.org Active .

Postponing for now. I suspect the style will be very similar across dorg sites and that once we solve this once in ✨ Styling support for Drupal.org Active .

Another really cool idea, but I see the use-case as being as or-more narrow than ✨ Funding command for Drush Postponed . If this module provides the functionality, then it will have to be installed by the site owner to get the results.

The chances of a site owner or dev installing this module just to see what funding links their site will produce seems very unlikely.

If the owner/dev is already looking for a way to support a project, it seems like a stretch to think they would install this module and hope the project they want to support will have links appear.

Again, this is a cool idea, but postponing for now because.

I was thinking of a feature like this when going through ✨ Scan Drupal Git repo for funding.yml Postponed: needs info . It's a neat idea for sure, but I think the audience for the message this module could provide is very narrow. The messages would only be seen by developers that have the Funding module enabled.

Also worth notice, some other package manager did something similar in the past few years. Don't recall if it was npm or composer, but there was backlash. Devs immediately wanted a way to turn off the additional noise being added to their screens and logs.

I'm going to postpone this for now for this module. I think if we as a community _really_ wanted to surface this funding information during drush runs, we'd want to do it in drush itself. Otherwise people are installing this module just to see drush messages that many of them will not want to see.

Postponing for now, mainly because I suspect the style will be very similar across dorg sites and that once we solve this once in ✨ Styling support for Drupal.org Active .

Once that issue is complete, if there is a request from the drupal association to provide separate styles on the issue queue within this module, we can pick this back up.

Postponing for now, mainly because I suspect the style will be very similar across dorg sites and that once we solve this once in ✨ Styling support for Drupal.org Active .

Once that issue is complete, if there is a request from the drupal association to provide separate styles on the issue queue within this module, we can pick this back up.

I think postponed is a more-correct status. I could be convinced with more info.

Thought about this a good bit, and I don't think it really makes sense.

I think the fundametal idea of a Funding Provider should be that you can literally give people money by using it.

A funding provider that doesn't land the visitor on a location where they can give money would just be a generaic styled link, and I believe out of scope for this project.

Been thinking about this a lot, and I don't think as-written the scope of this feature request fits into the Funding module. Mainly because it's a feature only drupal.org would ever need / want.

If I'm way off here, and the drupal association wants this feature to be a part of this module, I'd be happy to give it a shot. I'd definitely need some direction though. I doubt anyone wants this module to crawl gitlab.

Same as other issues, I'm not clear on the relationship between this module and the various initiatives or collectives. Happy to learn more about how all these things are tied together.

Re-categorizing as an "Initiative" for now.

Not really sure if this module's issue queue is the right place for this, but also unclear on the cross over between this module and various initiaitves/collectives.

Re-categorizing as "Initiative" for now.

Removing some of the general info about how the module works and its goals.

Updated the installation and configuration steps.  Removed mention of supported providers, since that is now on the module's main page.

This is a bit out of scope for the Funding module, but is a perfect thread for the Open Collective → modules. They are greatly inspired by @pwolanin's work on Open Collective Events Integration → module, and I'd love to collaborate more on getting OC events management into Drupal.

Moving this issue to Open Collective module's queue for now.

This is fixed in 📌 Funding: Upgrade to Drupal 9 Fixed .

With the merge of 📌 Funding: Upgrade to Drupal 9 Fixed , this is now outdated.

This is fixed with the merge of 📌 Funding: Upgrade to Drupal 9 Fixed

With the merge of 📌 Funding: Upgrade to Drupal 9 Fixed , this is fixed.

Merged and marking as Fixed.

After speaking with Tim, Fran, and Gus via Zoom call, we decided this was ready to merge.

Updated patch adds some styles to the funding-link implementations.

This is complete (ish) in the upgrade patch on 📌 Funding: Upgrade to Drupal 9 Fixed .

Currently the display is a select field that shows examples rather than a tooltip.

Examples are provided by each Funding Provider plugin:

• https://git.drupalcode.org/project/opencollective/-/blob/1.0.x/src/Plugi...
• https://git.drupalcode.org/project/opencollective/-/blob/1.0.x/src/Plugi...

Duplicate of 📌 Create a Settings Form Fixed

Screenshots for 2.x patch:

• Settings Page →
• Gallery →

This has been completed in the Open Collective module that is based on ✨ Funding: Implement Providers for D9 Fixed .

The responsibility for the advanced Open Collective widgets has been moved to the Open Collective module to prevent duplicating lots of templates and processing.

Providers: https://git.drupalcode.org/project/opencollective/-/tree/1.0.x/src/Plugi...

Each provider contains examples of its use.

This is complete in the patch on ✨ Funding: Implement Providers for D9 Fixed .

Settings page allows admins to disable and rearrange (control the rendering order) Funding Providers.

This has been completed in the patch on 📌 Funding: Upgrade to Drupal 9 Fixed .

FundingProvider plugin Implementation Details:

• Annotation: https://github.com/daggerhart/funding/blob/2.x/src/Annotation/FundingPro...
• Interface: https://github.com/daggerhart/funding/blob/2.x/src/Plugin/Funding/Fundin...
• Plugin Manager: https://github.com/daggerhart/funding/blob/2.x/src/Service/FundingProvid...
• Plugin Processor: https://github.com/daggerhart/funding/blob/2.x/src/Service/FundingProvid...

This patch is a rebuild.

I don't know the GitLab MR workflow, so it's a patch. To easily browse the code, I have it in GitHub also for now (2.x branch): https://github.com/daggerhart/funding

Demo Site: https://dev-opencollective.pantheonsite.io/ (admin-light access available on request).

New features:

• Plugin Type: Funding Provider. Each funding provider is responsible for a namespace (specific key) in the funding yaml.
• 11 Funding Providers in effort to have parity with GitHub's funding.yml in the core of this module.
• Settings form allows admins to rearrange and disable Funding Providers.
• Gallery page where admins can see examples for all funding providers.
• Funding Examples are documented inline with the field.

Open Collective

The new Open Collective → module adds many more Funding providers for this new branch of the funding module: https://git.drupalcode.org/project/opencollective/-/tree/1.0.x/src/Plugin/Funding/Provider

• Badge
• Contributors Image
• Banner
• Button
• Contribution Flow
• (API) Members - requires an API-Key be set in the oc_graphql_client module settings

Each are as configurable as I could get make them (some of OC's documentation is incorrect).

MVP Remaining TODOs

1. I could not find any complete and working example of GitHub's, so I am not sure about all the URLs produced by the simple providers. Specifically, I need verified url patterns for the following: IssueHunt, KoFi, LfxMentorship, Liberapay, Otechie, Patreon, Tidelift
2. Styling. Almost every visitor facing output is unstyled (or very lightly styled). Need some specific styling goals for the OOTB styles implementation.
3. More documentation.
4. Automated tests.

volkswagenchick → credited daggerhart → .