How can I allow a standalone page to access WordPress functions without including/requiring wp_load or wp_config?
I am developing a plugin and need to allow access to the WP database on a standalone php page. This page is a simply curl request that returns a full HTML page to display. For context, the plugin is a list of jobs from an API that then need to link to the full job ad (a full HTML page).
The code I currently have is this (in a jobad.php page):
$root = dirname(dirname(dirname(dirname(dirname(__FILE__)))));
if (file_exists($root.'/wp-load.php')) {
require_once($root.'/wp-load.php');
}
This is the code that I pulled from every answer I have found on how to accomplish this. Including from wordpress.org's own forums. From this stackoverflow answer, for example: Using WPDB in standalone script?
It works fine, but when I tried to submit the plugin to the WP directory, the plugin was rejected for including wp_load.php in this way. It makes sense why not to, but I cannot find any other way to make the file work within WordPress.
The outcome I need
From a list generated by a shortcode, each item has a link that will return a full HTML page. This HTML page is returned as a cURL response--not a URL (or I could just have each link drive an iframe). For context, I am building the link this way
$job_ad_link = plugins_url( 'includes/jobad.php' , dirname(__FILE__) );
$job_id = //id from database;
<a href="'.$job_ad_link.'?sgjobid='.$job_id.'">link</a>
Thus calling jobad.php will run the cURL function for the correct job_id and display the cURL response. I can run the cURL as AJAX and avoid this problem, but because it is a full HTML page, I cannot simply return the cURL in a div. In an iframe is awkward and iffy and I would rather not use it (and have had no success in trying).
For clarification, the response from WordPress:
Including wp-config.php, wp-blog-header.php, wp-load.php, or pretty much any other WordPress > core file that you have to call directly via an include is not a good idea and we cannot > approve a plugin that does so unless it has a very good reason to load the file(s). It is > prone to failure since not all WordPress installs have the exact same file structure.