Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

I'm a Drupalista who occasionally works in WordPress so this might be obvious :) I was helping a colleague debug some AJAX behaviour, and having got the URL of the callback from Firebug, I wasn't sure how to translate that into a file and function server-side. Can someone enlighten?! TIA

share|improve this question
1  
Can you please tell us the link you're trying to debug? –  Brady Aug 4 '11 at 16:15
    
@Brady I'm looking for a general solution for working out the file and function from the URL (maybe WP just doesn't work that way). I know exactly how I'd do it in Drupal, and maybe that's leading me to assume things work similarly in WP. –  Andy Aug 4 '11 at 16:25
add comment

2 Answers

The problem is that many people do ajax their own way rather than using WordPress provided ajax.

If it's done the proper WordPress way, the js will call /wp-admin/admin-ajax.php via an ajaxurl var and pass an action, which will map to an add_action('wp_ajax_{$action}', 'some_function'); somewhere in the theme's functions.php or a plugin, which will call some_function when the action matches.

share|improve this answer
    
Thanks Milo, that's exactly what I was looking for! In my case the plugin wasn't calling that URL (you are saying that the JS itself calls that URL - it doesn't get rewritten or anything?) Also I've put a comment under Otto's answer and would appreciate your feedback there as well :) –  Andy Aug 5 '11 at 8:38
add comment

WP doesn't quite work that way. How WP does work is a long and involved discussion, but here's the short version.

(BTW, AJAX is a whole other thing entirely. There's a whole system in WP just for doing AJAX requests easily, and most people are doing-it-wrong. If your question is AJAX specific, none of the below may apply.)

The first thing to understand is the rewrite system. WordPress uses a class called WP_Rewrite which essentially implements rewrite rules similar to how you'd do it in an .htaccess file. It uses regular expressions to convert "pretty" URLs into query variables.

For example, http://example.com/author/otto would be converted into http://example.com/index.php?author_name=otto internally. Similarly, http://example.com/2011/08/04 would be converted into http://example.com/index.php?year=2011&monthnum=08&day=04.

There's a rather large set of these rules (50+) that are generated to handle these URL cases, and what these rules actually are depends heavily on your settings, what custom post types you're using, etc. Plus, themes and plugins and such can adjust them too.

Those query variables are standardized and named in the WP_Query system, which controls what is being queried for in the database. So that year/monthnum/day thing gets read and turned into $wp_query->year and $wp_query->monthnum and so on. This works based on a whitelist system, so the variables have to be defined beforehand by either the core code or plugins/themes adjusting them.

Anyway, the main WP_Query gets initialized and populated by the WP_Rewrite system. When the query runs, it determines what it's pulling from the database based on what variables are set. It sets a bunch of flags, such as is_author and is_archive and is_home and is_single and similar, to denote various types of things. In broad terms, these are used to define the Template Hierarchy.

After this is done, the template loader is called to determine what part of the theme to display. Using these is_* rules and a series of template determination functions, one of the theme's template files is chosen and then called upon to display the page. The template is expected to implement something called The Loop, which basically pulls the posts from the main $wp_query global and displays them properly, according to however it wants to do that.

So it's not really a matter of files and functions, it's a matter of procedures based on variable inputs. All calls to WordPress basically take the same sequence of events:

  1. The URL is parsed into query variables.
  2. The main Query is executed based on those variables.
  3. The template hierarchy determines what theme file to use.
  4. The theme file displays the page.

Generally, if you want to change things on existing pages, you either change the proper file in the theme (or make a new one based on the Theme Hierarchy), or you create a new "type" of thing (such as a Custom Post Type) which can automatically adjust both the query variables and rewrite rules appropriately, or if you're doing something totally custom then you do-it-yourself and modify the rewrite rules directly.

The point being that in order to modify things in the easiest way, you have to really stop thinking about connecting URLs to functions, but instead start thinking about "what type of things am I using, and what do I want them to actually do and how do I want them to live inside the system?"

More specific questions will get you more specific answers. :)

share|improve this answer
    
Thanks so much for such a comprehensive answer! So taking Milo's and your answer together, when doing a normal page request I should think in terms of what's being displayed and The Loop; when dealing with an AJAX call (that's done properly) I can check which functions are bound to the relevant action. Does that sound about right? –  Andy Aug 5 '11 at 8:36
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.