From: <Chr...@he...> - 2002-10-28 17:24:16
Attachments:
custom_fields_API.php
additional_tables.sql
|
Hi, I've tried to include as may changes as possible that Victor and Julian sent me. As I didn't have much time last week it might be that some slipped by :( Anyway, the results are attached. Probably now is a good time to get the stuff in CVS and try to resolve the rest in there. Because then I could start to implement/modifiy the web pages for the custom fields code and thus figure out limitations and bugs of the api. If there are only small issues left you might want to change them yourself and check it in then. CU, Christian PS: These changes have to go to the corresponding files. As they are that small it doesn't make sense to send the whole file (and I don't have diff on this machine...) strings_english.txt [...] $MANTIS_ERROR[ERROR_CUSTOM_FIELD_DOESNT_EXIST] = 'ERROR: Custom field does not exisit.'; [...] constant_inc.php [...] # access levels define( 'ANYBODY', 0 ); [...] # ERROR_CUSTOM_FIELD_* define( 'ERROR_CUSTOM_FIELD_DOESNT_EXIST', 1300 ); [...] |
From: Colin S. O. <co...@og...> - 2002-10-29 18:08:50
|
Is it possible to use http://server:port syntax with the CVS version of Mantis? I have $g_path = "http://omega:92/"; but mantis is outputting <link rel="stylesheet" type="text/css" href="http://omega\/css/default.css" /> Is this a bug or am I doing something wrong. |
From: Jeroen L. <jl...@ca...> - 2002-10-29 18:39:38
|
At 18:08 29-10-2002 +0000, you wrote: >Is it possible to use http://server:port syntax with the CVS version of >Mantis? > >I have > >$g_path = "http://omega:92/"; > >but mantis is outputting > ><link rel="stylesheet" type="text/css" href="http://omega\/css/default.css" >/> > >Is this a bug or am I doing something wrong. I looked into it. In my CVS version (current at the time of writing), the only way that could happen is if you had manually set $g_css_include_file. Have you? Jeroen |
From: Colin S. O. <co...@og...> - 2002-10-29 21:55:05
|
No - only set g_path and the email related ones. I'll have a thorough look tomorrow. -----Original Message----- From: man...@li... [mailto:man...@li...]On Behalf Of Jeroen Latour Sent: 29 October 2002 18:39 To: man...@li... Subject: Re: [Mantisbt-dev] Using http://<server>:<port> At 18:08 29-10-2002 +0000, you wrote: >Is it possible to use http://server:port syntax with the CVS version of >Mantis? > >I have > >$g_path = "http://omega:92/"; > >but mantis is outputting > ><link rel="stylesheet" type="text/css" href="http://omega\/css/default.css" >/> > >Is this a bug or am I doing something wrong. I looked into it. In my CVS version (current at the time of writing), the only way that could happen is if you had manually set $g_css_include_file. Have you? Jeroen ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Mantisbt-dev mailing list Man...@li... https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Jeroen L. <jl...@ca...> - 2002-10-29 22:04:26
|
At 21:54 29-10-2002 +0000, you wrote: >No - only set g_path and the email related ones. I'll have a thorough look >tomorrow. Take a look at how $g_css_include_file is being determined in config_defaults.php. That might be the problem. Jeroen |
From: Julian F. <ju...@be...> - 2002-10-29 22:20:34
|
I'm going to take a guess that this server is running on windows maybe? What is probably happening is that dirname( $_SERVER['PHP_SELF'] ) is evaluating to '\'. Now I can understand it evaluating to '/' if you were accessing it via http://omega/ but I don't quite understand how the backslash ends up there (you're not accessing it with http://omega\ are you??). anyway, even in this case we'd end up with http://omega//css/default.css which is not ideal... I can fix that. But this does raise another issue... if you override $g_path in your custom_config file, everything in config_defaults that uses $g_path has already used the old value. How did anyone think we'd solve this? We really need a lazy evaluation of the config file... sigh... Julian Jeroen Latour wrote: > At 21:54 29-10-2002 +0000, you wrote: > > > No - only set g_path and the email related ones. I'll have a thorough > > look > > tomorrow. > > > Take a look at how $g_css_include_file is being determined in > config_defaults.php. > > That might be the problem. > > Jeroen -- ju...@be... Beta4 Productions (http://www.beta4.com) |
From: Colin S. O. <co...@og...> - 2002-10-29 22:29:25
|
It is running on windows, and the custom config thing is probably whats causing it Another issue/problem is that the default config doesn't cope with port numbers as it is; if ( isset( $_SERVER['SERVER_NAME'] ) && isset ( $_SERVER['PHP_SELF'] ) ) { $g_path = 'http://' . $_SERVER['SERVER_NAME'] . dirname( $_SERVER['PHP_SELF'] ) . '/'; } else { $g_path = 'http://yourhostnamehere/mantis/'; } I could be mis-remembering my Environment Variables though... -----Original Message----- From: man...@li... [mailto:man...@li...]On Behalf Of Julian Fitzell Sent: 29 October 2002 22:20 To: man...@li... Subject: Re: [Mantisbt-dev] Using http://<server>:<port> I'm going to take a guess that this server is running on windows maybe? What is probably happening is that dirname( $_SERVER['PHP_SELF'] ) is evaluating to '\'. Now I can understand it evaluating to '/' if you were accessing it via http://omega/ but I don't quite understand how the backslash ends up there (you're not accessing it with http://omega\ are you??). anyway, even in this case we'd end up with http://omega//css/default.css which is not ideal... I can fix that. But this does raise another issue... if you override $g_path in your custom_config file, everything in config_defaults that uses $g_path has already used the old value. How did anyone think we'd solve this? We really need a lazy evaluation of the config file... sigh... Julian Jeroen Latour wrote: > At 21:54 29-10-2002 +0000, you wrote: > > > No - only set g_path and the email related ones. I'll have a thorough > > look > > tomorrow. > > > Take a look at how $g_css_include_file is being determined in > config_defaults.php. > > That might be the problem. > > Jeroen -- ju...@be... Beta4 Productions (http://www.beta4.com) ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Mantisbt-dev mailing list Man...@li... https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Julian F. <ju...@be...> - 2002-10-29 23:10:30
|
I committed a change that will hopefully help but I can't easily test it since my server is running on port 80 and on linux. Can you give it a try and let me know? Julian Colin S. Ogilvie wrote: > It is running on windows, and the custom config thing is probably whats > causing it > > Another issue/problem is that the default config doesn't cope with port > numbers as it is; > > if ( isset( $_SERVER['SERVER_NAME'] ) && isset ( $_SERVER['PHP_SELF'] > ) ) { > $g_path = 'http://' . $_SERVER['SERVER_NAME'] . dirname( > $_SERVER['PHP_SELF'] ) . '/'; > } else { > $g_path = 'http://yourhostnamehere/mantis/'; > } > > I could be mis-remembering my Environment Variables though... > > > -----Original Message----- > From: man...@li... > [mailto:man...@li...]On Behalf Of Julian > Fitzell > Sent: 29 October 2002 22:20 > To: man...@li... > Subject: Re: [Mantisbt-dev] Using http://: > > > I'm going to take a guess that this server is running on windows maybe? > > What is probably happening is that dirname( $_SERVER['PHP_SELF'] ) is > evaluating to '\'. Now I can understand it evaluating to '/' if you > were accessing it via http://omega/ but I don't quite understand how the > backslash ends up there (you're not accessing it with http://omega\ are > you??). anyway, even in this case we'd end up with > http://omega//css/default.css which is not ideal... I can fix that. > > But this does raise another issue... if you override $g_path in your > custom_config file, everything in config_defaults that uses $g_path has > already used the old value. How did anyone think we'd solve this? We > really need a lazy evaluation of the config file... sigh... > > Julian > > Jeroen Latour wrote: > > > >At 21:54 29-10-2002 +0000, you wrote: > > > > > >>No - only set g_path and the email related ones. I'll have a thorough > >>look > >>tomorrow. > > > > > >Take a look at how $g_css_include_file is being determined in > >config_defaults.php. > > > >That might be the problem. > > > >Jeroen -- ju...@be... Beta4 Productions (http://www.beta4.com) |
From: Colin S. O. <co...@og...> - 2002-10-29 23:28:57
|
Certainly seems to have worked with my testing. Colin -----Original Message----- From: man...@li... [mailto:man...@li...]On Behalf Of Julian Fitzell Sent: 29 October 2002 23:10 To: man...@li... Subject: Re: [Mantisbt-dev] Using http://<server>:<port> I committed a change that will hopefully help but I can't easily test it since my server is running on port 80 and on linux. Can you give it a try and let me know? Julian Colin S. Ogilvie wrote: > It is running on windows, and the custom config thing is probably whats > causing it > > Another issue/problem is that the default config doesn't cope with port > numbers as it is; > > if ( isset( $_SERVER['SERVER_NAME'] ) && isset ( $_SERVER['PHP_SELF'] > ) ) { > $g_path = 'http://' . $_SERVER['SERVER_NAME'] . dirname( > $_SERVER['PHP_SELF'] ) . '/'; > } else { > $g_path = 'http://yourhostnamehere/mantis/'; > } > > I could be mis-remembering my Environment Variables though... > > > -----Original Message----- > From: man...@li... > [mailto:man...@li...]On Behalf Of Julian > Fitzell > Sent: 29 October 2002 22:20 > To: man...@li... > Subject: Re: [Mantisbt-dev] Using http://: > > > I'm going to take a guess that this server is running on windows maybe? > > What is probably happening is that dirname( $_SERVER['PHP_SELF'] ) is > evaluating to '\'. Now I can understand it evaluating to '/' if you > were accessing it via http://omega/ but I don't quite understand how the > backslash ends up there (you're not accessing it with http://omega\ are > you??). anyway, even in this case we'd end up with > http://omega//css/default.css which is not ideal... I can fix that. > > But this does raise another issue... if you override $g_path in your > custom_config file, everything in config_defaults that uses $g_path has > already used the old value. How did anyone think we'd solve this? We > really need a lazy evaluation of the config file... sigh... > > Julian > > Jeroen Latour wrote: > > > >At 21:54 29-10-2002 +0000, you wrote: > > > > > >>No - only set g_path and the email related ones. I'll have a thorough > >>look > >>tomorrow. > > > > > >Take a look at how $g_css_include_file is being determined in > >config_defaults.php. > > > >That might be the problem. > > > >Jeroen -- ju...@be... Beta4 Productions (http://www.beta4.com) ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Mantisbt-dev mailing list Man...@li... https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Scott H. <ha...@ne...> - 2002-10-30 07:23:00
|
As long as we're on config_defaults_inc.php, I run my installation under SSL, and had problems with redirects to http instead of https until I got disgusted and locally changed the g_paths in config_defaults to https. A real solution might be something like this: if ( isset( $_SERVER['SERVER_NAME'] ) && isset ( $_SERVER['PHP_SELF'] ) ) { $t_protocol = ( $_SERVER['HTTPS'] ? 'https://' : 'http://' ); $t_host = $_SERVER['SERVER_NAME']; ... $g_path = $t_protocol . $t_host . $t_port . $t_path . '/'; } else { Scott On Wednesday 30 October 2002 00:09, you wrote: > I committed a change that will hopefully help but I can't easily test it > since my server is running on port 80 and on linux. Can you give it a > try and let me know? > > Julian > > Colin S. Ogilvie wrote: > > It is running on windows, and the custom config thing is probably whats > > causing it > > > > Another issue/problem is that the default config doesn't cope with port > > numbers as it is; > > > > if ( isset( $_SERVER['SERVER_NAME'] ) && isset ( $_SERVER['PHP_SELF'] > > ) ) { > > $g_path = 'http://' . $_SERVER['SERVER_NAME'] . dirname( > > $_SERVER['PHP_SELF'] ) . '/'; > > } else { > > $g_path = 'http://yourhostnamehere/mantis/'; > > } > > > > I could be mis-remembering my Environment Variables though... > > > > |
From: Julian F. <ju...@be...> - 2002-10-30 10:18:08
|
thanks, done Julian Scott Hanson wrote: > As long as we're on config_defaults_inc.php, I run my installation > under SSL, > and had problems with redirects to http instead of https until I got > disgusted and locally changed the g_paths in config_defaults to https. > > A real solution might be something like this: > if ( isset( $_SERVER['SERVER_NAME'] ) && isset ( $_SERVER['PHP_SELF'] > ) ) { > $t_protocol = ( $_SERVER['HTTPS'] ? 'https://' : > 'http://' ); > $t_host = $_SERVER['SERVER_NAME']; > ... > $g_path = $t_protocol . $t_host . $t_port . $t_path . '/'; > } else { > > Scott > > > On Wednesday 30 October 2002 00:09, you wrote: > > >I committed a change that will hopefully help but I can't easily test it > >since my server is running on port 80 and on linux. Can you give it a > >try and let me know? > > > >Julian > > > >Colin S. Ogilvie wrote: > > > >>It is running on windows, and the custom config thing is probably whats > >>causing it > >> > >>Another issue/problem is that the default config doesn't cope with port > >>numbers as it is; > >> > >>if ( isset( $_SERVER['SERVER_NAME'] ) && isset ( $_SERVER['PHP_SELF'] > >>) ) { > >> $g_path = 'http://' . $_SERVER['SERVER_NAME'] . dirname( > >>$_SERVER['PHP_SELF'] ) . '/'; > >>} else { > >> $g_path = 'http://yourhostnamehere/mantis/'; > >>} > >> > >>I could be mis-remembering my Environment Variables though... > >> > >> > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Mantisbt-dev mailing list > Man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev -- ju...@be... Beta4 Productions (http://www.beta4.com) |
From: Jeroen L. <jl...@ca...> - 2002-10-29 22:32:34
|
At 14:20 29-10-2002 -0800, you wrote: >But this does raise another issue... if you override $g_path in your >custom_config file, everything in config_defaults that uses $g_path has >already used the old value. How did anyone think we'd solve this? We >really need a lazy evaluation of the config file... sigh... Yes, I figured that earlier. The only 'easy' solution I can think of is to do: include(custom config) include(default config) include(custom config) Or something like that. That's an awful solution though :( Jeroen |
From: Colin S. O. <co...@og...> - 2002-10-29 22:36:52
|
And stil has the problem I set gpath (and only gpath) in custom You set gpath in default (and hence all the other stuff uses default's gpath) I change it again in custom Has the same problem... I suppose it would work if you did isset or similar. -----Original Message----- From: man...@li... [mailto:man...@li...]On Behalf Of Jeroen Latour Sent: 29 October 2002 22:32 To: man...@li... Subject: Re: [Mantisbt-dev] Using http://<server>:<port> At 14:20 29-10-2002 -0800, you wrote: >But this does raise another issue... if you override $g_path in your >custom_config file, everything in config_defaults that uses $g_path has >already used the old value. How did anyone think we'd solve this? We >really need a lazy evaluation of the config file... sigh... Yes, I figured that earlier. The only 'easy' solution I can think of is to do: include(custom config) include(default config) include(custom config) Or something like that. That's an awful solution though :( Jeroen ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Mantisbt-dev mailing list Man...@li... https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Jeroen L. <jl...@ca...> - 2002-10-29 22:48:34
|
At 22:36 29-10-2002 +0000, you wrote: >I suppose it would work if you did isset or similar. That's what I meant. Jeroen |
From: Julian F. <ju...@be...> - 2002-10-29 23:26:39
|
Yup, but until we can be sure that everyone has register_globals turned off, doing isset() on global variables is a huge no no. So, no it doesn't work. You might be right about the colon not being in there, Colin... I'll take a look. Julian Colin S. Ogilvie wrote: > And stil has the problem > > I set gpath (and only gpath) in custom > You set gpath in default (and hence all the other stuff uses default's > gpath) > I change it again in custom > > Has the same problem... > > I suppose it would work if you did isset or similar. > > -----Original Message----- > From: man...@li... > [mailto:man...@li...]On Behalf Of Jeroen > Latour > Sent: 29 October 2002 22:32 > To: man...@li... > Subject: Re: [Mantisbt-dev] Using http://: > > > At 14:20 29-10-2002 -0800, you wrote: > > >But this does raise another issue... if you override $g_path in your > >custom_config file, everything in config_defaults that uses $g_path has > >already used the old value. How did anyone think we'd solve this? We > >really need a lazy evaluation of the config file... sigh... > > > Yes, I figured that earlier. The only 'easy' solution I can think of is to > do: > > include(custom config) > include(default config) > include(custom config) > > Or something like that. That's an awful solution though :( > > Jeroen -- ju...@be... Beta4 Productions (http://www.beta4.com) |
From: Julian F. <ju...@be...> - 2002-11-12 05:37:53
|
Hi Christian, Just wanted to let you know that I'm looking at this patch now (I've been at a conference for the last week). There seems to be a bit of confusion between the definitions of custom fields and the values (selecting from the wrong table in several places, for example) and I'm taking a hard look at the naming of some of the functions. But once I've gone through all that I'll commit the file so we can continue working based on patches to that. I'll post again when I've done that (probably won't finish it until tomorrow... I'm going out shortly). Julian Chr...@he... wrote: > Hi, > > I've tried to include as may changes as possible that Victor and Julian > sent me. As I didn't have much time last week it might be that some > slipped by :( > Anyway, the results are attached. > > Probably now is a good time to get the stuff in CVS and try to resolve > the rest in there. Because then I could start to implement/modifiy the > web pages for the custom fields code and thus figure out limitations > and bugs of the api. > If there are only small issues left you might want to change them > yourself and check it in then. > > CU, > Christian > > PS: These changes have to go to the corresponding files. As they are > that small it doesn't make sense to send the whole file (and I don't > have diff on this machine...) > > > strings_english.txt > [...] > $MANTIS_ERROR[ERROR_CUSTOM_FIELD_DOESNT_EXIST] = 'ERROR: > Custom field does not exisit.'; > [...] > > constant_inc.php > [...] > # access levels > define( 'ANYBODY', 0 ); > [...] > # ERROR_CUSTOM_FIELD_* > define( 'ERROR_CUSTOM_FIELD_DOESNT_EXIST', 1300 ); > [...] -- ju...@be... Beta4 Productions (http://www.beta4.com) |