modxorg · Ibochkarev · Aug 19, 2026
diff --git a/...ing-sites/client-proofing/security/policies/permissions/administrator-policy.md b/...ing-sites/client-proofing/security/policies/permissions/administrator-policy.md
@@ -70,6 +70,7 @@ This policy is packaged into MODX and is given to users on the 'mgr' context who
 | new\_chunk                  | To create a new [Chunk](building-sites/elements/chunks "Chunks").                                                                |
 | new\_context                | To create a new [Context](building-sites/contexts "Contexts").                                                                   |
 | new\_document               | To create a new [Resources](building-sites/resources "Resources").                                                               |
+| new\_document\_in\_root     | To create a [Resource](building-sites/resources "Resources") at the site root. Replaces the removed `udperms_allowroot` setting. |
 | new\_plugin                 | To create a new [Plugin](extending-modx/plugins "Plugins").                                                                      |
 | new\_role                   | To create a new [Role](building-sites/client-proofing/security/roles "Roles").                                                   |
 | new\_snippet                | To create a new [Snippet](extending-modx/snippets "Snippets").                                                                   |

diff --git a/en/building-sites/resources/custom-resources.md b/en/building-sites/resources/custom-resources.md
@@ -31,6 +31,8 @@ CRCs look like normal Resources in the tree. The CRC class can also hook into th
 
 CRCs can have their Controllers, Processors and main rendering functionality extended and overridden. You can, for example, automatically append text to the output of any CRC's content by overriding the process() or getContent() method of the CRC in the PHP class. Any method in the modResource class is available to be overridden when using CRCs.
 
+On MODX 3, a CRC create or update processor must extend `\MODX\Revolution\Processors\Resource\Create` or `Update`. The old `modResourceCreateProcessor` and `modResourceUpdateProcessor` names are aliases until 3.3. The 2.x processor files under `core/model/modx/processors/resource/` are gone. See [Step 4: Customizing the Processors](extending-modx/custom-resources/step-4-processors) and [Processors in the 3.0 upgrade notes](getting-started/upgrading-to-3.0/processors).
+
 ## Creating a CRC
 
 Please follow the tutorial on [Creating a Resource Class](extending-modx/custom-resources "Creating a Resource Class").
diff --git a/en/building-sites/settings/index.md b/en/building-sites/settings/index.md
diff --git a/en/building-sites/settings/manager_tooltip_delay.md b/en/building-sites/settings/manager_tooltip_delay.md
@@ -0,0 +1,13 @@
+---
+title: "manager_tooltip_delay"
+description: "Milliseconds before a manager field tooltip hides"
+---
+
+**Name**: Delay Time for Manager Tooltips  
+**Type**: Number  
+**Default**: 2300  
+**Available In**: Revolution 3.0+
+
+Milliseconds before an enabled field tooltip hides. The manager passes this value to ExtJS QuickTips as `dismissDelay`.
+
+Has no effect when [manager_tooltip_enable](building-sites/settings/manager_tooltip_enable) is No.
diff --git a/en/building-sites/settings/manager_tooltip_enable.md b/en/building-sites/settings/manager_tooltip_enable.md
@@ -0,0 +1,15 @@
+---
+title: "manager_tooltip_enable"
+description: "Show field description tooltips in the manager"
+---
+
+**Name**: Enable Manager Tooltips  
+**Type**: Yes/No  
+**Default**: Yes  
+**Available In**: Revolution 3.0+
+
+When Yes, the manager shows ExtJS QuickTips on form fields that have a description. The same text appears on the field and on its label.
+
+Set this to No to hide those tooltips. This setting does not control Media Browser image preview tooltips. Those use [modx_browser_tree_hide_tooltips](building-sites/settings/modx_browser_tree_hide_tooltips).
+
+See [manager_tooltip_delay](building-sites/settings/manager_tooltip_delay) for how long an enabled tooltip stays on screen. These settings are listed with other 3.0 manager UI notes on [Manager UI in 3.0](getting-started/upgrading-to-3.0/manager-ui).
diff --git a/en/building-sites/settings/udperms_allowroot.md b/en/building-sites/settings/udperms_allowroot.md
@@ -4,12 +4,6 @@ _old_id: "317"
 _old_uri: "2.x/administering-your-site/settings/system-settings/udperms_allowroot"
 ---
 
-## udperms\_allowroot
+The `udperms_allowroot` setting was removed in MODX 3.0. Revolution already ignored it. Root resource creation is controlled by the `new_document_in_root` [permission](building-sites/client-proofing/security/policies/permissions/administrator-policy) on the Administrator Policy (granted by default).
 
-**Name**: Allow Root Resource Creation
-**Type**: Yes/No
-**Default**: No
-
-If true, allows users to create new resources in the root of the site.
-
-This setting is **deprecated** in MODX Revolution. It has been replaced by the 'new\_document\_in\_root' [Permission](building-sites/client-proofing/security/policies/permissions "Permissions") in the Administrator Policy (the permission is granted by default).
+Grant `new_document_in_root` to let users create resources at the site root. Deny it to block create, duplicate, and move into the root.
diff --git a/en/building-sites/settings/webpwdreminder_message.md b/en/building-sites/settings/webpwdreminder_message.md
@@ -0,0 +1,8 @@
+---
+title: "webpwdreminder_message"
+description: "Removed in MODX 3.0. Unused web-user password reminder email template"
+---
+
+The `webpwdreminder_message` setting was removed in MODX 3.0. In 2.x it stored the HTML email sent when a web user requested a password reset. The core no longer used that template.
+
+Manager password reset uses [forgot_login_email](building-sites/settings/forgot_login_email). Front-end reset is handled by extras such as Login.
diff --git a/en/extending-modx/custom-resources/step-4-processors.md b/en/extending-modx/custom-resources/step-4-processors.md
@@ -4,26 +4,54 @@ _old_id: "73"
 _old_uri: "2.x/developing-in-modx/advanced-development/custom-resource-classes/creating-a-resource-class/creating-a-resource-class-step-4"
 ---
 
- This tutorial is part of a Series:
+This tutorial is part of a Series:
 
 - [Part I: Creating a Custom Resource Class](extending-modx/custom-resources "Creating a Resource Class")
 - [Part II: Handling our CRC Behavior](extending-modx/custom-resources/step-2-overriding-methods "Creating a Resource Class - Step 2")
 - [Part III: Customizing the Controllers](extending-modx/custom-resources/step-3-controllers "Creating a Resource Class - Step 3")
 - Part IV: Customizing the Processors
 
- This is a bit of bonus material to help identify some of the things you can do by extending the default processors.
+This is a bit of bonus material to help identify some of the things you can do by extending the default processors.
+
+## MODX 3.x class names
+
+When you create or update a CRC, `MODX\Revolution\Processors\Resource\Create::getInstance()` looks for `{class_key}CreateProcessor`. The update processor looks for `{class_key}UpdateProcessor`. Those classes must extend the core resource processors.
+
+The 2.x files `core/model/modx/processors/resource/create.class.php` and `update.class.php` are gone. Do not `require_once` those paths.
+
+| Old class | New class |
+| --- | --- |
+| `modResourceCreateProcessor` | `\MODX\Revolution\Processors\Resource\Create` |
+| `modResourceUpdateProcessor` | `\MODX\Revolution\Processors\Resource\Update` |
+
+`core/include/deprecated.php` aliases the old names until 3.3. For 3.0+ only, extend the namespaced classes:
+
+``` php
+use MODX\Revolution\Processors\Resource\Create;
+use MODX\Revolution\Processors\Resource\Update;
+
+class CopyrightedResourceCreateProcessor extends Create
+{
+}
+
+class CopyrightedResourceUpdateProcessor extends Update
+{
+}
+```
+
+See [Processors in the 3.0 upgrade notes](getting-started/upgrading-to-3.0/processors).
 
 ## Extending the Processors for our CRC
 
- Extending the Processors for our CopyrightedResource is fairly simple. Load up your **copyrightedresource.class.php** file that contains your main class, and at the top, put this:
+ Extending the Processors for our CopyrightedResource is fairly simple. On MODX 2.x, load up your **copyrightedresource.class.php** file that contains your main class, and at the top, put this:
 
 ``` php
 require_once MODX_CORE_PATH.'model/modx/modprocessor.class.php';
 require_once MODX_CORE_PATH.'model/modx/processors/resource/create.class.php';
 require_once MODX_CORE_PATH.'model/modx/processors/resource/update.class.php';
 ```
 
- This tells MODX to load some base classes that we'll need – yes, we're sort of double-dipping here. Because our main class file is on MODX's radar and will be included when MODX loads, we just can require more files from there. At the bottom of the same file, after your CopyrightedResource class, put this:
+ This tells MODX to load some base classes that we'll need. Because our main class file is on MODX's radar and will be included when MODX loads, we just can require more files from there. At the bottom of the same file, after your CopyrightedResource class, put this:
 
 ``` php
 class CopyrightedResourceCreateProcessor extends modResourceCreateProcessor {
@@ -32,7 +60,9 @@ class CopyrightedResourceUpdateProcessor extends modResourceUpdateProcessor {
 }
 ```
 
- Now we've overridden the processors for our class; MODX will automatically use these classes as the processor class when creating or updating our CRC. We can then override methods to provide custom functionality for our CopyrightedResource class. For example, here is a stub for our CopyrightedResource class and the Update processor that shows some methods that you could override:
+On 3.x skip those `require_once` lines and extend `\MODX\Revolution\Processors\Resource\Create` and `Update` instead, as shown above.
+
+Now we've overridden the processors for our class; MODX will automatically use these classes as the processor class when creating or updating our CRC. We can then override methods to provide custom functionality for our CopyrightedResource class. For example, here is a stub for our CopyrightedResource class and the Update processor that shows some methods that you could override:
 
 ``` php
 class CopyrightedResourceUpdateProcessor extends modResourceUpdateProcessor {
@@ -71,13 +101,13 @@ class CopyrightedResourceUpdateProcessor extends modResourceUpdateProcessor {
 }
 ```
 
- These are just trivial examples, but hopefully you get the idea. If you've been paying close attention to our examples on these pages, you may have noticed that we set some properties in the **CopyrightedResource** class (class\_key), and we set others in **CopyrightedResourceUpdateProcessor** (cacheable, isfolder). This may leave you confused as to where you should modify a behavior – in the resource child class? In the controller class? or in the processor?
+These are just trivial examples, but hopefully you get the idea. If you've been paying close attention to our examples on these pages, you may have noticed that we set some properties in the **CopyrightedResource** class (class\_key), and we set others in **CopyrightedResourceUpdateProcessor** (cacheable, isfolder). This may leave you confused as to where you should modify a behavior – in the resource child class? In the controller class? or in the processor?
 
- If the attribute is something that can be controlled by the GUI, then you'll have to do some customizations in the processors.
+If the attribute is something that can be controlled by the GUI, then you'll have to do some customizations in the processors.
 
 ## Extra Attributes
 
- There are some attributes that are not in the **`modx_site_content`** table. See the comments in the **modresource.class.php** file for a list of attributes. You can set them in your resource class via the set method, e.g.:
+There are some attributes that are not in the **`modx_site_content`** table. See the comments in the **modresource.class.php** file for a list of attributes. You can set them in your resource class via the set method, e.g.:
 
 ``` php
 $this->set('show_in_tree',false);
@@ -88,4 +118,4 @@ You can customize the icon used in the MODX resource by creating a System Settin
 
 ## Conclusion
 
- And that's about it! There's obviously tons of possibilities with CRCs, and you can really go nuts on the customization that you can apply to them and their processing and rendering logic. Have fun!
+And that's about it! There's obviously tons of possibilities with CRCs, and you can really go nuts on the customization that you can apply to them and their processing and rendering logic. Have fun!
diff --git a/en/getting-started/upgrading-to-3.0/manager-ui.md b/en/getting-started/upgrading-to-3.0/manager-ui.md
@@ -0,0 +1,29 @@
+---
+title: Manager UI in 3.0
+---
+
+The manager in 3.0 is the same ExtJS app with a new skin and a set of layout tweaks. This page lists the leftover interface changes from the 3.0 cycle that do not have their own how-to.
+
+Installer and login redesigns are covered on [Upgrading to 3.0](getting-started/upgrading-to-3.0) and [Manager login](building-sites/client-proofing/manager-login). Language switching is on [Manager language](getting-started/upgrading-to-3.0/manager-language).
+
+## Tooltips
+
+Field description tooltips can be turned off, and you can change how long they stay on screen:
+
+- [manager_tooltip_enable](building-sites/settings/manager_tooltip_enable) (default Yes)
+- [manager_tooltip_delay](building-sites/settings/manager_tooltip_delay) (default 2300 ms, ExtJS `dismissDelay`)
+
+Media Browser image previews use [modx_browser_tree_hide_tooltips](building-sites/settings/modx_browser_tree_hide_tooltips), not these settings.
+
+## Profile and resource forms
+
+- User profile screens share one layout. [#14731](https://github.com/modxcms/revolution/pull/14731), [#14420](https://github.com/modxcms/revolution/pull/14420)
+- Resource settings and the Quick Update Resource window use the same field layout. [#14726](https://github.com/modxcms/revolution/pull/14726)
+- Template and TV forms put the TV tab before Settings. Resource editing does the same for TVs. [#14251](https://github.com/modxcms/revolution/pull/14251), [#14250](https://github.com/modxcms/revolution/pull/14250)
+- Grid "New" buttons follow one pattern. [#14312](https://github.com/modxcms/revolution/pull/14312)
+
+## Other manager behaviour
+
+- System Info → Database tables shows a success notice after a table operation. [#14525](https://github.com/modxcms/revolution/pull/14525)
+- The top search bar (uberbar) trims leading and trailing spaces before it searches. [#14523](https://github.com/modxcms/revolution/pull/14523)
+- The manager CSS starts from normalize.css. [#14369](https://github.com/modxcms/revolution/pull/14369)
diff --git a/en/getting-started/upgrading-to-3.0/processors.md b/en/getting-started/upgrading-to-3.0/processors.md
@@ -37,6 +37,21 @@ To help ease with the transition to 3.0, the old class names are automatically m
 
 Any call to a core processor will need to be reviewed. The old action names in [modX::runProcessor](extending-modx/modx-class/reference/modx.runprocessor) (e.g. `resource/create`) are still supported, but it is possible that the internal logic of some processors has changed.
 
+## Custom resource types (CRC)
+
+If a custom resource class defines `{ClassKey}CreateProcessor` or `{ClassKey}UpdateProcessor`, the core resource processors instantiate that class instead of themselves. Custom resource types that extend those processors must follow the 3.x class names.
+
+In 2.x the core classes lived at `core/model/modx/processors/resource/create.class.php` (`modResourceCreateProcessor`) and `update.class.php` (`modResourceUpdateProcessor`). Those files are gone.
+
+| Old class                       | New class                                       |
+| ------------------------------- | ----------------------------------------------- |
+| `\modResourceCreateProcessor`   | `\MODX\Revolution\Processors\Resource\Create`   |
+| `\modResourceUpdateProcessor`   | `\MODX\Revolution\Processors\Resource\Update`   |
+
+`core/include/deprecated.php` aliases the old names until 3.3. A `require_once` of the 2.x paths fails.
+
+See [Step 4: Customizing the Processors](extending-modx/custom-resources/step-4-processors).
+
 ## Flat-file processors no longer supported
 
 Support for so-called flat-file processors (which end in `.php` rather than `.class.php` and don't use a processor class) has been removed.

diff --git a/en/getting-started/upgrading-to-3.0/system-settings.md b/en/getting-started/upgrading-to-3.0/system-settings.md
@@ -12,6 +12,7 @@ MODX 3.0 cleaned up a significant number of old system settings and changed the
 - `manager_language` [#13786](https://github.com/modxcms/revolution/pull/13786), replaced by automatic language detection and on-the-fly switching in the manager [#14046](https://github.com/modxcms/revolution/pull/14046). [Learn more about the manager language in 3.0](getting-started/maintenance/upgrading/3.0/manager-language)
 - `resolve_hostnames` and `server_protocol` have been removed [#14877](https://github.com/modxcms/revolution/pull/14877). Deprecated settings from MODX Evolution.
 - `upload_flash`, set `upload_files` or `upload_images` or the `allowedFileTypes` on the media source instead. [#14252](https://github.com/modxcms/revolution/pull/14252)
+- `udperms_allowroot` and `webpwdreminder_message` [#14841](https://github.com/modxcms/revolution/pull/14841). Root resource creation uses the `new_document_in_root` permission. `webpwdreminder_message` was an unused web-user password email template. See [udperms_allowroot](building-sites/settings/udperms_allowroot) and [webpwdreminder_message](building-sites/settings/webpwdreminder_message).
 - `cache_action_map` as the action map has been removed completely now that modAction is officially gone [#14927](https://github.com/modxcms/revolution/pull/14927)
 
 ## Changed default values

diff --git a/...ing-sites/client-proofing/security/policies/permissions/administrator-policy.md b/...ing-sites/client-proofing/security/policies/permissions/administrator-policy.md
@@ -69,6 +69,7 @@ translation: "building-sites/client-proofing/security/policies/permissions/admin
 | new_chunk                 | Создать новый [чанк](building-sites/elements/chunks "Куски") .                                                                                                                                              |
 | new_context               | Создать новый [контекст](building-sites/contexts "Контексты") .                                                                                                                                             |
 | new_document              | Для создания новых [ресурсов](building-sites/resources "Ресурсы") .                                                                                                                                         |
+| new_document_in_root      | Создавать [ресурс](building-sites/resources "Ресурсы") в корне сайта. Заменяет удалённую настройку `udperms_allowroot`.                                                                                      |
 | new_plugin                | Создать новый [плагин](extending-modx/plugins "Плагины") .                                                                                                                                                  |
 | new_role                  | Создать новую [роль](building-sites/client-proofing/security/roles "Роли") .                                                                                                                                |
 | new_snippet               | Создать новый [сниппет](extending-modx/snippets "обрывки") .                                                                                                                                                |