On March 26, 2019 we launched new MODX Forums. Please join us at the new MODX Community Forums.
Subscribe: RSS
  • I found a few posts on this subject, but found no direct example code, so I thought I would share this.

    I was developing a WP theme to integrate with a MODx site, and wanted to include my fully parsed site header and footer elements. I could have created modx documents that contained nothing but the elements I was after, as GaneshXL recently suggested, then include them into the WP theme. But I decided to try getting the modx parser up and running inside WP instead. I think this solution may weigh a little less because it doesn’t include files via http, and when the modx parser runs, I’m not running the entire thing. At the same time, I haven’t dug deeply into the caching ramifications, so maybe running this modified parser on each WP page could be more costly depending on the site in question.

    I had my header and footer coming from chunks named Header and Footer. You can use this technique to grab and parse anything in your modx site though.

    Luckily, the html template was built so that both the header and footer html could be included in on WP theme file - footer.php.

    What follows is sort of a "mini" modx parser. A lot of what modx normally does is not required (figuring out doc id, checking doc permissions and so on). At the same time, I had to take additional steps to make it work inside a WP theme file (e.g. dealing with globally scoped variables). There is probably a better way than putting it right in a theme template file like this - if anyone can point that out to me, please do and I will improve the solution. This is what I ended up with after a couple of hours of hacking around smiley

     * this goes at the top of a WP theme template file, e.g. footer.php
    // next line assumes that modx is installed in site root, and WP is a subdirectory off root (e.g. /blog/)
    define('MODX_BASE_PATH', dirname(dirname(dirname(dirname(dirname(__FILE__))))) . '/');
    define("IN_PARSER_MODE", "true");
    define("IN_MANAGER_MODE", "false");
    if (!defined('MODX_API_MODE')) {
        define('MODX_API_MODE', true);
    // initialize the variables prior to grabbing the config file
    $GLOBALS['database_type'] = 'mysql';
    $GLOBALS['database_server'] = 'localhost';
    $GLOBALS['database_user'] = 'xxxxxxxxxx';
    $GLOBALS['database_password'] = 'yyyyyyyyy';
    $GLOBALS['dbase'] = 'zzzzzzzzzz';
    $GLOBALS['table_prefix'] = 'modx_';
    $GLOBALS['base_url'] = 'http://www.xxxx.com/';
    $GLOBALS['base_path'] = '/home/xxxx/public_html/';
    define('MODX_BASE_URL', $GLOBALS['base_url']);
    define('MODX_SITE_URL', $GLOBALS['base_url']);
    $ipath = ini_get('include_path');
    ini_set('include_path', $ipath . ':' . $GLOBALS['base_path']);
    // initiate a new document parser
    $GLOBALS['modx'] = new DocumentParser;
    $modx =& $GLOBALS['modx'];
    $etomite = &$GLOBALS['modx']; // for backward compatibility
    // set some parser options
    $modx->minParserPasses = 1; // min number of parser recursive loops or passes
    $modx->maxParserPasses = 10; // max number of parser recursive loops or passes
    $modx->dumpSQL = false;
    $modx->dumpSnippets = false;
    $modx->tstart = $tstart; // feed the parser the execution start time
    $modx->documentMethod = 'id';
    $modx->documentIdentifier = 10;
    // header
    $modx_header= $modx->rewriteUrls($modx->parseDocumentSource('{{Header}}'));
    // footer
    $modx_footer= $modx->rewriteUrls($modx->parseDocumentSource('{{Footer}}'));

    A couple of things I want to point out...
    I use a weblink in modx to point to the wp blog. That weblink’s doc id is 10, which is why in the above code, I have explicitly set $modx->documentIdentifier = 10. When the Header chunk renders, Wayfinder outputs the menu as if we’re there on that modx doc (i.e. makes the Blog menu item active).
    The last couple of lines show how easy it is to parse anything at all. Inside both ->parseDocumentSource calls, you can see just raw chunk tags. Modx parses thoses, runs snippets etc etc.

    Please feed back especially with critical comments. I might reuse or generalize this solution further.

    For reference, the site is here: http://bit.ly/bC8yI

      Mike Schell
      Lead Developer, MODX Cloud
      Email: mike@modx.com
      GitHub: https://github.com/netProphET/
      Twitter: @mkschell
    • Looks good Mike smiley
      Will have to try it on a dev site and report back.
      • This looks good.

        Thanks for sharing! smiley
          Zaigham R - MODX Professional | Skype | Email | Twitter

          Digging the interwebs for #MODX gems and bringing it to you. modx.link
        • This looks very interesting. Cool method, thanks for posting.

          I have seen this requested a few times and I’m wondering the motivation behind joining WP to MODx? Is this to take advantage of the blogging function in WP? Or is this to be able to use the wealth of widges available for WP? Won’t this isolate the blog admin from the rest of the site admin?
            [font=Verdana]Shane Sponagle | [wiki] Snippet Call Anatomy | MODx Developer Blog | [nettuts] Working With a Content Management Framework: MODx

            Something is happening here, but you don&#39;t know what it is.
            Do you, Mr. Jones? - [bob dylan]
          • @dev_cw Some of my clients are just dead-set on using WP for their blogging. Though it’s easy to set up a simple similar-looking blog in MODx, WP just has tons of features that make it great for blogging out of the box. They also want the WP and MODx site to be visually seamless and for changes in site navigation to carry through to the WP blog automatically, which this technique allowed me to acheive.
            Beyond blogging, I don’t think I would use any of WP’s widgets. I really do prefer to build stuff in MODx.
            You’re right, this does isolate the MODx and WP admin from each other. So far, my clients don’t seem to mind that. Obvious improvements would be SSO or a module/plugin to post to WP from inside MODx. Ultimately, I’d much rather build a native MODx WP-killer ;-)
              Mike Schell
              Lead Developer, MODX Cloud
              Email: mike@modx.com
              GitHub: https://github.com/netProphET/
              Twitter: @mkschell
            • This is actually a very interesting approach. I think something similar could be used to include modx parsed elements within a Tradingeye ecommerce site, which is my next project.

              Thanks for sharing!
                Snippets: GoogleMap | FileDetails | Related Plugin: SSL
              • Hi All,

                I am basing a plugin for vbulletin on your code, which has been, after some modifications, very successful.

                I have a chunk with two cached snippets inside it. Inside one of those, the UltimateParent snippet is called, which must be uncached. Due to the snippet calls having to be alternate, I can only do this, or the inverse. These are inside a chunk, which is called by parseDocumentSource().

                The problem is, in this configuration the outer snippets do not execute, they are just returned in the source. If I inverse the cache/uncache status (so that the outer ones are uncached) they all fire... but the caching means my menus stop working.

                Any ideas?

                Executes but caching is not as required:
                            <div id="nav">
                 [[Wayfinder? &startId=`0` &config=`dropline2`]]
                 [[Wayfinder? &startId=`[!UltimateParent? &topLevel=`0`!]` &config=`dropline2sub`]]

                Does not execute outer snippets, but caching is as I need it (this does work in ModX pages, by the way.
                            <div id="nav">
                 [!Wayfinder? &startId=`0` &config=`dropline2`!]
                 [!Wayfinder? &startId=`[[UltimateParent? &topLevel=`0`]]` &config=`dropline2sub`!]
                • Hello,

                  Thanks for sharing.
                  It will be usefull to export any fully parsed content of modx documents.

                  Some plugins don’t parse enough the content: PrintDoc and PDF exports.

                  Have a good day!
                  • I’ve integrated it into the header.php file in Wordpress but the MODx header chunk just isn’t appearing in the WP pages. Have checked everything. Using MODx 1.02...
                      Mostly harmless.
                    • I tried a different approach that worked here.