Okay. So, over the weekend, I set out to pinpoint where the error happens, exactly.
The first thing I did was to create an accurate list of declared classes and dependencies within MODX php files. With that in hand, I collected every class that was referenced via extends and such, that was not in itself part of the MODX code. This yielded three classes: ArrayObject, SimpleXMLIterator and Exception. The first and last are part of PHP's core, and SimpleXMLIterator is part of the SimpleXML extension - but, just for kicks, I tested each one with a simple class_exists() and they check out. So, the issue is 100% not in non-existent prerequisites.
As long as the code is error-free (and I must assume that it is), any problems with non-existing functions would only have shown up later in the chain, and not resulted in a missing class exception which I was getting --
unless the MODX team is writing classes
dependent on function existence, which I
seriously doubt... So, this lead me to believe that the issue MUST lie in some inclusion code, somewhere. To my dismay however, I have found that MODX uses a custom class loader/parser wrapper. That made debugging the class loader
a bit more tricky.
So, just like Joel Spolsky mentions on his blog (see
http://www.joelonsoftware.com/articles/LeakyAbstractions.html and
https://en.wikipedia.org/wiki/Leaky_abstraction to read more), the abstraction is
leaky. The class loader is an abstraction designed to hide away the fact that PHP doesn't handle critical errors well - they can't be captured, and bubble up directly to the top, where they halt execution. The loader tries to abstract this away by providing a complex set of dependency-driven packages, and it works well...
until the abstraction 'leaks' and I'm staring at a ClassNotFound fatal error, and - thanks to the custom loader - debugging this issue becomes a pain instead. But I digress...
In any case,
modaccessibleobject.class.php is not being
parsed no matter where I looked - the file is just not being processed (none of my debug showed up in the log). I've also learned how the class loader works, and modAccessibleObject is not part of the manifest for module packages - which means that by conventional wisdom, modAccessibleObject should be loaded before the class loader is tasked with loading the packages. But, insofar as the static prerequisites (like transport.xPDO and associates) are loaded manually and stated explicitly in the code, I found nothing like that for modAccessibleObject.
After fuxxing around with it some more, I decided to try to manually include the required files (I expected to use the $modx object, but it's not available within include scope). This finally enabled the setup to move forward, but in the process I've found additional classes that failed to load (which I had to "augment" in the same manner).
Ultimately, I managed to complete setup with a modified Traditional package, and then move the /core, /connectors and /manager to new locations. As such, the site - for now, at least - is live on the development server.
One key note, however: the issue
may be with used passwords, because it stubbornly refused to connect to the database with a password that included a dollar sign and a backtick (whereas even the universally-loathed phpMyAdmin worked without a hiccup).
NOTE: the Setup page connected to the database just fine (according to what it printed out) - it was just the actual setup process (ie. creating and populating tables) that failed. In the end, I used simple passwords like "SimplePass123" to do setup, and then changed them by hand later. I can't tell if that was the issue, though, because I didn't test this on a vanilla package. This may highlight two separate issues, and only a combination of the two allowed me to move forward.
I should also mention, I suppose, that I tried the CLI installer version along with the setup.xml file - no joy there, either, although it never printed any errors. It was only in the /logs directory where I found out that it had trouble connecting to the damn database. Shame...
Summary list of classes that failed to load during Setup:
modAccessibleObject
modAccessibleSimpleObject
modPrincipal
modElement
modElementPropertySet (suspected, because I went ahead and just manually did an include_once for it along with modElement while I were there)
Since I am no longer going to use these passwords, they're essentially free debug tools for the development team. If there's an issue with these passwords, maybe a notification should be displayed to the user? Also, if it's the passwords, would it be possible to find security holes within the setup process and how it handles passwords? Could I somehow attack other databases by providing a crafted password to someone's undeleted /setup/?
SQL password: #=-cK/VJw@NDLYD+4Rr$h%M'/J*.`dwe
Admin password: RxHt8LH*#VSFvZSy&XPL9Pz7Cgz_Tc2$
[ed. note: mellfotostudio last edited this post 8 years, 6 months ago.]
☆ A M B ☆
