On March 26, 2019 we launched new MODX Forums. Please join us at the new MODX Community Forums.
Subscribe: RSS
  • At the risk of repeating myself: wink

    It could be an invalid modTemplateVarResource or modTemplateVarTemplate object.

    SiteCheck would tell you which one and offer to fix it: http://bobsguides.com/sitecheck-tutorial.html
      Did I help you? Buy me a beer
      Get my Book: MODX:The Official Guide
      MODX info for everyone: http://bobsguides.com/modx.html
      My MODX Extras
      Bob's Guides is now hosted at A2 MODX Hosting
    • Sorry Bob I am listening. My reluctance is based on the fact that I've manually checked and fixed both those tables' referential integrity and the type of each modTemplateVarResource value. I've also dissociated the old problematic TV and confirmed the error disappears. I then create a new TV, leave all values default except new name, title and description; I create a new template, copying in only the HTML, and assign it to the brand new TV, transfer one page to the new template with the new TV, and the error returns/edit page stops loading - no values, and every modTemplateVarResource or modTemplateVarTemplate object replaced (not duplicated but created afresh). I dissociate the new TV and the problem disappears/edit page works. The resources you indicate are links between content and TV and template and TV, and I've replaced all parts of that triangle and still get the problem. I therefore suspect it is a MODx bug and buying, installing and running SiteCheck would not get me anywhere in this case. I will publicly eat humble pie if I do manage to find I'm wrong (although of course I may never know).
      • However if SiteCheck goes deeper into tpls, TVs and their content than this (and I'd take your word for it) then I'll give it a whirl.

        (Updating so as not to fill inboxes and continuously bump my issue.)

        I've discovered that the problem appears to be related to TWO TVs. If EITHER of them are removed from the template the edit recovers. (I've checked all referential integrity and value types for them both.)

        Update: Hold any feedback for a while. The 'type' of one of the values is 'dropdown', which is not supported in MODx 2.2.10. Perhaps a consequence of upgrading a site from Evo to Revo using Provisioner. Odd it worked for a while then stopped - perhaps when someone edited something. However I fixed this and replaced the template and other problematic TV am still getting the 500 HTTP error.

        This is getting really really frustrating. Been working on this for a few days, can't remotely charge the client for the amount of time, have records of all the associations I've been testing, and there's just no pattern. I'll find just one TV switches on and off the problem, then I discover another that seems to disable the first, then those will stop making any difference at all and a totally different TV starts triggering or fixing the problem. Anyone any ideas from the other side, ie, what could possibly cause a 500 error? Presumably it is a memory issue due to a multiplicative record join, or something?
        [ed. note: technicaltitch last edited this post 6 years, 2 months ago.]
        • SiteCheck will check to see if both members referred to in the intersect object exist. I assume that's what you meant by "referential integrity".

          The fact that a brand new TV still causes the problem suggests that it's not a problem intersect object (though it's not conclusive proof of that).

          What's the content of the TV? I'm beginning to suspect mod_security.

          Is there anything in the MODX error log?

            Did I help you? Buy me a beer
            Get my Book: MODX:The Official Guide
            MODX info for everyone: http://bobsguides.com/modx.html
            My MODX Extras
            Bob's Guides is now hosted at A2 MODX Hosting
          • As it's a server error, there should be some clue in the server/php error log as well. If it doesn't, try adding this to the top of the manager/index.php file (after <?php) to force errors to be shown in plain sight:

            ini_set('display_errors', 1);
            error_reporting(E_ALL);


            Ideally it will then show an error and a line number.

            What's the type of the second TV that is causing the issue?
              Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

              Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.
            • FIXED!

              Thanks Bob yes that's what I mean by referential integrity - perhaps a term from the days of COBOL and Duran Duran! mod_security only scans data coming in and isn't on my dev server, but great call thanks - I have wasted spent many days missing that. There's nothing in the MODx log, but Mark thank you your answer reminded me I've replicated this on my dev server so have access to server logs. Duh!!

              But before I go into symptoms I have found the fix, thanks to your questions putting a bit more structure into my increasingly desperate diagnosis. Trying to be careful, and distracted by the error's dependence on a text or image TV too, I'd missed fixing some of the dropdown TVs..

              This SQL fixes the problem, however for anyone copying the SQL do test the result - I've tried to make it broadly compatible but it assumes choices about how the new drop-down works which may not match your requirements:

              update qstrv_site_tmplvars 
              set type='listbox', 
              properties='a:0:{}', 
              input_properties=
              'a:7:{s:10:"allowBlank";s:4:"true";s:9:"listWidth";s:0:"";s:5:"title";s:0:"";s:9:"typeAhead";s:5:"false";s:14:"typeAheadDelay";s:3:"250";s:14:"forceSelection";s:4:"true";s:13:"listEmptyText";s:0:"";}', 
              output_properties='a:0:{}'
              where type='dropdown';


              This seems to be the most compatible equivalent in Revo (a restricted ExtJS select) to Evo's dropdown (a HTML select) but I'd welcome correction.

              I did not need to duplicate the template or any TVs or anything else - just run this SQL to correct all dropdowns, which were presumably copied across by Provisioner. I believe this suggests a fix to Provisioner is in order. A very nice-to-have (imho, given it is software designed to accept plug-ins/extras) would be validation within MODx of those options that are stored in the database as text but could/should be foreign keys, such as modx_site_tmplvars.type.

              The log shows:

              [Sun Jan 19 08:28:46 2014] [error] [client 192.168.56.1] PHP Fatal error:  Cannot redeclare class modTemplateVarInputRenderText in /media/pathto/core/model/modx/processors/element/tv/renders/mgr/input/text.class.php on line 10, referer: http://example.com/manager/?a=30&id=640


              So this is being run twice:

              <?php
              /**
               * @package modx
               * @subpackage processors.element.tv.renders.mgr.input
               */
              class modTemplateVarInputRenderText extends modTemplateVarInputRender {
                  public function getTemplate() {
                      return 'element/tv/renders/input/textbox.tpl';
                  }
              }
              return 'modTemplateVarInputRenderText';


              Hence the unpredictable combination of two TVs rather than any predictable one or more. The type of the other TV is text, but last night I appeared to resolve the issue, so restored the database and started trying to find a sequence of steps, and another two TVs of different types (dropdown and image) appeared to trigger the error. [ed. note: technicaltitch last edited this post 6 years, 2 months ago.]
              • Quote from: sottwell at Jan 09, 2014, 02:32 PM
                I once got into this same situation. I had deleted a TV that I wasn't using any more, and every resource using the template that TV had been attached to was causing a 500 server error, whether I had edited the TV for the resource or not. I finally ended up duplicating the template and moving all of the resources to that new template. We never were able to figure out what the problem was. Nothing in the database, nothing in the cache had any sign of the TV or any connection to it, no error reports could be found.

                Afterwards, it occurred to me that it may have been a corrupted index in a database table, but by that time checking tables for needing repair didn't show anything wrong.

                So I would suggest first manually empty the cache (core/cache/), then check your database for tables that need repair. Also make sure that your browser's cache and cookies for the domain are cleared.

                Big THANK YOU Susan for this. I had the following issue: I could no longer edit Resources in a Context. I could QuickUpdate them, save and view them on the front end, but until I read this I couldn't figure it out. AFter adding about 100 Resources to the one particular Context, I took a break to houseclean. I removed TagLister and Smarttag Extras but not the TV that the Input Option was set to smarttag. First I opened the Template and removed the TV. Then I deleted the TV. I Flushed the Cache via Manager, logged out of the Manager, and manually removed the cache folders from the core/cache/ directory. Emptied my browser cache, logged back into the Manager, refreshed the browser a few times and voila! I'm now back in the saddle.

                Moral: this post - from 4 years and 7 months ago!! - saved my bacon and sanity. Wow!

                Side note: I haven't worked on a MODX site in almost 2 years and once again I appreciate how incredibly consistent the MODX platform is!
                Peter B
                MODXCloud 2.6.5, PHP 7.1