Bug: normal view differs from raw view

[cereal]

Hello. The problem is in this post. First block of code, line 5 and line 9. I see a difference between normal view and raw view (on double click). In normal view line 5 appears like:

<Directory />

in raw:

<Directory ></Directory>

and the same happens on line 9. These are the screenshots:

I'm not sure if the enclosing tags where added here by daniweb scritps or by the author's post, but a part this, the problem is that the normal view is not displaying the same content. Also, apparently, I'm not able to reproduce the issue: posting the same code didn't create this difference.

Thank you for your attention.

[deceptikon]

That's weird. It's almost as if our code highlighter is interpreting tags with no content as empty tags. At least for that particular malformed situation (an extra closing tag that was probably added automatically by a "helpful" editor):

<tag></tag>
    stuff
    stuff
</tag>

[cereal]

Yes I thought the same, but a week ago I posted a similar config file (I completely forgot to mention it while writing the first post) and I'm sure I didn't add a closing tag nor it was done by my IDE, as in that particular case I used leafpad to open the file and copy the contents, which are still right.

Anyway in the normal view the code is formally correct, because:

<Directory />

it is not a self-closing tag as <br /> but an Apache directive to set the root. In both cases the problem seems to be generated by the trailing slash, as example double click on this:

<tag /var/www/>
    hello
    some lines of code
    dum da dum
</tag>

Hope it's helpful.

[Dani]

It's obviously bad that our code highlighter is interpreting things differently, but do you realize that the poster posted malformed code? Notice their <Directory > has an extra space, and that is never closed.

[cereal]

Notice their <Directory > has an extra space, and that is never closed.

No Dani, I'm sorry I cannot explain it better, English is not my first language. I didn't posted any malformed code, double click here:

<Directory />

The normal (beautified) view is correct. The raw output is wrong and different from what I originally posted and if you check the HTML output of this thread you can see the actual code. Look at this screenshot, this is what I wrote:

But after posting, this is the result (in the raw view):

This happens also in my previous posts of this thread. Anyway, I wanted to point out the problem because I thought the user who I helped in the cited threads, maybe just copied what I wrote and, since this can be done only by double clicking on the code block, he could have copied an alterated version.

Let me know if I have to explain it better, I will try if needed :)

[Reverend Jim]

Isn't "<tag/>" shorthand for "<tag></tag>"? In which case the original code is malformed. It looks like double clicking the code is just replacing the shorthand with the longhand version.

[cereal]

Exactly, it isn't a shorthand, it's a directory path, maybe this will help to understand: http://httpd.apache.org/docs/2.2/mod/core.html#directory

[Reverend Jim]

It seems to me you are trying to use a reserved character "/" in a place where it doesn't belong. I would think the proper syntax would be

<directory>/</directory>

or possibly

<directory dir="/">

[cereal]

No, please check the link, in the Apache configuration file or in .htaccess files this is the correct syntax. For example, if you want to deny web access to a specific directory, let say test, you have to write:

<Directory /test/>
    Order Deny,Allow
    Deny from All
</Directory>

with the path inside the tag. The problem is given by the trailing slash which, in the raw view, is intrepreted like a shorthand.
This problem can also happen with Location directive: http://httpd.apache.org/docs/2.2/mod/core.html#location

[Reverend Jim]

If you say so. From what I know of xml/html that is not standard. Values go between tags and attributes go inside double quotes.

[deceptikon]

No, please check the link, in the Apache configuration file or in .htaccess files this is the correct syntax.

Our highlighter doesn't magically determine that you're using an Apache configuration or .htaccess file and adjust its logic accordingly. So whether it's valid for Apache or not is irrelevant. Is this valid XML? If not then the highlighter could rightfully be choking on malformed syntax.

Of course I still don't think it should be modifying the content, but that would at least explain why it's happening. ;)

[cereal]

Yes, I agree and obviously I don't insist and thank you all for your patience, but this is not XML.

This is the syntax for the configuration files of Apache servers. This kind of syntax is used inside httpd.conf, apache2.conf, .htaccess and the files used to configure virtual hosts.

For me it's not a big problem, because I know what is happening and now I will make more attention. But, for example, if in the PHP/Linux/Windows/Ruby/Python/Perl forums we want to paste the contents of a .htaccess file, modify it, suggesting rewrite rules, well when another user is going to copy, he will copy something wrong, that doesn't work because the raw view is altered.

Bye! :)

[deceptikon]

This is the syntax for the configuration files of Apache servers. This kind of syntax is used inside httpd.conf, apache2.conf, .htaccess and the files used to configure virtual hosts.

We don't have a highlight mode for that, it's probably interpreting it as XML. But I absolutely agree that producing different highlighted text than raw text is a bad thing, and when I get a chance I'll see if it's something that can be fixed without herculean efforts.

[Dani]

Because it's screwing up the plaintext version, and not the beautified version, this is unrelated to our pretty print parser. It's entirely a jQuery issue/known bug. Looking into it ...

[Dani]

I think I fixed this. Can you guys confirm?

[cereal]

Yes, now it's perfect! :D
Many thanks!

EDIT

just out of curiosity about JQuery: which bug was?

[Dani]

I think it was actually a record for one of the fastest times I've ever spent debugging javascript!!

[cereal]

If any other problem occurs I'll try to explain it better, so maybe it will be easier to catch it. Thank you all again! Wonderful support!

[Dani]

Chalk it up to me being super sick and finally getting my head clear enough to understand what you were asking :)