[Resolved] CRED Form in a View loop returns Curren Post in Loop for container_id

[Author]

Posts

[smileBeda]

When using a CRED form in a View loop and hooking cred_save_data, which features a $form_data['container_id '], supposed to return the page or post ID which contains the form, the function in this case returns the current post in the View loop, instead of the container ID

I tried using get_queried_object_id(), which usually returns the current post or page, yet, in this case get_queried_object_id is not set at all (also checked in wp_query global).

As far I know get_queried_object_id() would be exactly for this purpose, to get the ID of stuff outside the loop, it should not be overwritten by the View loop.

Am I wrong? Or in other words, how do we get the container ID in a loop of View Posts (which have each an edit Form in that same loop)?

[smileBeda]

Replicated on a clean install

1. Create a View, query posts
2. Create a Post Edit Form select AJAX submit, keep show this form
3. Insert Form in View
4. Insert View in page
5. Submit form on page.

This is the content of the $form_data you will get on cred_save_data:

[27-May-2021 09:29:02 UTC] Array
(
    [id] => ID_OF_FORM
    [post_type] => post
    [form_type] => edit
    [container_id] => ID_OF_CURRENT_POST_IN_VIEW_LOOP
)

[container_id] => ID_OF_CURRENT_POST_IN_VIEW_LOOP is wrong, it should be [container_id] => ID_OF_POST_WHERE_FORM_IS_INSERTED_TO (or in other words, where the View is inserted to)

While I confirmed that this never seems have to been working, it is very worrying that this code

global $wp_query;
error_log( print_r( $wp_query, true) );

will return an empty

 [queried_object_id] => 

This happens on a clean site.
It is thus impossible to receive the "container" ID within a cred_save_data hook when that hook is firing inside a View loop?

That's a shame. Or I have to take a vacation (very possible).

The only thing I found to help me was accessing [HTTP_REFERER] from $_SERVER, but is this really what we are expected to do? I don't like this 🙂

[Waqar]

Hi Beda,

Thank you for contacting us and I'd be happy to assist.

I've received feedback from the concerned team that it is the expected behaviour that the "container_id" holds the ID of the immediate post item, that actually holds the form.

During testing on my website, I was able to get the current page's ID inside the function attached to the 'cred_save_data' hook, by following these steps:

1. I passed the current page's ID, in the view's shortcode like this:

[wpv-view name="test-view" cached="off" currentpage="[wpv-post-id]"]

2. In the edit form inside the view's loop, I added a hidden generic field 'hidden-field' and for its default value, used the 'wpv-attribute' shortcode to get the value passed through the view's shortcode:

[wpv-attribute name="currentpage"]

3. In my function attached to the 'cred_save_data' hook, I was able to get this hidden field's value through $_POST['hidden-field'].

I hope this helps.

regards,
Waqar

[smileBeda]

Hi Waqar, yes that is a nice hint!
I did already proceed on my use case using $_SERVER['HTTP_REFERER'], which works as well, however your solution has a certain style.

I will think about using that instead, and surely in future - at least when people don't use boring Elementor Widgets, that solution is totally viable.

Thanks!!