Bob Ray

It seems so. I've seen these elsewhere in classes, so I though there might be a way to set them early based on info in the .yml file. ``` protected...

> Protecting the core using .htaccess or a simple nginx rule is just as secure as the security-by-obscurity of moving the core. IIRC, this solution breaks some extras. I think...

This still seems like a good idea to me. The ClassExtender extra calls `addExtensionPackage()` and the result is still written to the system setting, and the modExtensionPackage table remains empty.

I also find that packages in the modx_extension_packages table don't seem to be loaded when `$modx->initialize()` calls `_loadExtensionPackages()`. They're retrieved with this call: ``` $cache = $this->call(modExtensionPackage::class, 'loadCache', [&$this]); ```...

Sorry, I missed this question until now. TBH, I really don't know.

No, but I suspect a lot of users have been confused. ;) I would say it still needs fixing. Otherwise, it's likely to persist into future versions. While we're discussing...

Wow, 2010??? The improvements I suggested way back when would result in less confusion for people trying to use the extended fields.

That was my suspicion as well, but why would we want a single validator to run over and over. This doesn't happen with resolvers does it?

I agree with Susan (Upgrade MODX gets added to the default dashboard and has always stayed there through all upgrades). I can confirm that removing widgets from the default dashboard...

The code above, and the code I've created for packages is rendered perfectly at https://parsedown.org/demo. Also, MODX 2.8.4, which uses Parsedown 1.0.0 doesn't parse links correctly.