That is a seriously wonky plugin, my friend.

-----------------

##Prologue##

Before we actually start, trash this conditional - it does absolutely nothing:

    if($_REQUEST['s'] != '') {
    
    }
    
But really, more than likely, the original plugin developer had intended this conditional to actually do _something_ by bailing out of the function if `$_REQUEST['s']` is not set (seeings as this function will do very little in such a case):

    function getApplications( $_REQUEST ) {
        if( empty( $_REQUEST['s'] ) ) {
            return false;
        }

        global $wpdb;
        $sql = "SELECT * FROM employment_applications";

        ...

        return $applications;
    }

----------


##The Fatal Error##

First up: the fatal error. `$_REQUEST` in PHP is an automatically-populated super-global that PHP fills with HTTP request data. As such, it can be regarded as a [reserved word](http://us3.php.net/manual/en/reserved.php) (more specifically, a [Predefined Variable](http://php.net/manual/en/reserved.variables.php)). Specifying `$_REQUEST` as a parameter to the `getApplications()` function tells PHP to reference the first argument as `$_REQUEST` (i.e. reassign the variable `$_REQUEST` to the argument) - this cannot be done in PHP5 (Not sure of the specific version in which this changed, but it was possible in PHP4).

__If the `getApplications()` function is called _with_ arguments__, change the name of the parameter to maintain proper flow and avoid reassigning the `$_REQUEST` super-global:

    function getApplications( $request ) {
        if( empty( $request['s'] ) )
            return false;

        global $wpdb;
        $sql = "SELECT * FROM employment_applications";
        $sql .= " WHERE applicant_name LIKE '%" . $request['s']  . "%'";

        $applications = $wpdb->get_results( $sql );
        $wpdb->show_errors();
        $error = $wpdb->last_error;

        if($error != '') {
            echo '<div class="alert alert-error">' . $error . '</div>';
        }

        return $applications;
    }

__If the `getApplications()` function called _without_ arguments (_or_ is always called with `$_REQUEST` as the argument, i.e. `getApplications( $_REQUEST )`)__, remove the parameter entirely and make direct use of the `$_REQUEST` super-global:

    function getApplications() {
        if( empty( $_REQUEST['s'] ) )
            return false;

        global $wpdb;
        $sql = "SELECT * FROM employment_applications";
        $sql .= " WHERE applicant_name LIKE '%" . $_REQUEST['s']  . "%'";

        $applications = $wpdb->get_results( $sql );
        $wpdb->show_errors();
        $error = $wpdb->last_error;

        if($error != '') {
            echo '<div class="alert alert-error">' . $error . '</div>';
        }

        return $applications;
    }

More than likely, your solution will be the latter of the two.

----------


##Disabling Plugins Outside of the Dashboard##
There are many ways to go about this, but here are a few of the most common:

 - Alter the `active_plugins` option (permanent)
   - __Database:__
>Using PHPMyAdmin or raw SQL, within the `wp_options` table locate the row whose `option_name` field is `active_plugins` and modify it's
> `option_value` field. Note that [this is a serialized
> value](https://wordpress.stackexchange.com/questions/45109/how-to-make-sense-of-the-active-plugins-option-value-to-enable-and-disable-certa),
> so if you're not sure how to make the modifications to serialized data
> by hand you'll need to unserialize the value, make your modifications,
> and then reserialize it before placing it back into the field.
> Alternately, deleting the contents of `option_value` will disable all
> plugins (though their deactivation hooks may not fire, depending on
> the plugin's implementation).
> 
> Or you can make use of a [serialization-aware search and replace tool](https://interconnectit.com/products/search-and-replace-for-wordpress-databases/).

   - __PHP:__
> Make use of [the `deactivate_plugins()`
> function](https://codex.wordpress.org/Function_Reference/deactivate_plugins) or the [Options API](http://codex.wordpress.org/Options_API) in a [must-use plugin](http://codex.wordpress.org/Must_Use_Plugins). Must-use plugins
> are always regarded as "activated" and are loaded before all other
> plugins; this provides a convenient entry point to execute code even
> when the large portions of the site are inaccessible.

 - Invalidate `active_plugins` ("undoable")
> This is essentially the same trick as renaming the (root) plugins folder. In
> `active_plugins`, WordPress notes the location of each plugin's
> primary file relative to the plugin root ([the constant
> `WP_PLUGIN_DIR`](http://codex.wordpress.org/Editing_wp-config.php#Moving_plugin_folder)). By changing `WP_PLUGIN_DIR` you can force WordPress
> to loose track of the plugins and thus fail to load them, effectively
> processing the request as though no plugins are present and leaving
> the `active_plugins` option untouched in the database. In [wp-config.php](http://codex.wordpress.org/Editing_wp-config.php): `define( 'WP_PLUGIN_DIR', 'thisPathDoesNotExist' );`. Removing this line will revert the plugin path to it's default setting.

----------------------

##"A Better Way to Troubleshoot"##
Please refer to the Codex entry [Debugging in WordPress](http://codex.wordpress.org/Debugging_in_WordPress) for a primer into the debugging facilities provided by WordPress, as well as a short list of some great plugins that aid debugging. The very first step is _always_ to enable the `WP_DEBUG` constant in `wp-config.php` (though refrain from doing this in a production environment, if at all possible):

    define( 'WP_DEBUG', true );

If `WP_DEBUG` is `false` (as is default), WordPress suppresses the vast majority of warnings and errors.

I also highly recommend using [Xdebug](http://xdebug.org/) on your development machine for quick access to ridiculously useful stack traces, formatted `var_dump()`s, remote debugging, and pretty colors (among other things).

-----------------

##A Note Regarding Security##

Let's take a moment to inspect this line here:

    $sql .= " WHERE applicant_name LIKE '%" . $_REQUEST['s']  . "%'";

As `$_REQUEST` is filled with HTTP request data, what this line here is doing is taking the data-key `s` straight from the request and dropping it into an SQL query. __This is a major security hole and likely exposes your site to SQL injections__. _Anyone_ who has access to any part of the site that results in the `getApplications()` function executing can simply append `?s=whatever` to the URL to perform queries of their own design. The lack of proper escaping means that an attacker could even potentially use this query to access data outside of the `employment_applications` table.

If not abstracted and/or validated, all data supplied by users should be escaped, at the very least:

    $sql = "SELECT * FROM employment_applications";
    $sql .= " WHERE applicant_name LIKE '%" . esc_sql( like_escape( $_REQUEST['s'] ) ) . "%'";
    $applications = $wpdb->get_results( $sql );

or
    
    $querystring = "SELECT * FROM employment_applications WHERE applicant_name LIKE '%%%s%%'";
    $applications = $wpdb->get_results( $wpdb->prepare( $querystring, $_REQUEST['s'] ) );

You should give the Codex entries on [Data Validation](http://codex.wordpress.org/Data_Validation) and [Protecting Queries Against SQL Injection Attacks](http://codex.wordpress.org/Class_Reference/wpdb#Protect_Queries_Against_SQL_Injection_Attacks) a look-over for a brief intro to data security in WordPress.

------------------

##Epilogue##
All of the above considered, I feel your modified code should look similar to the following:

    function getApplications() {
        if( empty( $_REQUEST['s'] ) )
            return false;
    
        global $wpdb;
        $querystring = "SELECT * FROM employment_applications WHERE applicant_name LIKE '%%%s%%'";
        $applications = $wpdb->get_results( $wpdb->prepare( $querystring, $_REQUEST['s'] ) );
        $wpdb->show_errors();
        $error = $wpdb->last_error;

        if( ! empty( $error ) ) {
            echo '<div class="alert alert-error">' . $error . '</div>';
        }

        return $applications;
    }