The following features are deprecated or retired. Review details and recommendations to plan migrations.
Showing 1-10 of 20 deprecations
Page 1 of 2
This plugin has been moved into the dotCMS core as of 26.06.06-01. If you are on this or a more recent version, you may remove the plugin and continue using the functionality normally.
If you are on a prior version, dotCMS recommends upgrading. The plugin will continue to function, in the meantime.
dotCMS will be altering its default settings to disallow anonymous content access via API. As a result, dotCMS will always require an authenticated user for API content access.
Users currently allowing anonymous API access to content should create a front-end key for server-side use, and establish a pattern for what elements of the returns are permitted to be shared with anonymous users.
Content always respects content permissions; only content specified as anonymously accessible is available for reading without authentication.
Should a customer require anonymous API access, it remains possible to retain the prior permissive behavior, though this is not recommended. The DOT_CONTENT_APIS_ALLOW_ANONYMOUS environment variable can be used restore the old default. Possible values are as follows:
NONE | New default value; no anonymous API access. |
|---|---|
READ | Old default value; allows read-only anonymous access to content API endpoints. Not recommended. |
WRITE | Allows anonymous read OR write content behaviors. Doubly unrecommended, but may be useful in certain testing or development environments. |
A full inventory of affected endpoints is forthcoming.
We're changing this for reasons of data security. Because anonymous, unauthenticated API calls permit full access to every content property — including hidden and system properties — this may ultimately compromise more data than a user may wish. Making API calls require a level of authentication by default forces all content-access decisions to be intentional at the level of, e.g., a site or app front end.
Use a content type to create a form; use the workflow viewtool or workflow API to ingest each submission as a new contentlet of that content type.
See How to Build A Schema Driven Form in dotCMS for a tutorial.
Original legacy form functionalities, such as the FormTool, depended on Struts components, removed years ago — version 5.2.0, back in 2019.
The successor, the Form Builder, has likewise aged out; it renders out-of-date (sometimes nonstandard) tags that frequently fall short of WCAG or other standards, and custom fields like a captcha are not possible. Given more coherent alternative methods outlined above, we deemed this feature no longer worth updating.
Edit Mode Anywhere has been superseded by the Universal Visual Editor, which is easier to configure, easier to use, and more versatile. The UVE even boasts a still-expanding JavaScript SDK for modern framework integrations.
The UVE has been designed to be both simpler and more powerful than all previous page-editing tools, across both traditional and headless paradigms.
The Page Viewing Modes of yesterday have been superseded by the Universal Visual Editor, which unifies the traditional page-editing tools with the ability to perform in-context editing headlessly — likewise superseding Edit Mode Anywhere.
The UVE has been designed to be both simpler and more powerful than all previous page-editing tools, across both traditional and headless paradigms.
File system management can also be handled via the dotCMS Command-Line Interface, or dotCLI.
WebDAV is an outgoing technology that faces declining platform-level support — e.g., it has been deprecated on the Windows platform, where it is no longer enabled by default.
Please use the official dotCMS Command-Line Interface (dotCLI).
The legacy CLI was a series of Bash scripts, no longer maintained, with fewer options and less overall utility than the modern, comprehensive dotCLI.
We're planning to move the future-focused section of the Time Machine to the scope of individual pages, where it will be handled through our Universal Visual Editor. Time Machine snapshots of past versions of a site will be removed altogether; to preserve static snapshots of existing sites, we recommend using static push-publishing.
The Time Machine feature is both expensive and unwieldy to maintain as the product continues to grow. Its utilities and functions, however, can be retained and sustainably provisioned in the recommended manner (i.e., static push-publishing and UVE).
Customers should consider all DWR (Direct Web Remoting) endpoints (those that begin with dwr/*) and DotAjax endpoints (those that begin /DotAjaxDirector) as deprecated and should instead use the REST API equivalents. If there is not a REST equivalent, customers are suggested to create a custom plugin.
As of the first release of dotCMS 23.01, all usages and reliance on the repackaged jars in dotCMS — those that begin with dot-xxxxxx.jar and classes that start with com.dotcms.repackage.* — are considered deprecated.
Any OSGi plugin that relies on these classes should be recompiled using the un-repacked versions of these libraries. Or as another (not great) alternative, you may include the repackaged JAR in your OSGi plugin for use.
The only exception to this are the core dotCMS JARs that provide the base JSR-168 Portlet classes, such as com.dotcms.repackage.javax.portlet.Portlet.
