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’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
-
MODX Staff
- 10,725 Posts
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
-
MODX Staff
- 10,725 Posts
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
