[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