Bulk duplicating post_meta only inserts meta of first post in loop correctly into Database (WordPress with CRED)

I am using the CRED plugin’s API to perform certain actions upon submitting a certain CRED form.

It’s basically not important but the issue is related to how the CRED plugin reads the Data after the Form is submitted.

When I submit a CRED Form, I duplicate the post which is currently Edited by CRED, and also all it’s child Posts.

Those Child Posts have certain Custom Fields attached to them
(Checkboxes, WYSIWYG and Radio Boxes)

Each of above Custom Fields is (for each child post) displaying conditionally, the condition is determined whether another Custom Field (Radio) has value 1,2 or 3.
So, if Radio has value 2, the checkboxes Field will display.
If Radio has value 3, WYSIWYG displays, etc.

I insert the new Child Posts via a wpdb query, which first gets all meta data from the “original” child posts (which I am duplicating) and then inserts the same meta data as the “original” posts have into the new ones.

This works fantastic, and the values of the Custom Fields are correctly set when looking at the new (duplicated) posts in the WP Backend.

But in the Database they are not saved correctly, namely I need to re-save (by hitting “update” button in WP Bacjend for each new post), in order to have the correct conditional values in the Database.

It is confusing to me, how I can see the correct set values of my Custom Fields in the WP Backend, but not in the Database.
Due to this problem, the Plugin CRED will not show the new Custom Fields when editing the New Inserted posts, until I re-save them manually.

This is the wp-db query that gets the meta and inserts (duplicates) it too the new (duplicated) posts:

//get the meta of the "original" post which I am duplicating
//$single_question_id is the ID of those "original" posts, which I get by a get_post() array
$post_meta_infos = $wpdb->get_results("SELECT meta_key, meta_value FROM $wpdb->postmeta WHERE post_id=$single_question_id");
//If we there are some meta infos
                if (count($post_meta_infos)!=0) {
                    $sql_query = "INSERT INTO $wpdb->postmeta (post_id, meta_key, meta_value) ";
//get the values of the original meta
                    foreach ($post_meta_infos as $meta_info) {
                        $meta_key = $meta_info->meta_key;
                        $meta_value = addslashes($meta_info->meta_value);
//Insert the returned values in the new (duplicated), where $new_question_id is the ID of the previously inserted (duplicated) new post
                        $sql_query_sel[]= "SELECT $new_question_id, '$meta_key', '$meta_value'";
                    $sql_query.= implode(" UNION ALL ", $sql_query_sel);

Now, the data is (in the WP Backend) displaying correctly for ALL Posts
BUT only the FIRST post_meta which is inserted is correctly stored in the database.

ALL other post_meta is ONLY displaying in the WP Backend, but in the Database the values of the meta_key is not stored.

Once I re-save those posts, the value is correctly saved.

I assumed a simple wp_update_post would solve the problem (as it basically calls the same action as hitting the “update” post in WP Backend)

But it does not.

I tried also a different approach, with get_post_custom, but the problem is, the Custom Fields (checkboxes) are stored as serialized arrays in the DB and there fore, I would need to loop over each of my returned post_custom, get the checked values and duplicate it in a completely different way.

I would prefer to use above “bulk” duplicate of the post_meta, also, it is to mention that it works in the Backend, but somehow the data isn’t correctly saved in the DB

Does anyone know, why my above code correctly duplicates all post_meta but does only store in the DB the FIRST post_meta inserted?

It is very confusing to me, that I can SEE the data (checked checkboxes as example) for ALL posts in the Backend, but NOT in the Database!

I know that is not a trivial issue, and if needed, I can also provide the entire code.

Source: wpdb

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.