Pods offers web developers the ability to globally set options, tucked away and invisible to client eyes. These constants can be defined in
wp-config.php or in a file inside your
mu-plugins folder. By defining these constants, you’re able to alter the default functionality in Pods; settings such as hiding the Pods sidebar menu, toggling on or off Pods’ API cache, enabling or disabling Pods Components, and more.
When defining a Pods constant, be sure that it’s defined before Pods loads, which is when the
plugins_loaded action runs.
Before defining any constant, determine if it’s actually needed; remember: constants are constant, and defining a constant without understanding what is actually happening could have adverse effects!
NOTE: All defaults are as of Pods v2.x.
How to Define a Constant
The syntax you should follow goes like this:
define( 'CONSTANT_NAME', 'constant value' );
An example using a Pods constant might look like this:
define( 'PODS_DISABLE_CONTENT_MENU', true );
Following you will find all of the available constants provided within the Pods codebase. Unless otherwise noted, all Pods constants available accept boolean values: i.e. one of
These constants can disable some of Pods Admin screens from showing up, when no longer needed (or for Production sites that have Staging sites to manage configurations).
- Hides the ‘Pods’ menu that shows all pods content pages for any pod that does not have it’s own top-level menu item. Note: You can set access to individual Pods by capability using the Pods Roles component or using our supported user capabilities for Advanced Content Types.
- Hides the ‘Pods Admin’ menu for users of any role. Note: You can set access to the Pods admin menu by user level using the Pods Roles component or using our supported user capabilities for Pods Administration.
Advanced / Performance
These are advanced constants, using them may improve performance or enable advanced functionality depending on needs of a project.
- Disables all Pods components.
- Enables “Tableless Mode”. No additional database tables such as wp_podsrel will be created nor utilized. The wp_podsrel table is created on activation
- Disable including Pods media helper functions.
- Set to false to prevent get_post_meta( $id ) interaction with Pods for meta storage Pods.
- Enables strict mode, which results in global pagination disabled and global search disabled in pods() (unless manually set in $params); Disables $_SERVER access in pods_v and from special magic tags; Disables deprecated functionality; And pods( ‘pod_does_not_exist’ ) will return false instead of an object
- Disables Pods API caching, used to cache data for Pods, Fields, and other lookups Pods does often.
- Enables a performance tweak that rebuilds all of the config data needed for Pods directly after flushing Pods caches from Pods Admin > Settings > Clear Pods Caches. With this, on the next page load everything will already be generated and set in the cache. Useful for large configurations.
- Names for Pods or Pod Fields reserved for internal use can be used for new Pods or Pod Fields. Use with caution.
- Disables Sessions from starting when Pods is loaded. Sessions are used by Pods for securing usage of public forms visitors who are not logged in.
These are constants specifically related to the Pods Pages component.
- Disables the check that is run before a page loads to see if Pods Pages is being used.
- Disables output of the $pods->meta / $pods->meta_property data in header of a Pods Page (if they are set).
- Disables outputting the current Pods version in head of Pods Pages.
- Disables outputting Pods Pages body classes based on the current pod page.
- Disables checking for $pods->page_template to use for a Pods Page (if it’s set).
If you’re looking to make your site more secure, check out these constants to make things more tied down.
- Disables PHP eval(), and Pods will not allow PHP code added in the admin interface to be output. No PHP code will be output either, so source code will not be leaked. PHP eval() currently is in use by Pods Templates and Pods Pages (and the deprecated Pods Helpers) components.
- Disables the ability to upload any files via Pods.
- Allow users who are NOT logged in to upload files via Pods file fields. Use this with caution.
- Disables access to the file browser when uploading files via Pods file fields.
- Allow users who are NOT logged in to see the file browser via Pods file fields. Use this with caution.
- Disables Pods shortcodes.
- Allows shortcodes to evaluate special magic tags which appear like magic tags, but the values are mapped through pods_v(). Use this with caution.
- Allows shortcodes to be embedded from within Pods Shortcodes. This is a necessary step to allow shortcodes to be ran within the Pods Templates.
- Allows the
blog_idparameter in Pods Shortcodes to allow Blog Switching which allows you to run shortcodes against Pods defined in other network sites.
- Allows shortcodes to passing SQL directly. Enables usage of “orderby”, “where”, “having” , “groupby” and “select” arguments for Pods::find() $params. Use this with caution.
true– Any pod can be paginated
- Globally disables pagination from Pods class. Can be overridden in Pods::find() $params.
true– Any pod can be searched
- Globally disables search in Pods class. Can be overridden in Pods::find() $params.
See PODS_STRICT in the Advanced section above in relation to $_SERVER access in pods_v().
Changing these constants is not recommended; these are the minimum versions Pods is unit tested against and known to work with. If a version does not meet the minimum requirements, Pods will not be loaded and an admin warning notice will be displayed in the WP Admin area. The values defined in these constants are strings, not booleans.
- The minimum version of WordPress required.
- The minimum version of PHP required.
- The minimum version of MySQL required.
These constants cannot be overridden! They are defined by the plugin directly.
- The version number of the current version of Pods. On upgrade to next PODS_VERSION, may trigger a DB update (see below). Last known PODS_VERSION from an upgrade process is stored in the option pods_framework_version. Previous version installed, when last upgrade ran is stored in the option pods_framework_version_last.
- The version of the Pods database configuration. On upgrade to next PODS_VERSION, if the previous version is less than the DB version, it will trigger a database update. Last known PODS_DB_VERSION from an upgrade process is stored in the option pods_framework_db_version.
plugin_basename( __FILE__ )
- The slug for the plugin.
plugin_dir_path( __FILE__ )
- The directory path of the directory Pods is installed in.
plugin_dir_url( __FILE__ )
- The URL of the directory Pods is installed in.