1

My script needs to load the whole WP in order to work probably. I'm currently doing it this way

if ( !defined('ABSPATH') ) {

    /** Load WordPress Bootstrap */
    @ini_set('include_path', '../../../');
    require_once('../../../wp-load.php');

}

//additional html stuff

do_action('my_custom_hook');

//more html stuff

which works most of the time. Sometimes people get a Fatal error for a missing file though.

The script is located at

wp-content/plugins/my-plugin-slug/script.php

What's the best way to load it?

4
  • You should NOT need to use ../../../, ever! Instead, you need to find the proper hook to use for your function. Your plugin is already in the WordPress environment. Why do you need to load it again?
    – josh
    Commented Oct 24, 2014 at 15:30
  • it's a cron page and should be accessible directly and not via some query parameters. Also I disable the wp-cron with DISABLE_WP_CRON on that page
    – Xaver
    Commented Oct 24, 2014 at 15:53
  • I'd need to see more of your code; perhaps the script.php file. It's fine if the server cron runs the file; but you're trying to get WP information by re-loading the entire platform. I'm suggesting there is a hook you can run from your script.php file, which can perform your processing on each cron run without having to reload WP.
    – josh
    Commented Oct 24, 2014 at 16:34
  • I basically call a custom hook. The other stuff is just HTML, JS and CSS. I've updated my questions
    – Xaver
    Commented Oct 24, 2014 at 17:22

1 Answer 1

2

Requiring a file using relative path is never a good idea, that because wp content folder can be easily changed and that make your code fail.

You should convert your file into a MU plugin (you only need to save it wp-content/mu-plugins folder) and change it to something like:

add_action( 'wp_ajax_super_custom_stuff', 'my_super_custom_stuff' );
add_action( 'wp_ajax_nopriv_super_custom_stuff', 'my_super_custom_stuff' );

function my_super_custom_stuff() {

  // additional html stuff

  do_action('my_custom_hook');
  exit();

}

After that, to make the script run, instead of calling the url

http://example.com/wp-content/plugins/my-plugin-slug/script.php

you can call

http://example.com/wp-admin/admin-ajax.php?action=super_custom_stuff

This will always work because wp-admin folder, unlike wp-content, can't be changed because it is hardcoded in a lot of places.

You can run the script from a linux crontab using something like:

wget -q --spider "http://example.com/wp-admin/admin-ajax.php?action=super_custom_stuff"
4
  • I like this approach but I have to copy the script on plugin activation to the mu-folder. Does this has any drawbacks?
    – Xaver
    Commented Oct 25, 2014 at 8:23
  • Normally MU plugins should be moved in right folder "manually". If plugin is something to be shared/sold you should explain to users how to do that in installation istructions. If plugin is for yourself, just take it and move to MU folder. In theory is possible to use WP filesystem API to copy a file to MU folder, but very restrictive permissions for the folder can prevent it from work. For plugin to be shared/sold you may "try" to do via filesystem API, and if it fails show a notice for users that says to do it manually.
    – gmazzap
    Commented Oct 25, 2014 at 10:30
  • Also note that the same code can be used in a regular plugin and it will work... But in that case you need to activate it, while MU plugins don't need to be activated.
    – gmazzap
    Commented Oct 25, 2014 at 10:31
  • Hey thanks again for the detailed answer! I'm going to add a script which can be copied into the mu-plugins folder in case the "old" version fails. This way I can still have backward compatibility
    – Xaver
    Commented Oct 25, 2014 at 14:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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