modxorg · Ibochkarev · Aug 19, 2026
diff --git a/en/building-sites/resources/custom-resources.md b/en/building-sites/resources/custom-resources.md
@@ -4,7 +4,7 @@ _old_id: "79"
 _old_uri: "2.x/developing-in-modx/advanced-development/custom-resource-classes"
 ---
 
-Custom Resource Classes are available in MODX 2.2 and later only.
+Custom Resource Classes (CRC) shipped in MODX 2.2. They still work in 3.x. Create and update processors moved with the rest of the core processors. See [Processors on MODX 3](#processors-on-modx-3) below.
 
 ## What is a Custom Resource Class?
 
@@ -31,6 +31,21 @@ 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.
 
+## Processors on MODX 3
+
+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`. Your subclass must extend the core Resource processor.
+
+In 2.x those core classes lived at `core/model/modx/processors/resource/create.class.php` (`modResourceCreateProcessor`) and `update.class.php` (`modResourceUpdateProcessor`). Those files are gone. A `require_once` of those paths fails.
+
+| 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. `runProcessor('resource/create')` still works.
+
+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/extending-modx/custom-resources/index.md b/en/extending-modx/custom-resources/index.md
@@ -11,6 +11,8 @@ _old_uri: "2.x/developing-in-modx/advanced-development/custom-resource-classes/c
 - [Part III: Customizing the Controllers](extending-modx/custom-resources/step-3-controllers "Creating a Resource Class - Step 3")
 - [Part IV: Customizing the Processors](extending-modx/custom-resources/step-4-processors "Creating a Resource Class - Step 4")
 
+On MODX 3, skip the 2.x `require_once` paths under `core/model/modx/processors/resource/`. Extend `\MODX\Revolution\Processors\Resource\Create` and `Update`. Details are in [Step 4](extending-modx/custom-resources/step-4-processors) and on [Custom Resource Classes](building-sites/resources/custom-resources).
+
  We're going to create a sample Custom Resource Class (CRC) that does a very simple task - it outputs a copyright on the bottom of a page with the current date. Yes, something this trivial should be done by placing a [Snippet](extending-modx/snippets "Snippets") in your [Template](building-sites/elements/templates "Templates"), but we want to illustrate the concept of CRCs using something very, very simple, so bear with us. :)
 
  This page deals with Part I - creating the actual Custom Resource Class itself. [Part II](extending-modx/custom-resources/step-2-overriding-methods "Creating a Resource Class - Step 2") will actually implement the behavior of appending the copyright. [Part III](extending-modx/custom-resources/step-3-controllers "Creating a Resource Class - Step 3") will deal with overriding the Controllers, and [Part IV](extending-modx/custom-resources/step-4-processors "Creating a Resource Class - Step 4") will deal with overriding the Processors. The files used in this tutorial can be found on GitHub for reference: <https://github.com/modxcms/CopyrightedResource>

diff --git a/en/extending-modx/custom-resources/step-4-processors.md b/en/extending-modx/custom-resources/step-4-processors.md
@@ -13,17 +13,45 @@ _old_uri: "2.x/developing-in-modx/advanced-development/custom-resource-classes/c
 
  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,6 +60,8 @@ class CopyrightedResourceUpdateProcessor extends modResourceUpdateProcessor {
 }
 ```
 
+ 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

diff --git a/en/getting-started/maintenance/upgrading.md b/en/getting-started/maintenance/upgrading.md
@@ -6,7 +6,7 @@ _old_uri: "2.x/administering-your-site/upgrading-modx"
 
 This document covers the standard process for upgrading an existing MODX Revolution installation (typically within the 3.x line, or from a recent 2.x site after you have planned for 3.0 changes).
 
-- Upgrading **from 2.x to 3.0+**: read [Upgrading from 2.x to 3.0](getting-started/upgrading-to-3.0) first — namespaces, processors, the fixed core path, and PHP requirements all change.
+- Upgrading **from 2.x to 3.0+**: Setup only accepts **2.6.0 or later**. Read [Upgrading from 2.x to 3.0](getting-started/upgrading-to-3.0) first. Namespaces, processors, the fixed core path, and PHP requirements all change.
 - Confirm your host meets current [Server Requirements](getting-started/server-requirements). **MODX 3.2+ requires PHP 8.1 or higher** (3.0 originally allowed PHP 7.2+).
 - Upgrading from Evolution (1.x) is not officially supported; historical notes are [here](getting-started/maintenance/upgrading/evolution).
 
@@ -71,7 +71,7 @@ It's a good idea to clear your browser cache after upgrading. Browsers often cac
 
 For changes relating to specific versions, please see the following pages:
 
-- [Upgrading from 2.x to 3.0](getting-started/upgrading-to-3.0) (required reading for any 2.x → 3.x move; includes the PHP 7.2 → **8.1 in 3.2** requirement notes)
+- [Upgrading from 2.x to 3.0](getting-started/upgrading-to-3.0) (required reading for any 2.6+ to 3.x move; includes the PHP 7.2 to **8.1 in 3.2** requirement notes)
 - [Upgrading to 2.8.2 / 2.8.3](getting-started/maintenance/upgrading/2.8.2) (security-related behavioural changes still relevant before jumping to 3.x)
 - Historical 2.x notes: [2.3](getting-started/maintenance/upgrading/2.3), [2.2](getting-started/maintenance/upgrading/2.2), [2.1](getting-started/maintenance/upgrading/2.1), [pre-2.0.5](getting-started/maintenance/upgrading/2.0.5), [2.0.0-rc2](getting-started/maintenance/upgrading/2.0.0-rc2)
 

diff --git a/en/getting-started/upgrading-to-3.0/index.md b/en/getting-started/upgrading-to-3.0/index.md
@@ -11,16 +11,21 @@ This document details the changes made between 2.x and 3.0 that may affect upgra
 
 ## Upgrade to 3.0
 
-In general, you can follow the [standard upgrading process](getting-started/maintenance/upgrading) when upgrading to 3.0. It's recommended to first upgrade to the latest 2.8 release for some time, which will log deprecated functionality your site may depend on to the MODX log.
+Setup only upgrades from **MODX 2.6.0 or later**. On 2.5 or older, upgrade to 2.6 first. Setup stops with a failure if the current version is below 2.6.0.
+
+After you are on 2.6+, follow the [standard upgrading process](getting-started/maintenance/upgrading). Then spend time on the latest **2.8** release before 3.0. 2.8 writes deprecated API use to the MODX log. Fix extras and custom code there, then jump to 3.0.
 
 After upgrading the core and upgrading your extras, you may encounter some breaking changes that need to be addressed in extras or custom code.
 
+- ⚠️ Important: upgrades from MODX older than **2.6.0** are not supported
 - ⚠️ Important: [the core folder must now always be located in the project root, and can no longer be renamed](getting-started/upgrading-to-3.0/core-folder)
 - ⚠️ Important: [MODX 3.0 required PHP 7.2; current 3.x (3.2+) requires PHP 8.1+](getting-started/upgrading-to-3.0/requirements)
 - ⚠️ Important: [sqlsrv support has been removed](getting-started/upgrading-to-3.0/sqlsrv)
 - [A list of breaking changes can be found here](getting-started/upgrading-to-3.0/breaking-changes), most notably [many core classes have been moved and renamed](getting-started/upgrading-to-3.0/class-names)
 - [The manager language is now dynamic](getting-started/upgrading-to-3.0/manager-language)
 - [Various system settings have been removed or changed](getting-started/upgrading-to-3.0/system-settings)
+- [Notable manager UI changes in 3.0](getting-started/upgrading-to-3.0/manager-ui)
+- Custom resource types that extend core Resource processors: [Processors](getting-started/upgrading-to-3.0/processors) and [Custom Resource Classes](building-sites/resources/custom-resources)
 
 ## Other notable changes and improvements
 

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,36 @@
+---
+title: Notable manager UI in 3.0
+---
+
+The 3.0 manager is still ExtJS. The skin, spacing, and a set of forms changed. This page records those UI notes. Feature how-tos (login backgrounds, language switching, dashboards) live on their own pages.
+
+## Already documented elsewhere
+
+- Redesigned [manager login](building-sites/client-proofing/manager-login), including custom backgrounds. [#13773](https://github.com/modxcms/revolution/pull/13773)
+- Redesigned installer. [#14507](https://github.com/modxcms/revolution/pull/14507)
+- [On-the-fly manager language](getting-started/upgrading-to-3.0/manager-language). [#14046](https://github.com/modxcms/revolution/pull/14046)
+- Media browser and manager layout on smaller screens. [#14700](https://github.com/modxcms/revolution/pull/14700), [#14735](https://github.com/modxcms/revolution/pull/14735)
+- Chrome in-page translation is blocked in the manager. [#14414](https://github.com/modxcms/revolution/pull/14414)
+- Gravatar is off on new installs. See [system settings in 3.0](getting-started/upgrading-to-3.0/system-settings). [#14215](https://github.com/modxcms/revolution/pull/14215)
+
+## Tooltips
+
+Form fields with a description show ExtJS QuickTips on the field and on its label.
+
+- `manager_tooltip_enable` (Yes/No, default Yes) turns those tooltips on or off.
+- `manager_tooltip_delay` (number, default 2300) is milliseconds before a tooltip hides. The manager passes it to QuickTips as `dismissDelay`.
+
+Media Browser image previews use `modx_browser_tree_hide_tooltips`, not these two settings. [#14535](https://github.com/modxcms/revolution/pull/14535)
+
+## 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: a success notice after a table operation. [#14525](https://github.com/modxcms/revolution/pull/14525)
+- The top search bar (uberbar) trims spaces at both ends of the query. [#14523](https://github.com/modxcms/revolution/pull/14523)
+- 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 [Custom Resource Classes](building-sites/resources/custom-resources) and [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/nl/aan-de-slag/upgraden-naar-3.0.md b/nl/aan-de-slag/upgraden-naar-3.0.md
@@ -10,16 +10,21 @@ Dit document beschrijft de belangrijkste wijzigingen tussen 2.x en 3.0 die upgra
 
 ## Upgraden naar 3.0
 
-In het algemeen volg je het [standaard upgradeproces](aan-de-slag/upgraden). Het is verstandig om eerst een tijd op de nieuwste 2.8-release te draaien: die logt deprecated functionaliteit waar je site van afhankelijk kan zijn naar het MODX-log.
+Setup upgrade alleen vanaf **MODX 2.6.0 of nieuwer**. Zit je op 2.5 of ouder, ga dan eerst naar 2.6. Setup stopt met een fout als de huidige versie lager is dan 2.6.0.
+
+Ben je op 2.6+, volg dan het [standaard upgradeproces](aan-de-slag/upgraden). Draai zo mogelijk eerst de nieuwste **2.8**: die logt deprecated API-gebruik naar het MODX-log, zodat je extras en custom code kunt bijwerken vóór 3.0.
 
 Na het upgraden van de core en je extras kun je breaking changes tegenkomen in extras of custom code.
 
+- Belangrijk: upgrades vanaf MODX ouder dan **2.6.0** worden niet ondersteund
 - Belangrijk: [de core-map moet in de projectroot staan en kan niet meer hernoemd worden](#core-map)
 - Belangrijk: [MODX 3.0 vroeg PHP 7.2; huidige 3.x (3.2+) vraagt PHP 8.1+](#serververeisten)
 - Belangrijk: [sqlsrv-ondersteuning is verwijderd](#sqlsrv)
 - [Breaking changes](#belangrijkste-breaking-changes), vooral [hernoemde en verplaatste core classes](/current/en/getting-started/upgrading-to-3.0/class-names)
 - [Manager-taal is dynamisch (EN)](/current/en/getting-started/upgrading-to-3.0/manager-language)
 - [Systeeminstellingen gewijzigd of verwijderd (EN)](/current/en/getting-started/upgrading-to-3.0/system-settings)
+- [Opvallende manager-UI in 3.0 (EN)](/current/en/getting-started/upgrading-to-3.0/manager-ui)
+- Custom resource types die core Resource-processors uitbreiden: [Processors (EN)](/current/en/getting-started/upgrading-to-3.0/processors)
 
 Uitgebreide details per onderwerp staan in de [Engelstalige upgrade-sectie](/current/en/getting-started/upgrading-to-3.0).
 
@@ -101,7 +106,7 @@ Ondersteuning voor sqlsrv-databases is verwijderd. Migreer eerst naar MySQL: [sq
 ## Aanbevolen volgorde
 
 1. Backup van bestanden en database
-2. Upgrade naar nieuwste 2.8 en check de MODX-logs op deprecation-warnings
+2. Zit je onder 2.6, upgrade eerst naar 2.6. Daarna naar de nieuwste 2.8 en check de MODX-logs op deprecation-warnings
 3. Upgrade extras die 3.x ondersteunen; check [SiteDash](https://sitedash.app/extras)
 4. Zorg voor PHP 8.1+ (voor huidige 3.x) en MySQL/MariaDB volgens de [server vereisten](aan-de-slag/server-vereisten)
 5. Zet een custom core terug naar `/core/` indien van toepassing

diff --git a/nl/aan-de-slag/upgraden.md b/nl/aan-de-slag/upgraden.md
@@ -6,7 +6,7 @@ translation: "getting-started/maintenance/upgrading"
 
 Dit beschrijft het standaardproces om een bestaande MODX Revolution-installatie te upgraden (meestal binnen de 3.x-lijn, of vanaf een recente 2.x-site nadat je de 3.0-wijzigingen hebt gepland).
 
-- Upgraden **van 2.x naar 3.0+**: lees eerst [Upgraden van 2.x naar 3.0](aan-de-slag/upgraden-naar-3.0). Namespaces, processors, het vaste core-pad en PHP-eisen veranderen.
+- Upgraden **van 2.x naar 3.0+**: setup accepteert alleen **2.6.0 of nieuwer**. Lees eerst [Upgraden van 2.x naar 3.0](aan-de-slag/upgraden-naar-3.0). Namespaces, processors, het vaste core-pad en PHP-eisen veranderen.
 - Controleer of je host voldoet aan de huidige [server vereisten](aan-de-slag/server-vereisten). **MODX 3.2+ vereist PHP 8.1 of hoger** (3.0 stond oorspronkelijk PHP 7.2+ toe).
 - Upgraden vanaf Evolution (1.x) wordt niet officieel ondersteund; historische notes: [Evolution (EN)](/current/en/getting-started/maintenance/upgrading/evolution).