#Configuration schema

Adjusted it to actually do what was asked for.

Did revert the deprecation message for the path property. Would like to know if we need to make the change here, or if we should defer that. Seems like that has been here for quite a while. I do think we might be able to ignore it here, since it doesnt seem to be used.

Waiting for build, since i had some cs issues ;x

So, the path config key was deprecated in Drupal 8.8 it seems ( https://www.drupal.org/node/3039255 → ). That kinda feels out of scope of this change, the fact is that it will need to go through deprecation? I don't even really see any usage in core, but that could be my search skills failing me.

But i don't feel we should do that here. Hopefully you agree.

If we changing the 10.3 database dumps because of invalid schema this points to us needing an update function. I think we should not be changing the dumps.

Also I think we should be adding a new constraint that works like callback but uses the class resolver service to my more flexible.

Actually I think this can go back to rtbc

ExtentionAvailable makes a lot of sense to me.

Back to rtbc now that it is moved.

Fixed the phpstan issue.

Also;

1st comment is Wim telling what this brings us, which is not an issue to resolve.

@quietone did leave feedback, but later wanted to commit so feel like she didnt feal to strong about it. Keeping is open to get extra attention from the committer here.

ModuleHandler already uses exists to check for installed. So the naming is kinda consistend.

If we need to seperate why now;

ExtentionAvailable, which would be consistent with things like; 'update available' or perhaps 'moduel available to install'. Doesn't feel that weird to me.

Appears to have a pipeline issue. Would you say the 2 threads are good to resolve? If they are and you can't I can do it for you.

Updated the class namespace as suggested, did do a rebase to clean up.

Did a codestyle fix and a rebase, since it was behind so much. That will create issues with lint jobs.

Think your last comment does seem reasonable, guessing we could work with that.

Seems blocked on 🐛 views.settings config object should not be used to cache list of available plugins Active since that one is the one still open, the blocked listed earlier was closed as duplicate of 🐛 views.settings config object should not be used to cache list of available plugins Active

Rebased and updated one deprecation message to 11.2.0 since we moved past 11.1.0

Rebased thsi issue.

@alexpott

> I think this issue points to us needing a new constraint which is something like NotBlankAfterInstall - so a very can be blank during site install but once the site is up and running it can not be. This is true for uuid, name and email.

You say this, which is kinda the same problem as 📌 Add validation constraints to contact.form.* Needs work comment #32. There it is a recipe which wants to use mail to replace a value, which is doesn't get since mail is not yet in config when installing from a recipe with the drupal command.

So there is also some sort of 'during install' issue, where during an install is appearantly possible to have invalid config.

Perhaps we even need to fix it ealier? Although i don't really feal like ignoring validation for config while installing is a good idea. Since it is pretty valuable, what if you are to install some sort of Drupal implementation (like a decoupled Drupal) and it comes with invalid config, would we want to ignore that?

Somewhat related: 📌 Add validation constraints to system.site Needs work

I reviewed the CR. It has all the information needed.

Added to the top of my list for tomorrow!

Ok, added a cr

Right but maybe we should.

Just to announce the new validation type that contrib modules can now use.

Title updated.

I looked at other issues regarding validation, and when there is no change in the interface (like '' becoming NULL) it seems it is not needed to have a CR as far as i can see.

Added CR

Yeah cr, is, and title updtae. Since this basically is the implementation of this constraint.

This should probably have a CR right?

Still failting on the standard install. Which has pretty much the. same problem, but unfortunately, does not configure system.site.mail at all.
In the test:

    // Standard expects to set the contact form's recipient email to the
    // system's email address, but our feedback_contact_form recipe hard-codes
    // it to another value.
    // @todo This can be removed after https://drupal.org/i/3303126, which
    //   should make it possible for a recipe to reuse an already-set config
    //   value.
    ContactForm::load('feedback')?->setRecipients(['simpletest@example.com'])
      ->save();

Which i alerady opened an issue for earlier. 📌 #3303126 was fixed, but a todo was not removed. Active . So guessing this might need to use another angle. Not sure what.

Updated the comments. :)

Some discussion on the issue with recipes here: https://drupal.slack.com/archives/C2THUBAVA/p1743182816947909

In order to load default values for recipes when quickstart is used we need to make sure default values that use config are actually found. We do this using a lookup array for the config path to $install_state.

Unfortunately the default email address for an install needed changing also since drupal@localhost is not a valid email address. I changes this to @drupal.local

I have some small documentation remarks, but this looks great.

Some more digging into the feedback form recipe.

It seems the actions are applied, BUT InputConfigurator::collectAll is never called, so while installing it seems like it doesn't really collect anything from config, so the placeholder ${recipient} is never replaced, therefor we get install errors.

FOund when debuging the failing test, stepping through RecipeRunner and seeing the $config_action_manager->applyAction($action_id, $config_name, static::replaceInputValues($data, $replace)); didnt really have any input values.

So basically this part of therecipe:

input:
  recipient:
    data_type: email
    description: 'The email address that should receive submissions from the feedback form.'
    constraints:
      NotBlank: []
    prompt:
      method: ask
      arguments:
        question: 'What email address should receive website feedback?'
    form:
      '#type': email
      '#title': 'Feedback form email address'
    default:
      source: config
      config: ['system.site', 'mail']

Is never looking up the default value, therefor we enter a invalid value when the config is installed.

Opened 📌 #3303126 was fixed, but a todo was not removed. Active since that should fix one of the tests. The references issue in the failing test tells us it was fixed and some code could be remove.d.

Thinking about this i think you are right. Doesn't seem to make sense. Closing.

📌 move static collect*() methods from display entity classes to EntityDisplayRepository Active would make this much easier. Then we could swap the display objects not and need hook_entity_prepare_view and hook_entity_view_alter

+1 to this approach! I had forgotten this issue and proof of concept existed when I had a chat with @phenaproxima where we chatted over this idea. The outcome happened to be nearly the same as this issue, except I didn't consider the possibility of having the config entity implement EntityViewDisplayInterface so we could swap it for the view display object.

I pushed a test and some wonky code to further explore. I like that it mimics how page regions work. If something exists we execute a new code path versus embedding into the existing code path.