Integrating WordPress into PHP website

1 Views

I apologize in advance if I am not describing the scenario the best way possible, but I will do my best.

I have a e-commerce(ish) website. We are looking to integrate a blog into the existing PHP (MVC) framework.

Read More

I am using 

define('WP_USE_THEMES', FALSE);
require('/wpengine/wp-blog-header.php');

I have WordPress installed under a subfoler called ‘wpengine’, but would like to call a WP function to render the theme from a custom controller, so I can place the rendered content into a page as I need it.

Is there a WordPress function to which I can pass GET parameters to render content as wordpress would normally do?

Maybe this will help describe what I am looking to do 

->Page Request
---> Loads custom framework
---> Builds custom view
---> Gets content from WP via function call ( rendered category, post, or page )
---> Injects content from WP into view
-> Returns page
Post Views: 1

Related posts

Leave a Reply

1 comment

  1. Using the following setup for assumptions:

    • An MVC controller in / that catches everything except /blog
    • WP serving /blog
    • WP files in /wp

    In the wp/wp-config.php file, add:

    define('WP_HOME',    'http://example.com/blog');  # important! no trailing slash
define('WP_SITEURL', 'http://example.com/wp');    # important! no trailing slash

    These are the two constants that make a lot of magic happen when making WP work outside of its folder. And things would work more or less out of the box with the above, provided you’ve a custom-built theme, except for the fact that you want to wrap the WP output in a view.

    Some pseudo-code to get you to where you want to… (pick your poison)…

    The first approach is to remote fetch WP:

    function http_fetch_the_wp_mess() {
  $request = remote_fetch('http://path/to/wp/wherever');
  extract_and_process_headers($request);
  return extract_and_process_content($request);
}

    The benefit of first approach is that it’s reasonably clean and without risks. You fetch /wp/wherever using http, and str_replace() URIs as needed in the content returned to you. (You could also do this using ajax or even an iframe.) WP gets to live in its own ghetto using a theme with no header, footer or sidebar, and you should be good to go.

    The other approach is to include WP, and it’s much trickier (as always, the devil is in the details):

    function php_include_the_wp_mess() {
  # Optionally:
  # make_deep_copy_of_superglobals();

  ob_start();
  require '/path/to/wp/index.php';

  # The meat of our procedure:
  pray_that_nothing_gets_screwed_up_due_to_using_so_much_global_state();

  # Optionally:
  # cleanup_superglobals();
  # cleanup_and_fix_headers();

  return ob_end_clear_up_to_where_started_further_up();
}

    Several points in the above:

    1. $_GET, $_POST, $_COOKIE and $_REQUEST all get slashed, as well as — wait for it! — $_SERVER. They occasionally get changed, too. So be on the lookout if you rely on them anywhere further in your request handling. Make backups of any piece of information you might care about before handling it to WP.

    2. Due to your MVC wanting unslashed data, as opposed to WP’s slashed data, and due to the fact that both you might register a shutdown actions in addition to those registered by WP, your mileage may vary if they involve any database queries. Be very wary of security considerations if you decide to backup and restore superglobals in the state they were in before WP got fired, because WP and plugins actually can and do issue queries on that shutdown hook.

    3. Needless to say, you still need a custom theme. One with no header, footer or sidebar. Yada, yada.

    4. In case it matters, some plugins break when they can’t access their favorite globals; many do, in fact. Some plugins also start output buffers; not as many, but you’ll still need to be wary of that when you terminate output buffers.

    5. WP and a rather small number of plugins (mostly, but not only, cache- and anti-spam related) may change some headers, and occasionally do so incorrectly or not as optimally as they should. So be on the lookout on that front if the options they take conflict with your own caching options. Especially when it comes to cookies.

    6. Speaking of caching, you will necessarily need to roll your own: output has already started — even if it’s in a buffer — by the time WP kicks in, and the plugins will all cache on the shutdown hook.

    7. If you need to make WP serve arbitrary pages, make WP_HOME point to the site’s root folder instead, and it should work…

    I’ll conclude with two links for further inspiration in the event I did a poor job at discouraging you to try: