From: Pierre-Alain J. <pa...@pe...> - 2003-02-11 01:21:41
|
Hello, New to this list and new user of phpwebsite, I'm starting an evaluation of CMS available for php. One of your developer (sorry, I do not find back his name) discussed about phpwebsite on pear ML and that sounds like something cool for me, so here I am :). Before I run to far in fixes in the setup script, have you successfully tested the current RC4 with error_reporting(E_ALL) and register_globals Off ? I got a lot of errors due to these two settings. Most of errors can be solved by a safe (isset($myvar) && $myvar==123) or even initialize a default value for each variable. A second error is the wrong way to check if a DB::connect successed or not, instead of checking the message ($db->message), there is a DB:isError($db): if(DB::isError($db)){ echo 'foobar '.$db->message; } I would like to continue my tests but I actually do not have a lot of times to debug/fixes others things then the setup itself. If the application itself works well with the above settings, I can try to fix the setup scripts. Otherwise, I like to see an application using PEAR, so I will try anyway to fix it later :), if that helps. Thank's for your great job, pierre |
From: Pierre-Alain J. <pa...@pe...> - 2003-02-11 01:51:10
|
On Tue, 11 Feb 2003 02:21:15 +0100 Pierre-Alain Joye <pa...@pe...> wrote: > Hello, > I answer myself, clearly no :(. Is it in your TODO ? hth pierre |
From: Matthew M. <ma...@tu...> - 2003-02-11 12:38:05
|
> New to this list and new user of phpwebsite, Welcome :) > Most of errors can be solved by a safe (isset($myvar) && $myvar==123) or > even initialize a default value for each variable. We will be more mindful of this in the future. > A second error is the wrong way to check if a DB::connect successed or > not, instead of checking the message ($db->message), there is a > DB:isError($db): > if(DB::isError($db)){ > echo 'foobar '.$db->message; > } An error class is in the making. It should incorporate the above. > I would like to continue my tests but I actually do not have a lot of > times to debug/fixes others things then the setup itself. No problem. Every little bit helps. Matthew McNaney Internet Systems Architect Electronic Student Services Appalachian State University Phone: 828-262-6493 phpwebsite.appstate.edu ess.appstate.edu |
From: Adam M. <ad...@tu...> - 2003-02-11 14:59:00
|
> New to this list and new user of phpwebsite, I'm starting an evaluation > of CMS available for php. One of your developer (sorry, I do not find > back his name) discussed about phpwebsite on pear ML and that sounds > like something cool for me, so here I am :). That was me being annoying and posting over and over on the PEAR mailing list about the HTML Template stuff, Pierre :) > Before I run to far in fixes in the setup script, have you successfully > tested the current RC4 with error_reporting(E_ALL) and register_globals > Off ? I got a lot of errors due to these two settings. > > Most of errors can be solved by a safe (isset($myvar) && $myvar==123) or > even initialize a default value for each variable. I'll talk with the team here and look into fixing these types of issues. Should be more tedious than hard really. > A second error is the wrong way to check if a DB::connect successed or > not, instead of checking the message ($db->message), there is a > DB:isError($db): > if(DB::isError($db)){ > echo 'foobar '.$db->message; > } I will be revisiting all the core classes when I get some time on my hands. The goal there is to 'unhook' the core classes since the current inheritence structure really has no meaning. In the process I will be checking the usage of the PEAR DB package as well as other packages relied on in the core. I have more experience now with pear and feel confident I can accomplish this with relative ease. > I would like to continue my tests but I actually do not have a lot of > times to debug/fixes others things then the setup itself. If the > application itself works well with the above settings, I can try to fix > the setup scripts. Otherwise, I like to see an application using PEAR, > so I will try anyway to fix it later :), if that helps. Just an fyi to you and everyone else on the list. A new installer is on the horizon for phpwebsite. It may be finished by next release, it may not. It will be completely stand alone from phpwebsite itself so it can be released at any time, independent of the phpwebsite releases. > Thank's for your great job, Thanks for visiting our mailing list Pierre :) Adam --------------------------------------------------------------------- Adam Morton Developer - Electronic Student Services http://phpwebsite.appstate.edu Founder - Appalachian Linux Users Group http://alug.appstate.edu |
From: Matthew M. <ma...@tu...> - 2003-02-17 14:36:12
|
> Before I run to far in fixes in the setup script, have you successfully > tested the current RC4 with error_reporting(E_ALL) and register_globals > Off ? I got a lot of errors due to these two settings. Steven and I are in the process of fixing ALL warning messages associated with having error_reporting on full (<whine> there are many). Check CVS today for many of the fixes. As for register_globals, we decided a long time ago to write the code with them turned off. So that should not be a problem. I am more worried about how much we have run the code with it turned on, but I will check that as well. Matthew McNaney Internet Systems Architect Electronic Student Services Appalachian State University Phone: 828-262-6493 phpwebsite.appstate.edu ess.appstate.edu |
From: Don S. <do...@se...> - 2003-02-18 04:10:07
|
This should probably serve notice to all of us "outside" module developers to test your modules with the maximum error_reporting that the law allows. Unless you're in Texas. They have crazy laws. Don. On Mon, 17 Feb 2003, Matthew McNaney wrote: > > Before I run to far in fixes in the setup script, have you successfully > > tested the current RC4 with error_reporting(E_ALL) and register_globals > > Off ? I got a lot of errors due to these two settings. > > Steven and I are in the process of fixing ALL warning messages associated > with having error_reporting on full (<whine> there are many). Check CVS > today for many of the fixes. > > As for register_globals, we decided a long time ago to write the code with > them turned off. So that should not be a problem. I am more worried about > how much we have run the code with it turned on, but I will check that as > well. > > > Matthew McNaney > Internet Systems Architect > Electronic Student Services > Appalachian State University > Phone: 828-262-6493 > phpwebsite.appstate.edu > ess.appstate.edu > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > > > |
From: Don S. <do...@se...> - 2003-02-18 05:24:20
|
With max error_reporting, I'm getting "Undefined index" notices for all my translation phrases. PHP says the error occurse on line 412 of mod/language/class/Language.php for each of them. This in cvs checkout around 11:15 PM Central. Is this something the module needs to take care of or is it a Language mod issue? Don. On Mon, 17 Feb 2003, Don Seiler wrote: > This should probably serve notice to all of us "outside" module developers > to test your modules with the maximum error_reporting that the law allows. > Unless you're in Texas. They have crazy laws. > > Don. > > On Mon, 17 Feb 2003, Matthew McNaney wrote: > > > > Before I run to far in fixes in the setup script, have you successfully > > > tested the current RC4 with error_reporting(E_ALL) and register_globals > > > Off ? I got a lot of errors due to these two settings. > > > > Steven and I are in the process of fixing ALL warning messages associated > > with having error_reporting on full (<whine> there are many). Check CVS > > today for many of the fixes. > > > > As for register_globals, we decided a long time ago to write the code with > > them turned off. So that should not be a problem. I am more worried about > > how much we have run the code with it turned on, but I will check that as > > well. > > > > > > Matthew McNaney > > Internet Systems Architect > > Electronic Student Services > > Appalachian State University > > Phone: 828-262-6493 > > phpwebsite.appstate.edu > > ess.appstate.edu > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Phpwebsite-developers mailing list > > Php...@li... > > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > > > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > > > |
From: Matthew M. <ma...@tu...> - 2003-02-18 12:51:40
|
> With max error_reporting, I'm getting "Undefined index" notices for all > my translation phrases. PHP says the error occurse on line 412 of > mod/language/class/Language.php for each of them. This in cvs checkout > around 11:15 PM Central. Thanks for the line number :) It is fixed. Matt -- Matthew McNaney Internet Systems Architect Electronic Student Services Appalachian State University Phone: 828-262-6493 phpwebsite.appstate.edu ess.appstate.edu |