🇦🇺Australia @2pha

Feed is serving promotional non drupal content.

I agree it should be clear it's a paid service.
It seems "miniorange" are using drupal docs pages as a promotional tool/lead generator aswell setting up quite a few pages :
https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →

Thanks for the workaround @jlbellido
Needed it on a site I am not able to make custom modules (a field formatter) for.

I could not reproduce this locally, but I did reproduce it on simplytest.me.
I think it has to do with the code that accesses the `$element['#element_validate']` value.
I have pushed a hopeful fix to the repo.
Please test it.

remove page_bottom and page_top which seem to no longer be in the defaults.

Latest content does not seem appropriate for planet drupal....
Specifically "Content that does not fit Planet Drupal" -> "General web development and programming posts that only mention Drupal in passing"
https://www.drupal.org/aggregator/sources/1881 →

#8 seems to work for me

Removing sorting didn't fix it for me

I think this page and all the associated child pages should at least point out that they relate to a paid service and that there are free alternatives.
These pages rank very high in google and I suspect many people will be getting to these pages thinking, rightly so, that they are going to read how to set up 2fa without having to resort to a paid service.
These pages are obviously about generating traffic to a paid service and if you ask me, are bordering on spam.

I hit this too...
I have...
A profile → with a required date field with no default value.
This profile is required to be filled on user creation (so shows on the "add user" page).
All is ok until I add a password policy → (which maybe forces a form rebuild?)
When adding a user and I tab away from the password field, ajax is fired and I get the "DateTime::createFromFormat(): Argument #2 ($datetime) must be of type string" error.
The $time variable used as the second parameter sent to createFromFormat is an array in this case.
If I set a value on the required date field before trying to set the password, I don't get the error and the $time variable is a string.

I have the same problem, but in my case, it is because of a profile which had a required date field in it, and this profile field needed to be filled out when creating a user.
If I selected a value for the date field before setting the password, it was fine. But if I tried settings the password when the date field did not yet have a value, I got the ajax error "TypeError: DateTime::createFromFormat(): Argument #2 ($datetime) must be of type string"

@markdorison basically, just to keep the upgrade_statue module happy when going from D9 to D10.

@markdorison I was referring to #17.
Merging but not adding a release tag should stop peple unexpectadly being updated.

There seems to be very little difference..
https://git.drupalcode.org/project/acl/-/compare/8.x-1.1...2.0.0-beta1?f...
You can always use mglaman/composer-drupal-lenient to install the older version, which I will be trying with my D10 upgrade.

Can this not be merged but wihtout a release so the dev can be installed easiliy via composer for a D9 -> D10 upgrade (which is my case) but people would not be updated unexpectadly?
Maybe I am missing something?

I stumbled here as I am trying to upgrade/migrate a D7 site I made many moons ago which has facebook connect as the only option to login.
It seems back in the day I wrote my own action for the D7 only fboauth module that would set the user email to {facebook_ID}@facebook.com if the email was not authorised.
Site has been running for over 10 years without a hitch... so just thought I would suggest it.

This works for me with date only fields.

@jackfoust I only moved the site to the latest D9 at this stage, I'll check back in here when I move the site to D10 in the near future.

the dev (8.x-2.x) version seems to have worked for me on a D8 to D9 upgrade.
Not sure why there is a specific 8.x-2.x-dev branch in the repo, but doing a composer require drupal/redirect_after_login:2.x-dev`does infact install (8.x-2.x)

This is also an issue in the 2.x branch when navigating to the config page the first time.

Update Bot has already added a patch with this change about a year ago.
https://www.drupal.org/project/restrict_role_login_by_ip/issues/3289377#... 📌 Automated Drupal 10 compatibility fixes Needs work

Patch #3 works.
Patch #6 adds nothing to #3, in fact it removes stuff, don't use.

How about we get this merge in yes?
https://git.drupalcode.org/project/restrict_role_login_by_ip/-/merge_req...

Any chance of getting this in and a new release...?

might need review...
4 latest posts don't seem to be about Drupal at all.

I can confirm this problem and it's workaround.

Add link to the module page. Hard to know what this documentation relates to without it.

Needs attention.
It seems every blog post on https://www.axelerant.com/blog is being pulled into Drupal Planet.

It seem like every blog post on the website is now in the feed with most posts having little specific relevance to Drupal.
https://www.drupal.org/aggregator/sources/1614 →

It seem like every blog post on the website is now in the feed with most posts having little specific relevance to Drupal.
https://www.drupal.org/aggregator/sources/1614 →

Most of the posts are not about Drupal.
Latest seem to be just promoting a download/signup to a newsletter.

Seems this feed has been removed before →

Feed still seems to be getting pulled in, still not about drupal.

@maxilein I have to agree that a screenshot is extremely helpful on module pages. I have often create issues on modules about it myself.

https://simplytest.me is helpful to quickly test modules before using them on your own site.

A problem I found when having a required attribute on each <input type="radio" is that screen readers would announce each individual radio button as required, which is confusing.
I was / am working on a government website which requires extreme usability. I am testing on 4 different devices with 4 different screen readers. The only option I could find that kept them all happy was to set a default value.
I think it is important that if these changes are going to happen, that it is tested with multiple screen readers and the outcomes are documented. This would probably just mean setting up a page somewhere with the proposed output and testing in JAWS / Talkback / Voiceover etc, then posting the results here.
By testing, I mean validating the html and the expected screen reader announcements.
I could do the testing if needed.

I thought I would chime in here again.
After trying to validate my page, I am being flagged for having aria-required set on radio buttons.
After searching around the interwebs, it seems that a radiobutton group that is required should have a default value.

Just an FYI for anyone else running into this issue...
You can override the preprocess of the radiobuttons with `MYTHEME_element_info_alter(array &$info)`.
This is the way I had to do it on a project (which required major accessibility) and it seems to work.
eg.

function MYTHEME_element_info_alter(array &$info) {
  $info['radios']['#pre_render'] = ['custom_prerender_radios'];
}

function custom_prerender_radios($element) {
  // Set the element's title attribute to show #title as a tooltip, if needed.
  // This first part is copied directly from CompositeFormElementTrait.php
  if (isset($element['#title']) && $element['#title_display'] == 'attribute') {
    $element['#attributes']['title'] = $element['#title'];
    if (!empty($element['#required'])) {

      // Append an indication that this field is required.
      $element['#attributes']['title'] .= ' (' . t('Required') . ')';
    }
  }
  if (isset($element['#title']) || isset($element['#description'])) {

    // @see #type 'fieldgroup'
    $element['#attributes']['id'] = $element['#id'] . '--wrapper';
    $element['#theme_wrappers'][] = 'fieldset';
    $element['#attributes']['class'][] = 'fieldgroup';
    $element['#attributes']['class'][] = 'form-composite';
    $element['#attributes']['class'][] = 'form-composite-radios';
  }

  // Move required to the actual radio buttons.
  if($element['#required']) {
    foreach($element['#options'] as $key => $value) {
      $element[$key]['#required'] = TRUE;
    }
    // Remove required from the fieldset.
    unset($element['#required']);
  }
  return $element;
}

It seems to me this issue should be garnering a lot more attention as no only is it bad for accessibility and screen readers, but it also produces invalid html (required on a fieldset).