Use wp-config.php constants in all files of plugin

Question

I have a wordress plugin.

It has 2 files

1.index.php (main file for plugin where we define plugin name,Description and all)

2.update_db_cron.php (This file i am using to update database using cron job daily at 12.00) I can use Database constants (which was defined in wp-config.php) in index.php , but can't use them in update_db_cron.php.

Should i include wp-config.php in second file or define the database constants in that file Or there is any other better solution

Answer 1

A Bigger Note on Database Access

You shouldn't be using the database constants. Instead you should be using the WPDB class, e.g.

global $wpdb;
$results = $wpdb->get_results( 'SELECT * FROM wp_options WHERE option_id = 1', OBJECT );

That still leaves you with the issue that you need to be inside a WP context though, but it simplifies database access and allows more caching opportunities and safety checks

Should I Include wp-config.php?

No, you should do neither of the things you suggested, and instead use a WP CLI command as intended. Don't bootstrap WordPress manually from a standalone file, it's a security headache not to mention other things

https://make.wordpress.org/cli/handbook/commands-cookbook/

updatedb_command.php

class UpdateDB_Command {
    public function __invoke( $args ) {
        // ... update db cron code goes here
        WP_CLI::success( 'All done!' );
    }
}
$instance = new UpdateDB_Command();
WP_CLI::add_command( 'updatedbcron', 'UpdateDB_Command' );

index.php

// only include the command if WP CLI is running
if ( defined( 'WP_CLI' ) && WP_CLI ) {
    require_once dirname( __FILE__ ) . '/updatedb_command.php';
}

Usage

In a cron job, run the command:

wp updatedbcron --path="path to WordPress install on your server"

But I'm On a Shared Host? I Don't Have Access to Real cron jobs or Shell Access

In this case it appears that your cron job is not a cron job at all, but something else being used as one. In which case, WordPress already has a mechanism for this named WP Cron, which approximates it.

You can schedule a cron job to fire an action/hook/event, then run code on that hook, for example:

if ( ! wp_next_scheduled( 'my_task_hook' ) ) {
  wp_schedule_event( time(), 'hourly', 'my_task_hook' );
}

add_action( 'my_task_hook', 'my_task_function' );

function my_task_function() {
    // your code
}

Which will run the code in my_task_function approximately every hour. If you gain access to real cron jobs you can make this exactly every hour by using wp cron event run --due-now --path="path to install" at regular intervals

A Note on Security

Standalone files that try to bootstrap WordPress, or do their own thing outside of the WP context can be dangerous. WordPress is a CMS, it's meant to handle all requests.

For frontend requests that push data or retrieve data, use:

• Admin AJAX
• REST API endpoints

For form handlers and other page submissions, use:

• Hooks on the same page that check if the page has been submitted

For regular timed events, or batch processing commands that do heavy lifting such as bulk uploads, image processing, bulk edits, use:

• WP Cron
• WP CLI commands

Remember to have dry run modes so you can check the results before you commit to them. If you're using standard WP Cron, don't do too much at once or you'll run out of time or memory, and try to think of things less as a single task, and more like a queue to empty that you bite off small chunks repeatedly

What Kind of Attacks Do Standalone Files Expose Me To?

I can hammer your server with lots of little requests to your updatedb_cron.php script, say 10 times a second. Now your server is running 10 of these scripts trying to update the database. Congratulations you now have a resource deprivation attack, just ping that URL enough times and your database server will fall over or lock up.

Not to mention the damage having them all running at the same time might do to your site. Duplicated posts, corrupted content from several scripts trying to update things out of order, etc

You also need to put a lot of security in that WordPress tries to do out of the box.

Not to mention that the script will always run, even when the plugin has been deactivated. This means it will also run on every site in a multisite install even if it was only intended for the root site