Tried to open mantis via firefox 3.6. Page does not display correctly.
No Images and url looks very freaky: http://mantis.example.com/\/my_view_page.php

First check whether your config_inc.php contains anything of your old installation which must not longer be set there. (especially any paths)

A virgin config_inc.php of 1.2.0 contains nothing more than something like
<?php
$g_hostname = 'localhost';
$g_db_type = 'mysql';
$g_database_name = 'bugtracker';
$g_db_username = 'root';
$g_db_password = '';
?>

You should also check the settings of
_SERVER["SCRIPT_NAME"] and
_SERVER["DOCUMENT_ROOT"]
with phpinfo();

Is your server running Windows?

Okay checked. Variables containig this:

SCRIPT_NAME /phpinfo.php
DOCUMENT_ROOT C:/WebServices/xampplite/htdocs/mantis

and yes my server is running under windows. its a basic xampp 1.7.3 installation

Okay i solved my problem with moving mantis to a subfolder.
So my url is now: http://mantis.example.com/bugtracking/my_view_page.php
But thats only a workaround.

This is a problem with the URL guessing algorithms duplicating the trailing /. IN the mean time, if you explicitly set $g_path in your config_inc to http://mantis.example.com without the trailing slash, that should fix the problem for your installation.

Targetting a proper fix for next 1.2 release.

I vote that we remove the automatic path/URL stuff from config_defaults_inc.php and instead integrate it into the installer somehow?

I am no specialist of PHP and tbh until now not really knowing how sessions are working or what require_once exactly means.

If I understand the idea of dhx, the code which runs now for every session should run only one time during install.

I like the idea of having the lowest base overhead per request which is possible.

At the other side there will be a loss of convenience for the administrator (when moving an installation, changing protocol, ...)
If this would be the only disadvantage, I see no reason why this should not be changed

Keep in mind that one instance of MantisBT might be connected over http and https, so $t_protocol variable will be set different during runtime.
Maybe this is a stopper for your idea?

@dhx: would be nice if you could explain me (or provide a good link for a short description of the concepts) how often the code in config_defaults_inc.php is interpreted in the current implementation, for example when am user logs in, enters an issue, after that views another issues, ...

I'm personally against removing the path/url detection. There are multiple use cases for being able to detect this on the fly, mostly useful for sites with multiple entry points with different URLs.

For instance, I work with a site that exposes a single tracker via multiple domains and protocols. "Internal" access over the local subnet uses a url like http://server/mantis/, and external user access uses urls like https://domain1.com/mantis/ and https://bugs.domain2.com/. Without being able to detect those paths on the fly, this sort of usage would not be possible.

Honestly, it just needs to have someone sit down and fix some of the edge cases, and then it should work just fine. Hopefully I can do so in the near future.

http://www.mantisbt.org/bugs/view.php?id=11700

1)
I tried to add to config_inc.php
$g_path = 'http://bt.example.com';

On opening http://bt.example.com system trying to open
http://bt.example.commy_view_page.php/ (i.e. not valid url)

If I open directly http://bt.example.com/my_view_page.php/
I have lot of next stuff:
a) <link rel="stylesheet" type="text/css" href="\/css/default.css" />
b) <img border="0" alt="Mantis Bug Tracker" src="\/images/mantis_logo.gif" />
c) < a hr ef="http://bt.example.comissues_rss.php?username=......;project_id=3">
d) < a hr ef="\/view.php?id=107" title="....">0000107</ a>

2)
I tried to add to config_inc.php
$g_path = 'http://bt.example.com/';
a) - still same
b) - still same
c) - correct link now
d) - same

I believe I have a proper fix for this problem. I've pushed the fix to my proposal repo [1] and would like some feedback on the patch, especially from anyone running MantisBT on a Windows server or IIS.

[1] http://git.mantisforge.org/w/mantisbt/jreese.git?a=commit;h=2a5a0bc17f72e2cdf560fd4a4f912c5d5e7c3665

Fix committed to 1.2.x and master branches.