All snippet properties in MODX snippet tags should be surrounded by back-ticks: &propertyName=`value` — never single or double quotes. The back-tick symbol on most keyboards is at the upper left and is typed with shift-~. This is by far the most common error made by new users of MODX.

If a snippet tag has properties, there must be a question mark immediately after the snippet name, followed by a space:

[[SnippetName? &propertyName=`value`]].

If you forget to put one in, you can stare at the snippet properties forever trying to figure out why they're not reaching the snippet.

In some versions of MODX a snippet property with a space on either side of the equals sign will confuse the parser. This is especially difficult for experienced coders who are used to putting a space on both sides to make the code more readable. Snippet tags with properties should always look like this:

[[SnippetName? &propertyName=`value`]]

or, if you want the snippet uncached

MODX Evolution:

[!SnippetName? &propertyName=`value`!]

MODX Revolution:

[[!SnippetName? &propetryName=`value`]]

MODX saves documents, chunks, templates, plugins, and snippets in the MODX cache so they can be retrieved more quickly. That means that sometimes you can make a change and have the change not show up when you preview a document. This is particularly annoying when you fix an HTML, CSS, or PHP error, then when the fix appears not to work, you make another change that actually breaks something. Now, you clear the cache and things are worse than when you started.

If you are editing a snippet in the MODX Manager using the Rich Text Editor (e.g., TinyMCE), the editor will helpfully replace ampersands with this: &. The MODX parser is smart enough to decompose that, but if you save the snippet multiple times, you can end up with &&propertyName, which is too much for the parser. The solution is easy enough: never, never use the RTE when editing code.

In some versions of MODX Evolution, long snippets have to be written on a single line with no carriage returns. It's OK if they wrap automatically in the editor, but if you press Enter, you'll break not just the line, but the snippet as well. (Contributed by Dimmy.)

In MODX Revolution, your getResources, Wayfinder, or other add-on snippet does nothing but output a whole lot of what looks like confusing PHP code. That's because the default behavior of some snippets is to dump the internals of the current object if no Tpl chunks are supplied. It means that either you left out the &tpl property(s), or you misspelled the name. (Contributed by odeclass.)

Why isn't your snippet (or someone else's snippet that you've installed) producing any output? One possibility is that you've misspelled its name. Snippet names are case-sensitive in MODX and it's easy to get then wrong. I can never remember whether it's EZfaq or ezFAQ. In MODX Revolution, FormIt works, but Formit doesn't. And, it's getResources, not GetResources.

With your own snippets, always start with this code:

<?php
$output = "The snippet is running";
return $output;

Don't start working on the code until you see some output.

You are writing your own snippet and you can't see anything wrong with it, but nothing appears on the page where the snippet tag is placed. It's because you forgot to return anything from the snippet. It's working fine (maybe), but since nothing is returned, there's no output for MODX to display. The accepted method for returning output from a snippet is to put this at the end:

return $output;

The best way to avoid this bug is to use the code in the example just above whenever you create a snippet. That way the "return $output" statement will always be there for you.

You're trying to use a snippet like Wayfinder or getResources to display information about some pages. The pages are there, but they're not showing up. In order for them to be seen, they have to be published, not protected by any permission rules, and the "Hide From Menus" checkbox must be unchecked. In Revolution, you may also have to check or uncheck the "Container" checkbox. In MODX Evolution, that checkbox is set automatically if the resource has children. In Revolution, it's up to you to check it if you want snippets to consider it a container. (Contributed by odeclass.)

You have PHP code that refers to a CSS, JS, or image file (e.g., regClientCSS()) but your browser refuses to find the file even though the path looks correct when you view the source of the page. It's because you've used MODX_ASSETS_PATH when you should have used MODX_ASSETS_URL. Unlike included files, which are specified by the file path, all web resources are referenced by URL.

MODX just won't find the page or image you want and you're sure you have the path and file name right. It might be because your template doesn't have a base href statement to tell your browser where to find it. Every MODX template should have this statement in the <head> section:

MODX Evolution:

<base href="[(site_url)]" />

MODX Revolution:

<base href="[[!++site_url]]"

You're trying to use a PHX-like output modifier to control the output of a placeholder or other tag in MODX Revolution. Sometimes it works; sometimes it doesn't. You're probably calling it cached, so you're only seeing what happened the first time it was parsed. If that matches what you expect, it looks like it's working, otherwise not. Use an exclamation point to make the tag uncached so it will be evaluated every time the parser sees it:

[[!+fi.error.name:notempty=`error`]]

Note that in MODX Revolution, any tag can be uncached with the exclamation point. (Contributed by odeclass.)

You've tried everything, but you just can't get Friendly URLs to work. The problem is that, in order for FURLs to work properly, every one of these conditions have to be met:

• Friendly URLs must be enabled in the Manager's configuration section
• The ht.access file must be renamed to .htaccess
• The FURL section of .htaccess must be uncommented
• The rewrite base in .htaccess must be set correctly
• The rewrite engine must be enabled (it's off by default in XAMPP)
• You need to enable the rewrite engine in the correct php.ini file
• All documents need to have an alias
• The documents must be published
• The documents must not be hidden by any permission rules
• You may need the base href line from the section above

The correct php.ini file can be found by looking in the Reports section of the Manager for System Information and clicking on the "view" link next to PhpInfo. The PhpInfo screen will show you the path of the php.ini file PHP is using. Remove the comments in front of the following two lines:

LoadModule rewrite_module<br /> modules/mod_rewrite.so

I ran into this one recently. I went back to work on a local version of a site where FURLs had been working the last time I used it, but they weren't working now. I checked everything but the php.ini file. I knew it couldn't be that because they had been working before. After more time than I care to admit, I finally realized that a while back, I had reinstalled XAMPP. The install was unsuccessful and I had to uninstall it completely and start over. That undid my change to php.ini.

One of your snippet properties doesn't seem to have any effect. This is just like the Missing Output Bug I, except that you've misspelled the name of the property rather than the name of the snippet. It's particularly insidious for properties that have some form of the word "id" in the name (is it "StartId" or "startID")? For Wayfinder it's "StartId".

You're trying to use a query to retrieve a MODX object from the database. You know it's there, but it just won't be found. It's because you've forgotten the name of the object's "name" field. The "name" field for documents is "pagetitle"; and lest you think this bug only bites beginners, what prompted me to create this page was spending over an hour earlier this evening wandering through the MODX and xPDO code with a debugger trying to figure out why I couldn't retrieve a Revolution document that I absolutely knew the name of with this code:

$resource=$modx->getObject('modResource',array('name'=>'NewsPublisher'));

This is a particularly insidious bug for more advanced coders. If you're bouncing back and forth between your PHP code and a snippet tag in MODX with many properties, it's easy to accidentally put a property in the snippet tag that looks like this:

$propertyName=`value`

MODX doesn't recognize the property (or any that follow it) as properties. The snippet will run fine, but those properties will have no effect.

Because PHP has the concept of "variable variables", you can accidentally start a variable name with two dollar signs: $$variableName. PHP won't complain, but the variable won't do its job properly.

This one is particularly insidious. Very few code editors will catch it because it's still valid PHP. It involves a dot where there should be a comma:

$modx->addPackage('quotes', $path . 'model/', 'bobs_');

It should be:

$modx->addPackage('quotes', $path , 'model/', 'bobs_');

This might be the most insidious of all, though it's unlikely to happen to you. Let's say you have a function in a plugin that is really handy -- in this case a function that writes to a log file. You copy the code to another plugin and change it slightly to write to another log file. Because the plugins are attached to the same system event and the function names are the same, you wrap the function definitions in if ( !function_exists() ) code.

This seems to work fine for each plugin when tested individually. When both are enabled, however, the second one to execute writes to the wrong log file. Because the function is already defined, the function definition in the second plugin is ignored. Since you're just checking the second log file (nothing is written to it) and you already know the function works, you think that there's something wrong with the rest of the plugin. Eventually, you figure it out, but by that time, you're nearly bald from pulling your hair out.

The solution is to make the functions identical and pass the name of the log file as an argument (doh). It's easy to think of plugins as independent pieces of code, but if they're attached to the same plugin, they're really not. Functions, variables (including $_SYSTEM variables), and placeholders can all collide leading to some very frustrating debugging.