8 Two Wheel 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 are attracted to everything just as they did at the very beginning.
Below are the notes that I did while working with the MODX Revolution over the past year. These simple techniques, I knew about them before, would help me save an incredible amount of time. The target audience for these notes is newcomers who only recently figured out what MODX is. Frank "bikes", out of respect for you, did not include notes.

1. Simplify working with MODX Manager

With the increase in the volume of the project, the deployment of the resource tree when loading the manager can take exactly as much time as is enough to shake your psyche. Collapse those 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 have left expanded.

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

2. Passing parameters to a snippet

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

echo $howMany. ' ' .'Monkeys'; 

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

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

Thus, in the snippet, you can transfer, for example, with the necessary logic for that, the language in which you want to display the content.

3. Calling MODX in a static PHP file

In case if you use the snippet only for include / require_once of a static file, the previous technique will still work as expected. But what if you need to use the $ modx object itself? For example, take the 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, such things, you can use as much as you like:

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

3. Switch context depending on the domain

In the above technique flashed this line:

 $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 should be run either in the plugin, on the OnHandleRequest event, or a little “earlier”, at the end of index.php, which, perhaps, none of the living will advise.

4. Switch on 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 ($ modx-> context-> get ('key')! = "Mgr" condition , as you may have guessed, prevents the code from running right in the manager.

5. Context Settings

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

 [[!++Key]] 

6. Call in the context the chunk we need, without creating separate settings

The previous method, of course, is 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 respect. For example, create two chunks: Footer_Web and Footer_One , where Web and One are the names of contexts. Now, let's call them on the page / in the template:

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

7. modMail

modMail is a class that is extensible by modPHPMailer. By default embedded in MODX and 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 myEmailTemplate chunk as a template for our letter. If the letter needs to be displayed, for example, the Username obtained from the form, we do the following:

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

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

 <p>Username: [[+username]]</p> 

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