Do you get the newlines from this issue?

Hi atrol - Were you pointing to another bug because I can't see it in your note.

I am talking about the newlines you entered in the description of this issue.
You wrote: "I'm able to enter newlines in the description box ....."
Do you mean the newlines entered in notes or newlines entered in the description box?

Both newlines in the description box and notes are being "lost" when displaying. Is there something specific I have to do with respect to PHP settings and/or something at the Mantis-level configuration for it to display properly?

I have to ask again:
Do you see the newlines of this issue 0012683 ?
I want to be sure whether the issue is caused by a server or a client setting

Hi - sorry, I didnt understand what you meant earlier.

I have no problems seeing the newlines in "THIS" bug (0012683), only all the bugs on my Mantis setup.

I am not able to reproduce the issue in my test installations.

Did you install any plugin?
Did you write any custom functions?
Did you change the source code of MantisBT?

No.
No.
No.

I did import a database from an older Mantis version into a newer / more recent one - that's it.

I understand that others and you won't be facing this problem and that's fine. There is distinctly something in my Mantis or server setup which is causing this.

Can you help me identify what PHP settings might be affecting this?

Do you get the problem only when looking at your old imported issues or also when entering new issues?

Thanks for the continued follow-up atrol... I'm seeing the same issue for the imported as well as the newly created ones.

create a file test.php in root directory of your MantisBT installation with the following content

<?php

echo nl2br ("1\r\n2");

?>

Thanks atrol - I get them on different lines when its at www.mysite.com as well as when its at www.mysite.com/mantis/

In php.ini, I changed
default_charset = "iso-8859-1"
to:
default_charset = "UTF-8"

But that did not work.

ATM I have no idea what's happening.
Maybe running admin/check.php will show bad settings of your installation.

I was getting two errors because one of the tables, mantis_project_category_table was in CHARSET=latin1 format, whereas the rest of them are in utf-8

I deleted this table as it didnt seem to exist in the default setup of Mantis 1.2.4 - this led to the two errors being resolved, but didnt solve my newlines problem.

Seems that your current installation is not standard.
You should setup a complete new test installtion in a new directory and a new database and check if the issue exists.
I want to be sure not to waste time for debugging/trying and maybe finally finding that the issue is caused by a manipulated database and / or source

The installation of Mantis 1.2.4 is standard. However, when importing the old content, I did the following relevant steps:

1. I cleared ALL the tables completely. I did NOT drop them, just deleted all the rows.
2. Then I imported the tables from the old Mantis version. There were a few fields mismatch for which I deleted them from the DATA, not the DB structure.

Because I was using mysql < file.sql format to import data, a new table would have been created which existed in the old Mantis setup but not in the new (1.2.4).

read file doc/INSTALL chapter UPGRADING for the recommended way how to upgrade.
I am quite sure that your step 1. is the reason for your problem.
You cleared table mantis_plugin_table, so you disabled the MantisCoreFormatting plugin which is the one who is reponsible for formatting the HTML output of issues. (where also handling of newlines is implemented)
Futhermore you cleared mantis_config_table. This is not a problem for the moment, but will be a problem in future for you when upgrading. There is one setting to hold the database schema version which is used when upgrading.

Thanks atrol! That solved the problem exactly. I also restored / set mantis_config_table to its 1.2.4 value

INSERT INTO mantis_config_table VALUES ('database_version',0,0,90,1,'183');

I'm keen on removing MantisCoreFormatting completely (or at least removing the part where it escapes HTML). If we do end up keeping it then I do agree that we should have checks in place to ensure it is loaded.