Drupal 8 version

Please see issue #2794919.

Long story short, yes, I want to do this. I'm having trouble working through D8 APIs, though. I'm working on another, much simpler, module first. Once I get that to work, I'll start on this.

Oh. No. Wait. I got projects confused.

Actually, this is the "simpler" module I referred to in my previous comment.

So, yes, working on this. No success so far.

@hansfn - That seems like a really good idea.

(Yahoo seems to want to mark email from drupal as spam, so I don't always see it.)

So I pushed to a new 8.x-1.x branch. It's nonfunctional, but pieces work. I'll keep playing with it, but please take a look and see if you know what's wrong.

See the README.md.

hansfn thank you!

Though there was something else going on than just this. I'm pretty sure that was one of a bunch of different versions. I applied the patch, still no joy. I tried clearing caches, and uninstall/install. Still, no joy.

Then I realized that I had a mothermayi_backup version in the modules directory; A copy I'd made when I first got just a little bit working. That must have been confusing Drupal. When I removed the directory, things immediately got better.

OK, now to figure out how to hook into the user register form.

Progress. The settings form works, and mothermayi_form_user_register_form_alter() works, adding the required fields in the user registration form.

But, I can't figure out how to get module-specific validations to run on form submission. My attempts using the D7 approach cause Drupal to get stuck in a loop. (At least that's what appears to happen.)

Any pointers would be appreciated,

Oh, and while I'm thinking of it, drupalmoduleupgrader left a fair number of blocks around like this:

    // @FIXME
// Could not extract the default value because it is either indeterminate, or
// not scalar. You'll need to provide a default value in
// config/install/mothermayi.settings.yml and config/schema/mothermayi.schema.yml.
$hint = \Drupal::config('mothermayi.settings')->get('mothermayi_secret_hint');

This implies that default values can be specified in one of those two files. I don't see any examples. What's the textbook way of setting default "out of the box" settings for config variables?

Unfortunately, the only reason I'm able to spend time on this now is because I'm home, laid up by a nasty flu. That means I'm only operating on about 30% of brain capacity.

Shoot, and I just realized that I've been putting the wrong issue number in my commits.

True, I probably haven't committed the latest version. At least not the version that breaks.

But I think I figured out the problem with getting the validation function called. As small matter of a missing

use Drupal\Core\Form\FormStateInterface;

work on this a bit more, then will commit. I'll also check your patches.

Thanks for all of your hand-holding hansfn, you've been a big help.

I think this is sufficiently functional now to warrant an alpha release. There are a few cosmetic things to clean up, but I think this works.

One thing that's still unclear to me: How to provide initial, default values for settings. Can that be done in the settings or schema yaml? Or is that you'd do in module.install?

Now that this is working, I think I'll tackle datereminder. It's rather more complex, but now that I have some admittedly limited experience with D8 apis, that's sounding less daunting.

But not tonight.

Rats. There's still a problem with the settings menu. I get a fault in validate. Will deal with this tomorrow.

I think it boils down to one of my config settings actually being an array. (Value and html style.) Before, when the schema file was wrong, apparently Drupal allowed me to set just anything. But with an actual schema in place, it balks at storing an array when it expects a string.

So what's the textbook way of dealing with this?

Defining two separate settings? (ick)

Can you have "array" as a type in the schema?

Can you have something like:

mothermayi_secret_hint: {value: '', format: 'basic_html'}

in module.settings.yml

The validation patches all look good. I don't understand why you didn't see the form on user registration, though. Is it possible you didn't clear the cache?

The user registration form is cached. Which is a pain. I need to figure out how to deal with that, and have a separate open issue on that.

If you also use captcha on the user registration form, it handles disabling cache for that form. But Mother May I shouldn't depend on that.

I have another ticket open to deal with the caching, Hans, if you have any pointers on that, I'd appreciate it.

Default values are set by the values in config/install. The values are kept after uninstall which some times is annoying when developing

D7 had the concept of disabling a module (make it stop working, but keep everything around), and uninstalling it (clean out everything). Apparently D8 doesn't have that distinction, and "uninstall" is more like D7's "disable?"

Maybe the module.install should take care of cleaning out everything. That was the case in D7.

I actually cleared the cache, uninstalled the module, and cleared the cache and then enabled the module again. I don't understand how the settings form could display for you without the changes in my patch.

Very strange. It was working OK for me, though your fixes were for obvious bugs. Could it be that I have my PHP configuration set to be more forgiving of errors?

I just tested. I was wrong. uninstall clears the configuration. It might have been a problem in the early D8 releases.

Cool. One less thing to worry about.

Well, if it works for you and for me, it must be good. :)

I do want to see if there's a better way to handle that one settings field other than "array," but that's not critical. Then there's disabling cache for the registration form.

My attempt to replace the "array" with a mapping failed. Failure on install.

It was probably something I did wrong, but at this point, I'm going with "If it aint broke..."

Sorry, I must have missed comment 24. I just committed that patch. (Had to do some hand massaging due to intervening changes. It looks right, though.)

Oh, look. If I look in the log, I see the error. Now I don't see it. I guess I should check that more often. I'm more used to things blowing completely up.

Thing, is, I don't see that description on the form. How would see that?

And I'm running Drupal 8.2.5. I realize there's an 8.2.6 now, but didn't want to risk chaos by doing a core upgrade in the middle of module development.

And I'll checkout the strict error.

Looks like your patch addressed the strict error, too.

Regarding clearing the user register form cache, some interesting discussion here: https://www.drupal.org/node/2851803

Let me know anything more you have about the settings issue. Does the hang happen when you do the setting form, or later when you do a user registration.

From what I'm seeing, if you don't clear all caches after changing settings, things can certainly go wrong; the form doesn't get updated, but the verification and submission methods don't know that. This business with caches is turning into a bigger deal than I thought.

I may need to add a settings form option to clear all caches. I assume there's an api for that.

Happy news - I think I have fixed the form cache issue. (After you have confirmed you can update the forum post you linked to.) After applying the patch, you need to rebuild cache. After that the user registration form is rebuilt whenever any of the module settings are changed. I think the solution was quite nice, but I didn't find it documented anywhere ...

OK, I think this one seriously qualifies as black magic. And it apparently covers the page cache as well, assuming that's what I was seeing.

I sort of see what's going on, but there's no way in heck that I'd have figured that out on my own.

Yes, this causes the form to be updated whenever the settings change. Good progress. All that remains now is to force the rebuild the first time around. Do you thing it would be too egregious to force a cache clear on module install? Or maybe the first time the settings are saved? I could add an option to the settings form that defaults to "yes" the first time, and "no" subsequently.

I think the attached patch is a more correct config setup - switching from "array" to "mapping" (which is a documented type).

I agree, this is more correct. It's almost exactly what I tried earlier, but I had the settings.yml wrong, and wasn't up to dealing with it at the time.

I'll look at your there "PS's" now.

Sigh. Why is it never simple? The "obvious" solution sounded like I should call drupal_flush_all_caches() in mothermayi_install().

But that resulted in:

Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "router.route_provider.old". Did you mean one of these: "router.route_provider", "router.route_preloader"? in Drupal\Component\DependencyInjection\Container->get() (line 157 of /home/drupalpro/websites/d8.dev/core/lib/Drupal/Component/DependencyInjection/Container.php).

OK, think I got the cache thing licked. Added a setting variable, initialized to true, to trigger cache flush the first time settings are saved. Setting is set to zero, to disable future flushes.

About done with the flu, so back to my day job tomorrow, meaning much less time to devote to this. It's been a highly valuable exercise.

I'll call this "Needs review" for now, though it's been an active collaboration getting to this point. There should be a beta release available shortly.

So how do we get rid of the "it's not usable yet" on the project page?

You create a alpha or beta release and change the issue status for #2851027: [mothermayi] Mother May I to "Needs review" - ref https://www.drupal.org/project/contrib_tracker#statuses

More magic! I am constantly amazed at the scale of this whole project.