We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 36816
    • 109 Posts
    PHP: 5.2.17 (CGI - not FastCGI)
    Apache: 2.2.20
    OS: linux
    MySQL: 5.1.58-community-log
    MODx: 1.0.5

    Greetings,

    Well, this is a first for me in a couple of dozen Evo installs. A content maintainer got a MySQL syntax error on a resource save. I can't re-create the issue on my end.

    Steps -- the best I could extract them -- the maintainer took (twice - same result):

    • Duplicated an existing resource - one that had a (past) publish date and an unpublish date that was also in the past
    • Edited the duplicate
    • Set a future unpublish date
    • Left the publish date blank
    • Checked the "publish" checkbox
    • Attempted to save the resource. System Events log shows a MySql syntax error on UPDATE of the document's row in the modx_site_content table

    The SQL error in the log is:
    « Execution of a query to the database failed - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ' unpub_date=1318441500, parent=26, template=14, menuindex='0', searchable=1,' at line 2 »

    The SQL statement shown in the log is:
    UPDATE `oshkoshr_modx`.`modx_site_content` SET introtext='', content='
    
    Art Wigchers will join us from Milwaukee and will describe recent travels to Pakistan on behalf of Catholic Relief Services, an international service organization.
    ', pagetitle='Weekly Meeting: Art Wigchers, \"Education in Pakistan\"', longtitle='', type='document', description='Art will discuss recent travels to Pakistani', alias='2011-09-05', link_attributes='', isfolder=0, richtext=1, published=1, pub_date=, unpub_date=1318441500, parent=26, template=14, menuindex='0', searchable=1, cacheable=1, editedby=6, editedon=1315241090, publishedon=1315241090, publishedby=6, contentType='text/html', content_dispo='0', donthit='0', menutitle='', hidemenu='1' WHERE id=196;


    A couple of things about the SQL statement seem odd to me:

    • There is no HTML in the content field, even though TinyMCE is installed and the page in question is marked rich text
    • The SQL syntax error seems to be related to the absence of a value for pub_date


      [li]I tried that SQL statement directly -- without MODX -- on (a copy of) the database; same error, plus more verbage pointing at
    pub_date=[/code
      ] being followed directly by a comma.[/li]
    • I tried it again on an older version of MySQL (5.02.43) for the heck of it; same error
    • I changed the UPDATE to use 'pub_date=DEFAULT,' (without the quotes; can't nest a code block in a list here); statement worked
    • I changed the UPDATE to use 'pub_date=0,' (which is the default for that field); statement worked

    Here's an odd thought -- Is it possible that the date picker for the pub and unpub dates is supposed to generate the default value used in the SQL? The absence of HTML in the content field (implying that TinyMCE wasn't working) and empty value for pub_date (if generated by the date selector) might imply at least some JavaScript failure on the content maintainer's machine?

    I don't know the content maintainer's browser and version -- trying to find out.

    I'm hoping someone who knows the internals will recognize this pattern and shout out. It's a puzzler, and a little bit worrying -- I'd not expect regular page edits to generate SQL syntax errors <smile>

    I've left it here instead of using the issue tracker, not knowing if it's truly a bug. I can always pop it in there if it's best.

    Thanks in advance for any shared brain-power on this odd issue. [ed. note: clareoconsulting last edited this post 15 years, 1 month ago.]
      • 36816
      • 109 Posts
      Hate to do this, but... bump.

      When I posted this, I didn't see the Evo / 1.0.5 category. Should I have posted it over there?

      Am pretty concerned about the nature of this error.,
        • 3749
        • 24,544 Posts
        I wonder if the user forgot to check the publish checkbox. I can imagine that having an unpublish date on an unpublished document might confuse things.

        It's probably not worth reporting as a bug unless you can specify how to reproduce it reliably or it's happening a lot.
          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
          • 28042 ☆ A M B ☆
          • 24,524 Posts
          According to the query, "published" was indeed set; it's 1. The date pickers appear to be working, since the unpub date is set. However, that empty publish date is odd. I've tried to duplicate the problem exactly as you've outlined, but cannot. It inserts a pub_date of 0.

          If someone set a custom configuration directive for the TinyMCE plugin to disable forced_root_block, then there wouldn't be any HTML in that content. Otherwise, it should have surrounding <p> tags.

          Just to reiterate, resource #1 is unpublished, with a pub_date and an unpub_date in the past. Resource #2 is published, with no pub_date set and an unpub_date in the future.
            Studying MODX in the desert - http://sottwell.com
            Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
            Join the Slack Community - http://modx.org
            • 36816
            • 109 Posts
            clareoconsulting Reply #5, 15 years ago
            Susan -- thanks for your insights. I still can't duplicate the issue, and the maintainer hasn't reported it again.

            You're right in your reitteration of the tasks the user performed.

            I remain puzzled, but I may have to accept that.
              • 36816
              • 109 Posts
              clareoconsulting Reply #6, 15 years ago
              Oh -- and forced_root_block is not disabled.
                • 28042 ☆ A M B ☆
                • 24,524 Posts
                Sounds like a one-time browser glitch; probably a corruption in a cached javascript file, as you had originally suspected. The user should clear all cache and cookies for the domain, and it probably won't happen again.

                I've had similar problems that are more obvious involving partially-loaded CSS files, and less frequently something along the same lines with javascript files. That's one disadvantage of combining several discrete CSS or Javascript files into one; it will reduce load time but if the connection gets flaky it's more likely to lead to too many dropped bits somewhere along the line.
                  Studying MODX in the desert - http://sottwell.com
                  Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
                  Join the Slack Community - http://modx.org