145 reputation
116
bio website
location
age
visits member for 3 years, 2 months
seen May 16 at 16:33

Apr
23
comment save_post action to include wp_insert_post_data filter, gathering meta field info & prevent infinite loop
In this case I think it probably is, I've put the question to the plugin authors as well to see if they can comment. Normally accessing types CPTs and meta boxes work just fine within a loop, so it didn't occur to me that it might not be doing things as expected in this instance.
Apr
22
revised save_post action to include wp_insert_post_data filter, gathering meta field info & prevent infinite loop
correct link
Apr
22
revised save_post action to include wp_insert_post_data filter, gathering meta field info & prevent infinite loop
changed title to be more discriptive
Apr
22
answered save_post action to include wp_insert_post_data filter, gathering meta field info & prevent infinite loop
Apr
22
comment save_post action to include wp_insert_post_data filter, gathering meta field info & prevent infinite loop
I've upvoted your contribution, as it was helpful. Im not sure if it would work for others or not.
Apr
22
comment save_post action to include wp_insert_post_data filter, gathering meta field info & prevent infinite loop
I keep trying to access the meta values using updated_post_meta and I'm not getting anywhere. If I run a save on the post in question, I only get one result, and I get strange numbers for the values of meta_key, meta_id and object_id. The meta_value returns _edit_lock. I dont this this action is running late enough. It may have to do with the fields being added by the types plugin, though in other instances I've been able to access them through the key name, so Im not sure what the difference. I've returned to my original approach using wp_update_post.
Apr
21
comment save_post action to include wp_insert_post_data filter, gathering meta field info & prevent infinite loop
Erm, this produces a bunch of notices - first missing semicolon wp_update_post( $post, true )
Apr
21
revised save_post action to include wp_insert_post_data filter, gathering meta field info & prevent infinite loop
save post hook is taking only one parameter, though the hook incorrectly stated two.
Apr
21
comment save_post action to include wp_insert_post_data filter, gathering meta field info & prevent infinite loop
I think you've missed my point. Im after the value of $show_time = types_render_field( "show-time", array("post_id"=>"$child_ID", "raw"=>"true") ); At the point of save_post, this value hasn't been set in the database, yet I want to add it to the post title. Take a read of wordpress.stackexchange.com/a/54713/13551. He's asking the same kind of question. Im just having trouble implementing it.
Apr
20
awarded  Excavator
Apr
20
revised save_post + insert_post = infinite loop
typo and code stylin
Apr
19
asked save_post action to include wp_insert_post_data filter, gathering meta field info & prevent infinite loop
Apr
19
suggested approved edit on save_post + insert_post = infinite loop
Apr
14
accepted Prevent wp_debug from polluting ajax within plugin
Apr
14
revised Prevent wp_debug from polluting ajax within plugin
added a new code block representing an intermediary solution
Apr
14
comment Prevent wp_debug from polluting ajax within plugin
$wpdb->esc_like($title) works, though the headers sent warning returns, and ob_buffer still has noting to delete. - squirlie problem this is. I'll workin your more robust suggestions and hopeful in that process I sort the issue.
Apr
14
comment Prevent wp_debug from polluting ajax within plugin
Well spotted! However, this leads to PHP Strict Standards: Non-static method wpdb::esc_like() should not be called statically in . . . . 8{
Apr
14
comment Prevent wp_debug from polluting ajax within plugin
given what Im seeing - I'm going to work in your second approach. I'd like this to be as robust as possible without making demands on the environment. I can see having to move hosts for example in a year, and I'd hate to overcomplicate this, in case its not me who does it. It will take a few days before I can get to this but will come back with comments. Many thanks again for sharing your approach - very helpful indeed.
Apr
14
comment Prevent wp_debug from polluting ajax within plugin
Also, regardless of the use or warnings related to ob_clean, I'm still seeing the notices make their way through to the response, so a check won't affect the results. This would seem evidence that ob_clean, isn't actually doing what the codex suggest. joson_encode however does just fine, when wp_debug is disabled. So this leads me to think that the notices are causing the issue, not the construction of json itself. a quandry - I will double check the json results to be sure.
Apr
14
comment Prevent wp_debug from polluting ajax within plugin
Thanks for the detailed write up! I will digest, but regarding the headers, I initially had them where you suggested, but received headers already sent warnings. I moved it up to the position until they disappeared.