[SOLVED] Manager broken after running MyComponent/Bootstrap

I'm not sure if the mess happened when installing MyComponent, or later after I created a new project and ran Bootstrap. I'm not even sure if it's MyComponent's fault, but it's the only thing that I worked on so it must have something to do with it somehow (does Bootstrap affect any critical file or setting maybe?)...

• The cache manager cannot manage (no pun intended) to build proper lexicon cache files anymore (it does not include any /core/lexicon entry, only user defined entries either from the db or from files).
• If I try to click on what should be the Elements or Files tab on the resource tree I get an 'access_denied' error instead. this only happened once, looks ok now
• Loading the site homepage gives the following error:
  

  Fatal error: Call to undefined function parseTpl() in /Users/manus/Lavori/Web/latte/restarteurope/core/cache/includes/elements/modsnippet/1.include.cache.php on line 592

• I can still log in and out.

I attached below a screenshot of what the manager looks like.

What I tried:

• empty the cache folder and refresh the site cache
• empty browser cache and cookies and log in again
• update REVO
• run the https://github.com/craftsmancoding/modx_utils/blob/master/test_config.php script (it says everything is setup correctly)
• git says that no core files where modified
• I tried to have a look at the settings in the db, comparing them with another working installation of MODX but I couldn't find any differece in settings, users, lexicon etc.

Now, it's not a tragedy because this is an experimental site on my local environment and I could still loose some time and start with a fresh install, but I really need to understand what happened. I cannot take the chance of a similar thing happening on a live site.

Any idea, or suggestion?

Thank you for any help! [ed. note: mjsarfatti last edited this post 12 years, 3 months ago.]

Well, this is what happened, in case anybody runs in the same problem:

In the configuration file I had the following code:



meaning that I instructed Bootstrap to add an entry to the system settings named precisely core_path, which pretty much messed everything up.

I was under the assumption that Bootstrap would have added petitions.core_path instead, or that somehow MODx didn't confuse components settings with core settings. But it did, and everything broke.

The System Setting keys you specify in the config file are exactly what you get. Adding a prefix could well break other code in the package in a way that would be very hard to diagnose. It's a good practice to add a prefix yourself, though, when creating new System, User, or Context Settings -- sorry you had to find that out the hard way.

I can't think of any good way to protect against what happened to you, since most of the relevant code is in MODX, not MyComponent. The new System Settings are created with newObject() and newObject() returns a new object with the fields set (including the primary key, which in this case is core_path). Apparently, saving that new object overwrites an existing object with the same key.


Sorry about the trouble, and thanks for figuring out what happened and reporting back.

No need, in fact thank *you* for MyComponent.
I guess I was tricked by seeing the namespace between the keys. I think just a line in the comments suggesting as a best practice to always prefix/namespace your keys would be more than enough there.

Done! Thanks for the suggestion.