What must I expect getting into, by "ajaxifying" my plugin?

  • Maybe some of you from the community could help me get past a dilemma I have over using AJAX in WP, which I have not done before.

    I am in the early stages of building a WP plugin for enabling a logged-in user of a WP site or blog to submit a short, simple form. For the sake of argument, values entered in the form will be the principal, the interest and monthly installment on the repayment of a bond.

    The idea here is to allow the user to inquire how long it will take (i.e. the number of installments) until the bond is paid off, depending on how big or small an installment she pays . This will be displayed as a response in a text area or box at the bottom of the form.

    Using this form she could then explore various scenarios by re-entering different installment amounts and re-submitting the form on each such change.

    If I were to build such a plugin in a simple, no-frills way, then each time the user will re-submit this form that will cause a re-load of the page or post in which it lives. Moreover, because of its small size, this plugged-in form will likely share room on a page or post with other content.

    So the conventional wisdom here would argue for me to add some Javascript and “ajaxify” my form, in order to reduce page reloading by refreshing the content of only the “number-of-remaining-installments” box with the result to be fetched by AJAX from the server. In theory this sounds good.

    But I have gathered from various sources that Admin-ajax.php can carry with it its own overheads. That being said and considering that the form with its supporting process will be relatively quite small / simple, would it not be over-kill for me to “ajaxify” my plugin?

    It is not as if there were dozens and dozens of different input values of the form which would need undergo repeated validations on a server to warrant the added complexity, that would come with Ajax in the mix.

    The counter view is of course, that if there were to be many different subscribers all using this plugin simultaneously, this could add significantly to the volume of traffic with the server.

    By the way, there would actually be more PHP work going on in the back-end than what I have indicated in my over-simplified example, which is why I would prefer avoid doing the calculation in the front-end with Javascript.

    As I am undecided due to my confusion over this issue of the trade-offs, I would really appreciate hearing your views and feedback on this.

Viewing 3 replies - 1 through 3 (of 3 total)
  • Moderator bcworkz

    (@bcworkz)

    The amount of code the server must load for a WP AJAX request is not a whole lot less than a normal full page request. The amount of data transmitted is likely much less. So while there is a certain amount of overhead involved in an WP AJAX request, the alternative of reloading a page is even worse.

    If whatever processing is required can be managed client side with javascript or jQuery, that is the best situation from a server load standpoint. The server is not involved at all after the initial page is output.

    The next best thing is to do a conventional AJAX request that does not involve WP at all. A custom PHP page could take the request, do whatever processing is needed, and send a response. This would involve a LOT less overhead than a WP AJAX request. The problem here is this PHP page cannot utilize any WP functions. If you cannot get around the need for WP functions, then you must make a WP AJAX request.

    The traffic volume seen by the server is certainly an issue with busy sites, but it’s more of a server and DB configuration issue than a WP issue. There are many very large, very busy sites that successfully run on WP. Of course they are not utilizing budget, shared hosting schemes, they are running their own dedicated servers. WP is quite scalable when properly utilized.

    Thread Starter tightorbit

    (@tightorbit)

    Hello bcworkz,

    Thank you for your valuable feedback.
    Regarding your comment: “A custom PHP page could take the request…“. What I was planning on doing is storing in my plugin’s directory a file called, say for example, processForm.php which would live there separately from the file of the plugin ‘handler‘ code that is invoked by the shortcode. That handler is where the form is generated for presenting to the user. The action field of the <form> line in that handler would be sending one to processForm.php upon submission of the form.
    As it happens for what I need done in that processForm.php, no WP functions are required.
    Let me confirm, though, that I understand you correctly. I assume that under my scenario processForm.php would still come within the framework of WP, thereby making me incur the WP overheads anyway, because of it being also on the WP server, right?
    By the way, supposing that I keep it all within WP without applying any AJAX, but have something like memcache or varnish going. Isn’t that supposed to help alleviate the demand on the server?

    Moderator bcworkz

    (@bcworkz)

    Of course some sort of caching scheme is going to help in many ways. It’ll certainly help when the form is served, but not when the form is submitted back if you’re bypassing the WP overhead. Ironically, caching is more help when WP overhead is involved, but I think bypassing WP is still the greater gain. Generally speaking though, it’s worth having an efficient installation without caching, then when you do add caching, the site will that much better.

    If process-form.php (WP PHP coders don’t like camelCase ?? ) is not included or required by plugin code, and is not dependent on WP functions, then no, there will be no WP overhead incurred when directly accessing that page, such as with the action attribute of <form>. However, when you are outputting the form with handler.php, use something like plugins_url() to determine the path to process-form.php because your plugin’s path from root can vary from one installation to another. Not just because of sub-folder installations, but because the entire /wp-content/ can be moved into another branch of the folder structure. Thus handler.php would be part of your plugin’s code base and incur the overhead of the WP environment.

    Just because a file resides in the WP server does not mean it incurs WP overhead. The WP environment is loaded anytime the WP root index.php is requested. All permalinks are rewritten to index.php, so basically everything WP related goes through index.php (there’s a different one for backend pages). index.php requires wp-blog-header.php, which requires even more files, including wp-settings.php, which loads the rest of the core code. The main plugin file of every activated plugin is also loaded, along with the theme’s functions.php.

    It’s up to plugins and themes to require or include any other files they need to be functional. If you do not require process-form.php, then it is not part of the WP code base, it’s on its own. When it receives the form submission, WP is not involved. If you did try to call a WP function, you will get a fatal function not defined error. You do have the entire PHP code base to call upon though, so it’s not like this code cannot do much!

    If you’re interested, an overview of what happens when WP loads is in Query Overview. The first link in the text leads to an even more detailed summary at humanshell.net.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘What must I expect getting into, by "ajaxifying" my plugin?’ is closed to new replies.