I'm not really following this. Are you saying you want every page view to listen for if a POST form is submitted and handle it as per hooks? Why not just make a new entry-point script and direct a form to that directly, just like form_to_email.php does for relaying emails?

No that's not the intention; that would be overkill to run it every time there is POST data.

The intention is only certain things would utilize the hooks. For instance, submitting a catalogue entry would call handle_catalogue_entry. Registering a user account would call handle_registration. And editing your profile would call handle_profile_edit.

The idea is that, for example, if someone has third-party CRM software, data from key areas of Composr (catalogues, user registration, and profiles) can be relayed via these hooks to the software. This is not for custom forms (which do not go through the catalogues system).

It could also be used to call webhooks, save / sync data elsewhere, etc.

That makes much more sense. In which case, why not have a different set of hooks for each source (catalogue entries etc). Is there a reason it is being brought together in one set of hooks? Seems like an unnecessary forcing of disparate systems together.

There is no reason for keeping it together. In that case, they can be separated out as you suggested (and I agree it is probably better that way).

Automated response: Form handler support

This hotfix adds basic form handler support for joining and for editing profiles. Catalogue handling has not yet been implemented. By default, this does nothing; developers should write their own form handler hooks. Documentation will be provided later (and so will catalogue support).

Patrick, this can be marked done?

I'm going to mark it partial implementation. The original issue also specified catalogue form handlers, which has not yet been implemented.

Okay I was wrong; I already did implement form handlers for catalogue entries in v11. I'm not sure why I missed that.