⚠️ Urgent! Active Attacks on MODX Revolution Sites Below Revolution 2.6.5
Subscribe: RSS
  • http://newsite.theorangeplanet.com/index.html

    Above is the link using MODx 9.5 that has a flash piece loading a xml based document that is build from a "DITTO" summary (with chunk wrapper)

    http://newsite.theorangeplanet.com/news.xml

    Above is the xml file which parses just fine.
    • I also have had problems with xml-files in 0.9.6.
      When dynamically creating the xml with a custom snippet the documentparser apparently adds some whitespace before the "<?xml..." declaration. Even when the script only echoed or printed a static string the whitespace was added. Right now I’m using a xml-file created externally from modx. I haven’t found a solution for doing this in modx, but I’ve honestly not tried that hard because of my backup-solution.
      • Quote from: carlholmberg at Oct 17, 2007, 08:34 AM

        I also have had problems with xml-files in 0.9.6.
        When dynamically creating the xml with a custom snippet the documentparser apparently adds some whitespace before the "<?xml..." declaration. Even when the script only echoed or printed a static string the whitespace was added. Right now I’m using a xml-file created externally from modx. I haven’t found a solution for doing this in modx, but I’ve honestly not tried that hard because of my backup-solution.
        I run several sites on 0.9.6 (or more recent versions); I tried returning XML content from all of them and they work fine on every site I’ve tried; no extra whitespace. Are you sure you don’t have a custom PHP file (or another component installed) with extra whitespace after the closing PHP tag included somewhere?

        @ww4667: I can’t explain why this is not working for you on 0.9.6; I’ve run tests on every 0.9.6 install I have -- I would look into Ditto itself and see if the extra whitespace problem may be in the component. You can always get the latest versions of the components and install those over the ones distributed with 0.9.6 to double-check.
        • I’ve learned something! The document will not be parsed if (blank) is used for the template.

          Apparently the lack of a template will not allow it to parse correctly.

          Don’t know if this sheds light on anything, but I’ll update if I find a work-around.

          Greg
          • Quote from: ww4667 at Nov 15, 2007, 05:02 PM

            I’ve learned something! The document will not be parsed if (blank) is used for the template.

            Apparently the lack of a template will not allow it to parse correctly.

            Don’t know if this sheds light on anything, but I’ll update if I find a work-around.

            Greg
            This is not true at all. Something else is wrong. I use XML and all kinds of document types with (blank) templates all the time. Did you update to 0.9.6.1?
            • yes!!! I’m working in 9.6.1 right now!

              -- update --

              the xml document will show if I attach it to a document with these minimums... AND!!! I’m logged into the manager.

              As soon as I log out the page will NOT parse...

              minimal template code:
              -----------------------
              [*content*]
              <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
              <head>
              <title>title</title>
              </head>
              <body>
              test
              </body>
              </html>
              • Sounds like your pages simply are not published, in which case, you must be logged in to see them.
                • Let me first say Thank you for hanging in here on this topic.

                  Another angle on this:
                  1) any document type other than html reveals the problems
                  2) document types NOT html seem to work if the default MODX templates are attached
                  3) ALL document types fail to parse when (blank) is selected for template
                  4) ALL document types fail to parse with a template containing only "[*content*]" (minus quotes)

                  EXCEPTIONS:
                  1) If documents of any type contain DOCTYPE and HTML tags the documents will attempt to parse.
                  a) plain text will work fine (obviously all the markup laguage shows along with the intended content)
                  b) html will parse fine (that’s a given)
                  c) xml tries to parse but errors if DOCTYPE and HTML tags appear before the <?xml.... tag
                  d) xml parses with DOCTYPE and HTML tags appearing after <?xml.... tag
                  -- view source code reveals the markup language --
                  e) css parses fine but the markup language that is in the css document makes the css not work when referenced
                  f) javascript -- haven’t tried that yet.

                  CONCLUSIONS:
                  1) This has something to do with the parser skipping documents not containg DOCTYPE and HTML tags
                  --- or something like this ---
                  2) MODX 9.5 has no trouble parsing all documents (as intended) on the exact same server setup
                  3) all documents are published so this is not user oversight or error
                  4) possible that the 9.6 php code is using features in a newer PHP version that I may not have...
                  -- current version in use: PHP Version 4.3.11

                  I’ll be glad to upload a snapshop of my PHP info() if this might help... if it’s as simple as adding something to .htaccess that would be great!!!

                  THOUGHTS:
                  1) There mus be some difference in how the parser works while logged in as manager vs. not being logged in. Thinking this might have something to do with this.
                  2) Changed the "0" to a "1" in index.php (root) to enable seeing PHP errors if there are any... so far no errors are seen with any of the afore-mentioned document types.

                  Thank you again for your patience and dedication to an excellent product!

                  Greg
                  • I cannot reproduce any of this behavior in PHP 4 or 5, so something else is wrong here, but without more information on specific content you are trying to parse, it’s hard to tell what it is you are experiencing.

                    I generate dynamic XML, CSS, JS, JSON, and other types with various versions of MODx, including the latest releases, and all tags are processed properly, regardless of the content type when I do this.

                    Perhaps we should start by examing what you precisely mean by will not parse? What will not parse? What is the resulting content? Resulting response headers? Is there an error?

                    And there is no PHP 5 specific code that I am aware of that would affect this.
                    • Good idea.

                      Parsed information = what is seen on the browser when called up via a non-logged-in web user to the site.
                      -- also what is seen via view source code --

                      Does not parse or fails to parse = blank browser window and nothing in view source -- in fact view source option on the browsers fails to even bring up default source viewer (opera/firefox/ie)

                      I’m ww4667 via hotmail for chat if you want to discuss this there... I just IM’d you

                      OH YEAH... no errors that I can see...

                      Greg