fix(schema): use FQCN for core model classes to resolve PSR-4 deprecation

[Ibochkarev]

What does it do?

Use fully qualified class names (FQCN) for all core model classes in core/model/schema/modx.mysql.schema.xml. Replaces every short class name (e.g. class="modNamespace", class="modResource", class="modUser") with MODX\\Revolution\\* equivalents. Covers modNamespace, modPlugin, modPluginEvent, modSystemSetting, modMenu, modResource, modUser, modTemplate, modChunk, modSnippet, modCategory, modContext, modEvent, modFormCustomization*, modTemplateVar*, modUserGroup*, modAccess*, and all other mod* objects in the main schema.

Additionally, modX::loadClass() now normalizes short mod* names to FQCN at runtime. When legacy code or xPDO call paths pass short names (e.g. modResource, modAccessContext), they are converted to MODX\Revolution\* internally. A class_alias is created for backward compatibility. This avoids deprecation notices from getObject, getCollection, newQuery, and other paths that invoke loadClass before modAccessibleObject::load.

Why is it needed?

Short names in the schema cause the profiler and modX::loadClass() to trigger v3.0 deprecation warnings that tell users to replace references with MODX\\Revolution\\* for PSR-4 autoloading. Application code already uses modNamespace::class and equivalent; the warnings come from the schema-defined class attribute and the resulting xPDO map keys. Updating the schema to FQCN aligns metadata with PSR-4 and removes the deprecation notices. Runtime normalization in loadClass() handles remaining call paths that still pass short names.

How to test

Run the application with the profiler or deprecation log enabled; verify that deprecation warnings for mod* classes from this schema no longer appear. Optionally rebuild the model from the updated schema and confirm the map uses FQCN.

Related issue(s)/PR(s)

None.

[Mark-H]

I'm confused about the schema changes - all objects are already in the \MODX\Revolution package so this is already getting prepended as namespace when the model is built. It seems like this would cause that it to get doubled up.

Any deprecation warnings should come from specific usages using the short name, not the core schema. But as there's no issue linked or deprecation warning shown, it's unclear what specifically we're fixing.

The loadClass fix I could get behind but would want to test with third-party extras that have (perhaps unwisely so) used the mod prefix in their models.

[smg6511]

On the loadClass change: Isn't the whole idea of having these deprecation warnings to remind (badger) us to adopt the appropriate replacement method? I don't think it's a fix to mute those.

[smg6511]

@Ibochkarev - Hey, just wanted to get your response to Mark's and my comments above and whether you want to continue to pursue this change. Thx ;-)

[Ibochkarev]

Thanks @Mark-H and @smg6511 — really helpful feedback, and sorry for the slow reply.

After re-reading your comments I agree the original approach was off:

Schema FQCN — you're right. Objects already live in the MODX\Revolution\ package, and xPDO prepends that namespace when the model is built. Putting FQCN in class="..." risks doubling the namespace. I've reverted all schema changes.

loadClass() normalization — also reverted. @smg6511 is right that those deprecation notices are intentional; muting them in loadClass() would work against the v3.0 migration path rather than help it.

What I kept instead — fixing actual short-name usages in core code. A repo-wide search turned up two remaining call sites that still passed bare mod* strings into xPDO:

• modResource::isPreviewable() — getObject('modResource', …) → getObject(modResource::class, …)
• modUser::getResourceGroups() — loadAttributes(['modAccessResourceGroup'], …) → loadAttributes([modAccessResourceGroup::class], …)

Pushed in 7c7b3df9e.

Happy to dig further if you know of other profiler warnings I missed — I didn't have a concrete stack trace in the original PR, which was part of the problem. If there are more, I'd rather fix them at the call site than in schema or loadClass().

@Mark-H — on third-party extras using the mod prefix: with the loadClass() shim gone, those should behave exactly as before. Worth a quick smoke test if anyone has a known extra that does this.

Let me know if this direction works or if you'd prefer closing the PR and opening a smaller one with just the two call-site fixes.

[smg6511]

@Ibochkarev My first comment is optional (but maybe preferrable), but it'd be good to know more re the modUser->getResourceGroups method — unless it's used behind the scenes somehow, we may be able to just remove that (?).

[smg6511]

more re the modUser->getResourceGroups method

Answering my own question, this is used in one place in modResourceGroup->hasAccess.

[smg6511]

Ok, we're good here!