Clicking the “Add New {$taxonomy}” button makes an ajax request, part of the data sent is:
{ action: "add-{$taxonomy}",
new{$taxonomy}: form-field-value }
On the server, this causes a do_action() call to the callback of the "wp_ajax_add-{$taxonomy}" action, which is _wp_ajax_add_hierarchical_term(). (source code)
You can see the comma is used to explode() the data string, with no way to filter the data. A possible solution is to hook the same action with a priority less than 10 so your callback is called first. Check and fix the contents of $_POST["new{$taxonomy}"].
Thread Starter
somtam
(@somtam)
Hello,
I’ve just tried, but probably there’s something I miss. This is:
add_action( 'wp_ajax_add-colors', 'som_divider_term', 1 );
function som_divider_term(){
$_POST['newtagcolors'] = 0;
$_POST["newcolors"] = 0;
}
In theory this code would prevent the insert of every new custom term. But it doesn’t work. I still can insert the custom term.
Moreover I tried both “newtag” and “new” to be sure to catch the right array.
And is there a way to debug and see what’s happen?… i mean some echo or print_r inside that function didn’t work.
thanks for helping!
The default action callback may be doing it’s thing before your action callback. You should add your action with a lower (<10 usually) priority number so you get 1st crack at the $_POST data.
It may just be a matter of coordinating the correct spelling of the various elements. You can see all the filter and action hooks (and their priority) by hooking ‘init’ and var_dumping the global $wp_filters.
Check the $_POST key by examining the admin screen HTML source and finding the fields name attribute. Better yet, use an HTTP traffic sniffer like HttpFox for Firefox.
Debugging within an AJAX call is difficult because the process is independent of a browser. You could set up a test page that calls the action callback directly, feeding it the data it would normally receive through the admin-ajax.php process. Then you can print_r or var_dump and see the results.
If you really need to capture values in situ, your only recourse is to use error_log() to write data to your error log file. Then open the file to see what was recorded. I’m not sure you can write huge var_dumps this way, but it works well for single values.
Thread Starter
somtam
(@somtam)
thanks to the firefox plugin I know that now the variable are not POST, but GET, see below:
admin-ajax.php?action=ajax-tag-search&tax=colors&q=sss
so I made a test where my purpose was to change the get $q value.
add_action( 'admin_init', 'som_divider_term' );
function som_divider_term(){
$_GET['q'] = 'hello';
}
This example didn’t work, and I can’t really understand why.
In fact the hook is exactly fired in admin-ajax, before the execution of the functions.
Moreover var_dumping the global $wp_filters in the INIT hook doesn’t work, because return an error of headers already send.
thanks for helping.
Thread Starter
somtam
(@somtam)
I found another important part of the problem.
The code that check the terms list is in
wp-admin > js > post.js
Only when the add term button is pressed all the data are sent by ajax.
the code of post.js about the term is from line 16
tagBox = {
clean : function(tags) {
var comma = postL10n.comma;
if ( ',' !== comma )
tags = tags.replace(new RegExp(comma, 'g'), ',');
tags = tags.replace(/\s*,\s*/g, ',').replace(/,+/g, ',').replace(/[,\s]+$/, '').replace(/^[,\s]+/, '');
if ( ',' !== comma )
tags = tags.replace(/,/g, comma);
return tags;
},
GET? Uh-oh! We may not be looking at the same add term form! The one I was checking definitely sends POST. It’s to add new terms to a custom taxonomy in the post edit screen. It’s the only one I know of that accepts a comma delimited list. What are you using?
I think the reason the ‘admin_init’ hook isn’t working is the hook fires a bunch of times for a single request, and only one of those will have the ‘q’ key, whatever that is. This results in errors most of the time. By first checking if the “new{$taxonomy}” key exists, I was able to alter the values passed on to the add hierarchical term function, resulting in different terms being added than those submitted, all from ‘admin_init’. It’s a viable approach if done correctly.
Not sure why you’re getting a headers sent error off of ‘init’, I dump vars all the time from there. var_dump() wouldn’t do anything to cause that error that I know of. At least on my system the $wp_filters contains hooks exactly as we expected on priority 10. If you have trouble verifying this, I think we’re OK assuming both systems are the same in this one respect.
I was aware that JS did some input checking before submitting the data, but I felt it was easier and cleaner to use a PHP hook after the data is submitted. Regardless of what JS does, the data has to be sent to the server for the terms to be saved in the DB, so the JS is not a parallel path, it is in series.
However, if you are having issues hooking with PHP and you know JS, you could simply hack the JS function to correct the data right at the browser and forget about PHP.
