[buddypress-trac] [BuddyPress] #2599: bp_core_add_ajax_url_js() generating wrong ajaxurl value

buddypress-trac at lists.automattic.com buddypress-trac at lists.automattic.com
Fri Dec 17 06:28:26 UTC 2010


#2599: bp_core_add_ajax_url_js() generating wrong ajaxurl value
----------------------+-------------------------------
  Reporter:  Kawauso  |      Owner:
      Type:  defect   |     Status:  new
  Priority:  normal   |  Milestone:  1.3
 Component:  Core     |    Version:
Resolution:           |   Keywords:  reporter-feedback
----------------------+-------------------------------

Comment (by vtowel):

 We are using BP on our site, and I find it annoying that the BP code
 causes WP's AJAX functionality to behave differently than is documented in
 the [http://codex.wordpress.org/AJAX_in_Plugins#Ajax_on_the_Viewer-
 Facing_Side WordPress Codex article AJAX in Plugins].

 WP plugin developers reading this Codex document - such as myself - will
 ''probably'' expect the global JS variable {{{ajaxurl}}}, if defined, to
 point to {{{admin-ajax.php}}}. I however didn't notice that the variable
 definition was different from the Codex's version (thanks to BP being
 installed), and as a result the hooks that I've written my plugin around
 (thinking {{{admin-ajax.php}}} has been run) are not fired. In particular,
 "admin_init" is not fired. I'm still investigating to find out which
 initialization hook I can use so that my plugin will work in '''any''' WP
 installation, whether BP has appropriated the {{{ajaxurl}}} global or not.

 So while option (2) will probably break existing themes, I do think it's
 the most logical option. I think it's good design to prefix all globals,
 whether in PHP or in JS, with a prefix unique to any given software module
 to avoid name collisions. It only makes sense to me that BP should, too.

-- 
Ticket URL: <http://trac.buddypress.org/ticket/2599#comment:6>
BuddyPress <http://buddypress.org/>
BuddyPress


More information about the buddypress-trac mailing list