Glossary of Revolution Terms
A MODX Third-party Component (3PC) that does not modify the Core or extend any of its classes, but yet still provides extra functionality to the MODX instance.
Any type of file resource that is usually located in the /assets directory, as defined by the constant
A synonym for the MODX manager interface.
The process of storing frequently requested data and where it is stored. By caching data that is being reused, a lot of database requests can be prevented, resulting in a better performance. MODX Revolution offers a number of different caching features on different levels within the application. See more
An optional classifying name that can be attached to any Element or PropertySet (and other objects in later versions of Revolution) that separates it from other similar objects.
Tags in the form
[[$ChunkName]] that can be used in reference to Chunks.
Also called "Third-party Component", or 3PC, a Component usually provides extra functionality to MODX, usually in the form of an Add-on, Core Extension, or Template.
Essentially entry point for AJAX requests in MODX. It doesn't do any database manipulation on its own; just simply load up the main MODX class, sanitize any request data, and then handle the request by pointing to the appropriate Processor file See more
Sets the extension, mime-type and binary setting for any Resource. See more
A delineator of resources and settings that can be used for a variety of reasons; usually used to create multiple-context sites, such as subdomains, multi-language sites, etc.
A single setting for that Context that either creates a new setting or overrides a System Setting.
Each unique MODX Core is represented by a named Workspace. When you install Revolution initially, the MODX Core used by the setup application is recorded into the MODX database as the Default MODX Workspace. In future MODX Revolution releases, there will be an ability to manage multiple Workspaces from a single database, directly from the manager application. This will make it easy to isolate upgrades to the MODX Core; by quickly adding a new Core Workspace and selecting a menu option, you'll be able to apply an entire new MODX Core installation to production sites after testing on a staging site, or quickly revert to a previous Core Workspace you know works. This will be especially important for multi-site configurations running on shared MODX Core installations.
A specific type of Resource, usually pertaining to a normal website page.
See Resource Identifier.
Also called "Content Elements", a single Template, Template Variable, Chunk, Snippet, Plugin, Category, or Property Set visible in the Manager Elements tree.
Also called "Core Extension". A MODX Third-party Component that modifies the MODX Core, such as a custom User or authentication class, caching mechanisms, or context manipulation classes.
A type of xPDOVehicle Resolver that copies files from the source location to the target location in a Transport Package.
Form Customization Set¶
Friendly URLs, Friendly aliases¶
Friendly URLs (FURLs) is actually short for SEO-friendly URLs. SEO, as you probably know, is an acronym for Search Engine Optimization. Since "Search-engine-Optimization-friendly-URLs" is quite a mouthful, they're usually referred to as FURLs in MODX.
Tags in the form
[[%LanguageStringKey]] that reference MODX Lexicon entries.
A Lexicon is a dictionary of words and phrases organized by Culture (more specific than language, i.e. en-UK) that is used to internationalize the manager application and can be used by Add-On and Core Extension developers to provide localization facilities for their own components. This replaces the legacy MODX language files and allows customization of the entries directly from the manager application.
Lexicon Topic (formerly Foci)¶
A set of Lexicon Entries focused on a particular subject. Revolution only loads Lexicon Entries as it needs them, by their Topic, to reduce load times.
Tags in the form
[[~ResourceId]] that reference the URL of a particular Resource.
The back-end of the MODX interface.
With MS you can specify the "source" of media through many types - from the file system itself, to an Amazon S3 bucket, to a Flickr album. MODX provides two source types with the core installation: the file system and Amazon S3 bucket integration. Other sources can be made by creating Media Source Drivers, or by downloading them from Package Management. See More
An organizational tag for Components to use to identify Lexicon Entries, Settings, and other objects related to the Component in a Revolution site. Also specifies an absolute path in which the Component may be found.
A web service that enables remote installation of Transport Packages directly from the Manager.
Tags in the form
[[+PlaceholderName]] that reference MODX Placeholders, usually set with
$MODX->setPlaceholder('placeholderName','value') in a Snippet or Plugin.
Any of the fields of the
site_content table, such as
menuindex, etc. Some fields are available on the Document Create/Edit screen and via Resource Tags; Others can only be accessed via the
A single variable for an Element; used to set a specific parameter for the Element.
A collection of variables used for a particular purpose with an Element. Property Sets are attached to Elements and pass in the Properties that they carry as parameters to the Element. An example is a custom Property Set for a Snippet that passes in specific parameters to the Element, overriding the default behavior.
A type of container that is interpreted by the Parser to fetch content. Can have any number of derivative classes; the most common is a Document.
Also called a Document ID, Resource ID, or Document Identifier; the number in parenthesis in the MODX Resource Tree in the Manager that uniquely identifies the Resource specified.
Tags in the form
[[*ResourceFieldTV]], which can be used to refer to Resource Fields, or Template Variables.
Resolver (from Transport Package)¶
Post-processor: a script or predefined action that is evaluated after a Transport Vehicle is installed or uninstalled. Resolvers always occur after the vehicle's object is save()'d, and can then perform actions on MODX before anything else happens in the install/uninstall process.
An example of a PHP Resolver is one that attaches Plugin Events to a newly-installed Plugin.
An example of a file Resolver is one that copies the
assets/getResources directory in the
xPDOVehicle path to
Tags in the form
[[SnippetName]], also referred to as Snippet Calls.
A specific type of Resource that is a direct reference to a specific file on the MODX site. The content is replaced with the contents of that file.
A type of Resource that references a single, local MODX Resource; the Resource's content will replace the Symlink's content.
A site-wide variable accessible to the MODX site. Can be overridden by Context Settings and User Settings.
Template Variables (or TVs)¶
Custom Resource Fields created by the user on the Document Create/Edit Screen and referenced using Content Tags.
A user-specific setting that either creates a new setting or overrides the similar Context Setting and System Setting. Used to provide unique settings to that user.
Validator (from Transport Package)¶
Pre-processor: a script or predefined action that executes prior to the Transport Vehicle being installed or uninstalled. If the validator returns true, the install/uninstall action will proceed as normal. If the validator returns false, MODX will not uninstall or install the package.
A Validator could be used to determine if a directory exists and is writable, to see if other MODX elements are already installed, or to determine if a certain version of MySQL and PHP are used on a server.
A type of Resource that references a specific URL or MODX Resource, redirecting the visitor to that URL or Resource.
The base Transport Vehicle class, xPDOVehicle, stores xPDOObject instances (which represent a row of data in a table) in it's payload, along with various attributes that control how the object is installed/uninstalled in a Core Workspace (see xPDOVehicle Validators and xPDOVehicle Resolvers).