We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
MODX Community Forums Archive

Answered Lexicon Cache Inconsistency

    • 37108
    • 80 Posts
    smg6511v2 Reply #1, 5 years, 9 months ago
    I've got a mystery on my hands regarding a lexicon topic residing in a custom namespace — one that's not associated with a CMP — which sometimes generates a cache file with only those entries that were overridden (via Lexicons in the manager), excluding others in the topic's php file. When this happens, the requested lexicon keys are displaying on the front end for all except the overridden ones. In the places where I'm trying to use the custom topic I am calling the service and loading the namespace:topic as directed in the documentation. I must be missing something, but am at a loss after much troubleshooting. I'll go into greater detail as necessary, but wanted to see if this sounds familiar to anyone.

    This question has been answered by smg6511v2. See the first response.

    • discuss.answer
      • 37108
      • 80 Posts
      smg6511v2 Reply #2, 5 years, 9 months ago
      Well, this issue seems to have been resolved by creating a new namespace and copying the lexicon files to that new space. I tried this as a last-ditch effort as there was only one other thing I could think of that could cause the odd behavior (aside from possible misuse of the Lexicon class within some of my code):

      The site I'm working on is a subscription-based research product that recently changed hands to a new parent company. The namespace I'd initially set up for custom code was named based on the old product. I'd created a new namespace for the new product, but pointed the core path to the old namespace to avoid having to update all the static paths I'd set up to various snippets in the short term. I'd not been relying on lexicons much, if at all, in the sites templates until very recently. When I began using lexicons for a new feature I was working on, I decided to do it under the new namespace and move all existing code there (on the server). The trouble began after during this process. I'd looked everywhere I could think of in the database and file system for inconsistencies I may have introduced, but couldn't find anything. As such, I can't identify where the conflict is exactly, only that the begin anew route seems to have done the trick.