🇮🇳India @omkar.podey

Right now \Drupal\FunctionalTests\Core\Recipe\StandardRecipeInstallTest::testStandard is failing and I think it is because of the changes in core/modules/system/config/schema/system.schema.yml as we have a empty profile in the test and stark theme isn't installed.

So what should we do here ?, just install stark at the start (which seems difficult without the container) and i was wondering would we encounter a similar problem while using recipes on a real site using the empty profile.

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

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

I would like to get it reviewed first and then we can decide if we need the 11.x branch explicitly.

omkar.podey → created an issue.

omkar.podey → changed the visibility of the branch 3436632-add-validation-constraints to hidden.

Okay so I switched to 10.3.x. and right now the only test that's failing is Drupal\Tests\user\Kernel\UserAdminSettingsFormTest::testConfigForm

To fix this there were two options, either add config target data to core/modules/user/src/AccountSettingsForm.php or mark the keys that are failing the test as requiredKey: false in user.schema.yml.

So I thought that the requiredKey false would be the solution but then I ran into the langcode issue again where the langcode isn't defined in user.schema.yml so I can't mark it requiredKey: false.

thoughts ?

alexpott → credited omkar.podey → .

omkar.podey → changed the visibility of the branch 3436164-add-validation-constraints to hidden.

omkar.podey → created an issue.

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

I simplified the whole code block by removing the creation of new field storage config and hence moving away from the whole translatable key issue.

The migration tests and UserMailNotifyTest isn't happy with making all the keys required because of marking user.settings as fullyValidatable .I could add keys to UserMailNotifyTest and remove the requiredkey: false from most of them, doing that next.

While that might be true that the langcode shouldn't be added. I think it's a problem for another day, without the langcode being set now this won't pass tests and not be committed at all should we really block this on that?

yep it is ready to be tested

It is related but i think this landing independently shouldn't be a problem

omkar.podey → created an issue.

followup 📌 Either Remove default_summary_length config in text.settings or reuse it. Active

omkar.podey → created an issue.

omkar.podey → created an issue.

cancel_method has to be nullable according to testConfigForm

1. register key could have 3 values according to \Drupal\user\UserInterface
2. cancel_method can have any function assigned to it but i think it can't be empty.
3. password_reset_timeout It is never being set just being read so I think it should just not be null.

omkar.podey → created an issue.

Since there is no defined upper limit it makes sense to just add a lower limit for the default value and that it's not null I think.

omkar.podey → created an issue.

Right now in the 11.x branch following the default_content module's convention which is to place the .yml file in the entity_type folder under the recipes folder works. You can try that by running php core/scripts/drupal recipe core/tests/fixtures/recipes/only_content.

1. Needs cleaning next as multiple classes are added which could be combined.
2. Needs implementation for handling media files.

@bnjmnm could you approve that the aria-label in div looks good.

Even if we strip off all the normalise stuff we still need the denormalise for yaml content files right ?, this means a new class for denormalise as it's a lot of code .

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

The latest changes look good, @alexpott if you can approve this too that would be great.

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

Just to clarify this ✨ Use modals in field creation and field edit flow Needs work isn't going to go in at all the issue had a lot changes at once and hence it was split up into smaller pieces that could go in independently.

There are still unresolved threads.

Updated for login show password.

I guess the show password isn't that important on the login page so just removed it with the strength indicator.

Split into controller and form. So we have no forms without form elements.

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

Set to needs work for writing a better test.

omkar.podey → changed the visibility of the branch 2663316-broken-title-in to active.

omkar.podey → changed the visibility of the branch 2663316-broken-title-in to hidden.

Updated descriptions, more suggestions ?

Does this seem better and attracts enough attention to the note?

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

I am trying to get them in quick succession instead the modals issue is mostly sorted out 📌 Move the first two steps of field creation into a modal. Needs work .

It still dictates the links and the content inside, is it still an accessibility issue ? Uploaded a sample video voiceover_field_selection.mov

Okay so it does not make much sense to get this in and not the modals , @benjifisher what do you think?, can we merge 📌 Move the first two steps of field creation into a modal. Needs work ((which was rebased on top of this issue hence might seem like a lot of changes but it's not)), here it won't be too much to review or too many changes in one MR and it seems to be the fastest and the most efficient way forward.