docs(building-sites/client-proofing): fact-check pass, en/ru sync by Ibochkarev · Pull Request #672 · modxorg/Docs

Ibochkarev · 2026-10-20T13:37:57Z

Description

Fact-check of en/building-sites/client-proofing against MODX Revolution 3.x at 313aabf8478ac2770c1090f42acdf34022291712 (22 Oct 2026). The Russian pages carry the same facts. The section covers the manager theme, dashboards, form customization, and security.

Themes. manager_theme holds the name of a directory inside manager/templates/, and the combo box cannot be typed by hand. When the installer upgrades a site from Evolution, setup/includes/upgrade.install.php sets manager_theme back to default. An update inside MODX 3 leaves the setting. A theme has to carry images/modx-icon-color.svg, images/modx-logo-color.svg, images/login/default-background.jpg and email/default.tpl. The login stylesheet is not themed: login.tpl links the default theme by a fixed path.
Dashboards. A widget comes in seven sizes and four types, including Inline PHP. The menu path, the button labels, and the lexicon key in the example are the ones in MODX 3. The name of the Default dashboard cannot be changed in the form. The description can. Default still cannot be deleted.
Form customization. The rules are derived from the three grids of a set and are rebuilt on every save. The pages list the ten kinds of rules, the order they are applied in, the fields and regions, the three actions of a set, and the groups of the policy templates.
Security. Authority is unique. Super User uses 0 and Member uses 9999. A logged-out user has id 0 and the username anonymous. The group tree shows (anonymous). The Russian tree shows (аноним). The salt column is filled. The shipped hasher modNative does not use it. A user setting overrides a user group setting, which overrides a context setting, which overrides the system setting. The Settings tab is absent while you create a user. Only a sudo user sees it.
Password reset. After an MD5 reset, the next password change keeps hashing with MODX\Revolution\Hashing\modMD5. Set hash_class to MODX\Revolution\Hashing\modNative and save a new password in the manager to return to the shipped hasher. The API example sets that password and nothing else.
Login page. Set the background from OnManagerLoginFormRender. OnManagerLoginFormPrerender places its output before the form. The page takes its language from the request, then the session, then the browser, then en. manager_language is removed on upgrade.
Russian manager labels. The Russian pages use Админ, Контроль доступа, Группы пользователей & Пользователи, Редактировать группу пользователя, Контексты, Добавить доступ к контексту, Перезагрузить права доступа, Завершить все сеансы, Добавить виджет, Виджеты, Настройка форм, and Управление словарями.

Callouts in the section use GitHub alerts (> [!WARNING]), which the site renders.

Affected versions

3.x

Relevant issues

Not checked

Spanish and Dutch have no pages in this section. Left as written: the schema comment about removing sessionid, the DailyPhoto extra, addOne and getObjectGraph, and the claim that an element-category ACL also covers the fields of a resource.

Mark-H · 2026-10-20T22:13:47Z

+As a site administrator you should not encourage your users to choose insecure passwords. Passwordless login moves the risk of a weak password away from your MODX installation, but of course needs a secure e-mail account for your users. The traditional username and password login has the same requirement, because it also offers self-service password resets by e-mail.

-Additionally, if passwordless login is enabled, no passwords are stored any more in the MODX database. Then there is no more theoretical risk of passwords being stolen by a database breach (regardless of any encryption).
+The password of the user stays in the database all the same. Every login by a link writes the hash of a temporary password into the field `password` of the user. The gain is that the user has no password to choose, to remember or to reuse, not that the password is gone.


this is kinda confusing

The two sentences were sitting on top of each other. One said the password stays in the database. The next said every link writes a new hash into password.

They are separate sections now. Benefits keeps the part about having nothing to choose, remember, or reuse. The Password Is Replaced says what the handler does: it writes a generated password, only the hash is stored, and the password the user chose stops working after the first link.

Mark-H · 2026-10-20T22:19:11Z

 ## Still can't get it to work?

-Make sure you followed everything step by step and that you flushed permissions properly. If everything seems to be alright, check again and then go to the Forums to ask for help. If you think the tutorial is misleading or inaccurate, please visit the forum topic (linked below) and post about what is incorrect so it can be fixed.
+Make sure you followed everything step by step and that you flushed permissions properly. If everything seems to be alright, check again and then go to the Forums to ask for help. If you think the tutorial is misleading or inaccurate, please visit the [forum topic discussing this tutorial](https://forums.modx.com/index.php/topic,51259.0.html) and post about what is incorrect so it can be fixed.


broken link, might as well take it out

The old forum topic is gone, so that URL is out. The sentence now points at https://community.modx.com. The Russian page does the same.

Mark-H · 2026-10-20T22:22:38Z

+It is not uncommon for a User account to become inaccessible because of a lost or forgotten password. In many cases, this can easily be resolved by having the user use the Forgot Password link on the login form. In some cases you need to reset the password directly.

-### Resetting Password in MODX 2.1+
+**The password cannot be written into the database by hand**


Kinda incorrect, it's not possible with modNative, but can be done with the modMD5 approach and the UPDATE line you've removed.

The lead treated every hasher the same. A database statement still cannot produce the modNative hash. It can write a password once hash_class is MODX\Revolution\Hashing\modMD5.

The lead now says that, and the UPDATE with MD5() is in the next paragraph. The Russian page matches.

Mark-H · 2026-10-20T22:23:58Z

It's taken me an hour to just read through half of this PR.. will follow up on the other half later.

Three remarks. **The passwordless login page was confusing about the password.** It said that the password of the user "stays in the database all the same" and that every login by a link writes the hash of a temporary password into the field `password` — two statements that read as a contradiction. What the code does (`manager/controllers/default/security/login.class.php`, `handleMagicLoginLink()`): the handler writes a generated password into the field `password`, where `modUser::set()` stores only its hash, and logs the user in with it. The password the user chose is replaced and stops working. The page now says that, in its own section **The Password Is Replaced**; the sentence about the gain moved to the section above it. **The link to the forum topic was dead.** The topic of the old forum is gone. The sentence now points at the MODX Community, which is where the forum lives. The Russian page had a dangling reference to a link below that was not there any more; it points at the same place. **The page about resetting a password by hand had lost the statement.** The note that the password cannot be calculated in the database was right, but the way out was described in prose only. The `UPDATE` statement is back, with the `hash_class` of the user set to `MODX\Revolution\Hashing\modMD5` and the password written as an MD5 hash — the database has an `MD5()` function for that. Both locales follow.

Fact-checked the whole section against MODX Revolution 3.x code and closed 122 audit findings: 13 PHANTOM, 27 STALE, 6 ORPHAN, 56 UNDOCUMENTED, 18 UNVERIFIABLE. The Russian locale mirrors the English one page by page. Themes of the manager: - `manager_theme` holds the name of a directory inside `manager/templates/`, the combo box cannot be typed by hand, and the upgrade script resets the value to `default`. A theme has to carry `images/modx-icon-color.svg`, `images/modx-logo-color.svg`, `images/login/default-background.jpg` and `email/default.tpl` — they are read from the theme with no fallback. The stylesheet of the login page is not themed: `login.tpl` links the one of the `default` theme by a fixed path. Dashboards: - a widget comes in seven sizes and four types, the Inline PHP one included; the paths of the menu, the labels of the buttons and the key of the lexicon in the example are the ones of MODX 3; - added the fields `permission` and `properties`, the setting `hide_trees`, the permission `dashboards`, the personal resize, the seven widgets of the core, the creation and the deletion of a dashboard, the filter by a user group, the events and the permissions. Form Customization: - the eleven pages of `rules/` described the grid of rules of MODX 2.x, which does not exist in 3.x: the rules are derived from the three grids of a set and are rebuilt on every save. All eleven pages were rewritten for 3.x; - added the list of the ten kinds of rules, the order they are applied in, the list of the fields and of the regions, the three actions of a set, the groups of the policy templates and the API of the section; - the name and the value of the rule "Move TV to Tab" were swapped in the documentation, and the two region ids that do not exist were fixed. Security: - the model is list-based, not attribute-based, and the wording now matches the code; - the table of the permissions of the Administrator policy was rebuilt from the core: 183 rows, the four permissions that never existed are gone; - the paths of the menu of MODX 2.x were replaced with the ones of 3.x; - added the twelve policies of the core, the seventh policy template, the seven groups of the templates, the five kinds of ACL, the fifth access area of a group, the permissions needed to manage groups, roles and policies, the flag `sudo` with its permission `set_sudo`, the eight missing fields of a user, the events of the section, the settings of the accounts and what a fresh installation creates; - the passwordless login and the manual reset of a password were corrected for 3.x. Every page of the section carries a `description` in the frontmatter, as the passes over resources, sending-mail and tag-syntax did. The frames of the Russian pages were missing: eighteen images that live only in the English locale were added to `ru/`, the way the other locales of the set keep their images.

Technical-editing pass over the whole client-proofing section in English: - cut filler and answer-first openings, moved details into the body; - turned prose into tables and lists where the content is reference data (widget fields, set fields, permissions); - unified terminology (User, User Group, Resource Group, Access Policy, TV, System setting, the manager) and the menu paths (the lock icon in the user menu, Admin for the gear); - unified the See Also list across the security section and the dashboards / form-customization subsections; - split sentences over 25 words and replaced the 2.x-era menu labels; - aligned the two reference tables (Administrator Policy, Resource Policy) and the field tables without touching their content.

…tion The editorial pass rewrote the English pages; the Russian ones were left behind. The RU pages now match the English ones: - the lists of "See Also" are the same in both locales: 19 items for the security section, 9 for the dashboards, 4 for the widget types, 6 for the form customization and 3 for its rules; - the English page of the resource groups got the unified list of the section — it was the only page that still carried the old one; - the prose that the English pages moved into the body is back in the body of the Russian ones: the link to the tutorial about a manager access and the video on the security model, the paragraph about the policy templates, and the two further readings about the rights; - the menu paths are the ones of MODX 3: the lock icon in the user menu → **Access Control Lists** → the tab **Roles**, the tab **Context Access**, and (**Admin → Actions → Create Menu**); - the rules of a form customization set call a template variable a TV, as the English pages do, and the name of the tab **Template Variables** is left as it is in the interface; - two headings follow the English ones: "Модель безопасности" and "Что такое панель управления".

Three remarks. **The passwordless login page was confusing about the password.** It said that the password of the user "stays in the database all the same" and that every login by a link writes the hash of a temporary password into the field `password` — two statements that read as a contradiction. What the code does (`manager/controllers/default/security/login.class.php`, `handleMagicLoginLink()`): the handler writes a generated password into the field `password`, where `modUser::set()` stores only its hash, and logs the user in with it. The password the user chose is replaced and stops working. The page now says that, in its own section **The Password Is Replaced**; the sentence about the gain moved to the section above it. **The link to the forum topic was dead.** The topic of the old forum is gone. The sentence now points at the MODX Community, which is where the forum lives. The Russian page had a dangling reference to a link below that was not there any more; it points at the same place. **The page about resetting a password by hand had lost the statement.** The note that the password cannot be calculated in the database was right, but the way out was described in prose only. The `UPDATE` statement is back, with the `hash_class` of the user set to `MODX\Revolution\Hashing\modMD5` and the password written as an MD5 hash — the database has an `MD5()` function for that. Both locales follow.

…e 3.x runtime The pages told readers that an MD5 reset returns to modNative, that every update resets the theme, and that several manager labels differ from the ones on screen.

…e to modNative The lead said a password cannot be written in SQL. That is true for modNative. The modMD5 UPDATE on the same page does write one.

Ibochkarev requested a review from Mark-H October 20, 2026 13:39

Mark-H reviewed Oct 20, 2026

View reviewed changes

Ibochkarev added 4 commits October 23, 2026 12:59

Ibochkarev force-pushed the docs/client-proofing branch from 2f739a4 to 31da295 Compare October 23, 2026 07:00

Ibochkarev added 2 commits October 23, 2026 14:57

docs(building-sites/client-proofing): match the manager labels and th…

99fc18c

…e 3.x runtime The pages told readers that an MD5 reset returns to modNative, that every update resets the theme, and that several manager labels differ from the ones on screen.

docs(building-sites/client-proofing): limit the database password not…

468c0c3

…e to modNative The lead said a password cannot be written in SQL. That is true for modNative. The modMD5 UPDATE on the same page does write one.

Navigation Menu

Repository navigation

docs(building-sites/client-proofing): fact-check pass, en/ru sync - #672

docs(building-sites/client-proofing): fact-check pass, en/ru sync#672
Ibochkarev wants to merge 6 commits into
modxorg:3.xfrom
Ibochkarev:docs/client-proofing

Ibochkarev commented Oct 20, 2026 •

edited

Loading

Uh oh!

Mark-H Oct 20, 2026

Uh oh!

Ibochkarev Oct 23, 2026

Uh oh!

Mark-H Oct 20, 2026

Uh oh!

Ibochkarev Oct 23, 2026

Uh oh!

Mark-H Oct 20, 2026

Uh oh!

Ibochkarev Oct 23, 2026

Uh oh!

Mark-H commented Oct 20, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

Ibochkarev commented Oct 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Affected versions

Relevant issues

Not checked

Uh oh!

Mark-H Oct 20, 2026

Choose a reason for hiding this comment

Uh oh!

Ibochkarev Oct 23, 2026

Choose a reason for hiding this comment

Uh oh!

Mark-H Oct 20, 2026

Choose a reason for hiding this comment

Uh oh!

Ibochkarev Oct 23, 2026

Choose a reason for hiding this comment

Uh oh!

Mark-H Oct 20, 2026

Choose a reason for hiding this comment

Uh oh!

Ibochkarev Oct 23, 2026

Choose a reason for hiding this comment

Uh oh!

Mark-H commented Oct 20, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Ibochkarev commented Oct 20, 2026 •

edited

Loading