Open git-temak opened 2 months ago
With the above solution, one thing to note to users is that if a form that was registered programmatically is no longer needed and the code has been removed from the plugin/theme where it was registered, the corresponding form post needs to be deleted from the site manually.
Hi @git-temak
Thanks for the suggestion here. The ability to register forms programmatically is designed specifically to allow devs to have forms that are not in the database. If we were to change this to suddenly create post objects, I'm sure I would cause a lot of problems for existing users who are avoiding have forms in the DB.
The other issue that would arise out of this is that on every single request to WordPress, that post object would be either updated or created. The af/register_forms
action hook runs on acf/init
which runs on WordPress' core init
hook.
What is the ultimate goal here? In my mind, if you want a form to be in the database, you just create it via the UI and it's there. If you don't want the form to be in the database, you can register it using PHP. It sounds like you are in need of a way to create forms for the UI using PHP. Is that correct? If so, I'm keen to understand why.
Cheers, Phil
Hi @mishterk
I see what you mean, I guess this is more case-specific. In this case, im using the forms on a portal where there are managers (company staff) that set up different parts of the platform and they can sort of pick from a range of options. One of these options is an ACF relationship field on the backend of the site and it assigns a form to a post. In the ACF relationship field, a WP Query is used to retrieve all the forms from the posttype of 'af_form'. This is the default ACF behaviour and there is a hook to adjust the args passed to the query https://www.advancedcustomfields.com/resources/acf-fields-relationship-query/ but ACF still uses the WP query to display the list of forms.
Due to how AF is registered programmatically, these forms dont show up since they dont have an attached form post so aren't saved as forms to the DB.
In this use case, i'm taking advantage of the programmatic approach to set up fields and forms for easier management, while leaving the managers to handle how and where the forms are being used. Maybe some sort of extension might be a way around this sort of use case so users can choose if programmatic forms should be saved and visible in WP queries or should simply remain fully code-managed as it currently is.
Love all the work with the plugin!
@git-temak,
I have some thoughts on how you could work around this.
I would have a look to see if there is another filter that allows you to modify the results of the WP_Query executed by the ACF field. If you can filter the results before they are returned to the browser, you could basically get a list of registered forms, create mock WP_Post objects using information from those forms, and then append them to the results set. If ACF doesn't provide a filter to modify the returned post results, you could of course filter the WP_Query directly, but you'll probably want to use the query args filter to set a flag to identify the query object as a means of isolating callbacks on core filters. I usually use something like 'pk_query_id' => 'my_something_query'
and then check for that in my hooked query callbacks.
Perhaps a better/simpler alternative could be to use something like a simple select field and dynamically control the available values in that select field using ACF's filters. This is something I've done quite a bit over the years and it work well.
Hi @mishterk thanks for the suggestions and the helping looking into this!
Appreciate all your work!
When a form is registered programmatically, just the form is created and a form post (very important in WP use) is not created. The form post attached to each form allows the form to be used across WP in various locations, such as ACF relationship fields that use 'af_form'. The form post saves the forms to the db and allows the form to be retrieved in WP queries. This extends the usage of forms created programmatically and is very handy for scalability.
This also means programmatically registered forms don't need to be added to the array of valid forms manually
A working solution to extend the
af_register_form()
function can be found below: