8 two-wheeled MODX Revolution tips

I have been working with MODX Revolution not so long ago, but, nevertheless, at the moment, for me it is a CMS pearl. Flexibility, extensibility and intuitiveness (If you forget about the ill-fated MODX Manager for a moment), they attract everything in it the same way as at the very beginning.
Below are the notes that I made while working with MODX Revolution over the past year. These simple tricks, if I had known about them before, would help me save an incredible amount of time. The target audience for these notes is newbies who have only recently figured out what MODX is. Frank "bicycles", out of respect for you, did not include in the notes.

1. Simplification of work with MODX Manager

With the increase in the volume of the project, the deployment of the resource tree when loading the manager can take just as much time as is enough to shake your psyche. Collapse the categories and contexts in which you are currently not working. When you go to a new page, the resource tree will show only what you left expanded.

Another thing that has a very adverse effect on performance is the RSS feeds on the manager’s home page, reporting new versions and security fixes. Disabled as follows: the System -> the System the Settings -> the MODX News Feed the Enabled / the MODX Security Feed the Enabled -> No .

2. Passing parameters to the snippet

Suppose you have a snippet called Monkeys that displays the most common line on the page:

echo $howMany. ' ' .'Monkeys';

You need to display this sippet on several pages with different values ​​of the $ howMany variable . This is done very simply:

[[Monkeys?&howMany=`12`]]

Thus, you can transfer to a snippet, for example, if you have the necessary logic for that, the language in which you want to display the contents.

3. Calling MODX in a static PHP file

In the event that you use the snippet only for the include / require_once static file, the previous method will still work as expected. But, what if you need to use the $ modx object itself? For example, pick up a pagetitle of a certain resource? Everything is also very elementary:

require_once '/var/www/config.core.php';
require_once MODX_CORE_PATH.'model/modx/modx.class.php';
$modx = new modX();
$modx->initialize('web');

Now, like this, you can use as much as you like:

$resource = $modx->getObject('modResource', $modx->resourceIdentifier);
$pagetitle = $resource->get('pagetitle');

3. Switch context by domain

In the above reception, a line flashed:

$modx->initialize('web');

This is the initialization of the default context, in which, in fact, all of the above will work. But, what if there are several contexts, and each should be displayed from its own specific domain? Easy!

switch ($_SERVER['HTTP_HOST']) {
    case 'domainOne.com':
    $modx->initialize('web');
    break;
    case 'domainTwo':
    $modx->initialize('two');
    break;
    case 'domainThree':
    $modx->initialize('three');
    break;
    default:
    $modx->initialize('web');
    break;
}

This switch must be run either in the plugin, on the OnHandleRequest event , or a little "earlier", at the end of index.php, which, perhaps, no one living now will advise.

4. Switch by context

If you need to "diversify" your code for each of the contexts, you can use the following:

if($modx->context->get('key') != "mgr"){
    switch ($modx->context->get('key')) {
        case 'web':
        $howMany = 3;
        break;
        case 'two':
        $howMany = 8;
        break;
        case 'three':
        $howMany = 12;
        break;
        default:
        $howMany = 12;
        break;
    }
}
echo $howMany. ' ' .'Monkeys';

The if condition ($ modx-> context-> get ('key')! = "Mgr") , as you might have guessed, prevents code from being run right in the manager.

5. Context Settings

Another way to vary content in existing contexts is to customize your settings. Open the context you need and go to the Context Settings tab . By clicking Create New , specify Key , and, accordingly, Value . The key you created is called in the document / chunk as follows:

[[!++Key]]

6. In the context, we call up the chunk we need without creating separate settings

The previous method is, of course, good, but what if we only need different chunks depending on the context? The [[* context_key]] key , which returns the name of the current context, is very useful in this regard . For example, create two chunks: Footer_Web and Footer_One , where Web and One are context names. Now, call them on the page / in the template:

[[$Footer_[[*context_key]]]]

7. modMail

modMail is a class extensible by modPHPMailer. By default, it is built into MODX and is used as follows:

$message = $modx->getChunk('myEmailTemplate');
$modx->getService('mail', 'mail.modPHPMailer');
$modx->mail->set(modMail::MAIL_BODY,$message);
$modx->mail->set(modMail::MAIL_FROM,'me@example.org');
$modx->mail->set(modMail::MAIL_FROM_NAME,'Johnny Tester');
$modx->mail->set(modMail::MAIL_SUBJECT,'Check out my new email template!');
$modx->mail->address('to','user@example.com');
$modx->mail->address('reply-to','me@xexample.org');
$modx->mail->setHTML(true);
if (!$modx->mail->send()) {
	$modx->log(modX::LOG_LEVEL_ERROR,'An error occurred while trying to send the email: '.$modx->mail->mailer->ErrorInfo);
}
$modx->mail->reset();

* Excerpt from official documentation .

8. From snippet to chunk

The above example takes the chunk myEmailTemplate as a template for our email. If in the letter you need to display, for example, the Username obtained from the form, we do the following:

$Username = $_POST['Username'];
$message = $modx->getChunk('myEmailTemplate', array(
   'username' => $Username,
));

Thus, we pass Username to our myEmailTemplate chunk . We get it in a chunk, in this way:

Username: [[+username]]

That's all for today. If anyone would be interested in such notes, I am ready to gladly continue them. Thank you for attention.