<![CDATA[ including parsed modx elements inside WP theme - alternate method - My Forums]]> https://forums.modx.com/thread/?thread=48937 <![CDATA[Re: including parsed modx elements inside WP theme - alternate method]]> https://forums.modx.com/thread/48937/including-parsed-modx-elements-inside-wp-theme---alternate-method#dis-post-285950 here.]]> kurucu Feb 10, 2010, 03:39 AM https://forums.modx.com/thread/48937/including-parsed-modx-elements-inside-wp-theme---alternate-method#dis-post-285950 <![CDATA[Re: including parsed modx elements inside WP theme - alternate method]]> https://forums.modx.com/thread/48937/including-parsed-modx-elements-inside-wp-theme---alternate-method#dis-post-285949 hotdiggity Feb 09, 2010, 08:03 PM https://forums.modx.com/thread/48937/including-parsed-modx-elements-inside-wp-theme---alternate-method#dis-post-285949 <![CDATA[Re: including parsed modx elements inside WP theme - alternate method]]> https://forums.modx.com/thread/48937/including-parsed-modx-elements-inside-wp-theme---alternate-method#dis-post-285948
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!
Thierry.]]>
thbenda Oct 03, 2009, 06:07 AM https://forums.modx.com/thread/48937/including-parsed-modx-elements-inside-wp-theme---alternate-method#dis-post-285948
<![CDATA[Re: including parsed modx elements inside WP theme - alternate method]]> https://forums.modx.com/thread/48937/including-parsed-modx-elements-inside-wp-theme---alternate-method#dis-post-285947
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`]]
            </div>


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`!]
            </div>
]]>
kurucu Jun 16, 2009, 09:02 AM https://forums.modx.com/thread/48937/including-parsed-modx-elements-inside-wp-theme---alternate-method#dis-post-285947
<![CDATA[Re: including parsed modx elements inside WP theme - alternate method]]> https://forums.modx.com/thread/48937/including-parsed-modx-elements-inside-wp-theme---alternate-method#dis-post-285946
Thanks for sharing!]]>
therebechips Apr 16, 2009, 11:17 AM https://forums.modx.com/thread/48937/including-parsed-modx-elements-inside-wp-theme---alternate-method#dis-post-285946
<![CDATA[Re: including parsed modx elements inside WP theme - alternate method]]> https://forums.modx.com/thread/48937/including-parsed-modx-elements-inside-wp-theme---alternate-method#dis-post-285945 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 ;-)
]]>
netProphET Apr 16, 2009, 10:58 AM https://forums.modx.com/thread/48937/including-parsed-modx-elements-inside-wp-theme---alternate-method#dis-post-285945
<![CDATA[Re: including parsed modx elements inside WP theme - alternate method]]> https://forums.modx.com/thread/48937/including-parsed-modx-elements-inside-wp-theme---alternate-method#dis-post-285944
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?]]>
dev_cw Apr 16, 2009, 10:21 AM https://forums.modx.com/thread/48937/including-parsed-modx-elements-inside-wp-theme---alternate-method#dis-post-285944
<![CDATA[Re: including parsed modx elements inside WP theme - alternate method]]> https://forums.modx.com/thread/48937/including-parsed-modx-elements-inside-wp-theme---alternate-method#dis-post-285943
Thanks for sharing! smiley]]>
zaigham Apr 16, 2009, 09:53 AM https://forums.modx.com/thread/48937/including-parsed-modx-elements-inside-wp-theme---alternate-method#dis-post-285943
<![CDATA[Re: including parsed modx elements inside WP theme - alternate method]]> https://forums.modx.com/thread/48937/including-parsed-modx-elements-inside-wp-theme---alternate-method#dis-post-285942
Will have to try it on a dev site and report back.]]>
bunk58 Apr 15, 2009, 04:30 PM https://forums.modx.com/thread/48937/including-parsed-modx-elements-inside-wp-theme---alternate-method#dis-post-285942
<![CDATA[including parsed modx elements inside WP theme - alternate method]]> https://forums.modx.com/thread/48937/including-parsed-modx-elements-inside-wp-theme---alternate-method#dis-post-285941
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

<?php
/**
 * 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
include_once($GLOBALS['base_path'].'manager/includes/document.parser.class.inc.php');
$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->getSettings();
$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

]]>
netProphET Apr 15, 2009, 04:22 PM https://forums.modx.com/thread/48937/including-parsed-modx-elements-inside-wp-theme---alternate-method#dis-post-285941