Invoking classes via Nested includes (php)
Posted by lifewater, 03-15-2007, 04:00 PM Hello, I apologize if this is a repeated question, but I did not see it while I was checking the first few pages. Here is my dilemma. I am trying to make a script using classes, and I'm having trouble getting the class to work. Here is my situation index.php is the main page, which includes a header (header.php) and then pulls data from my MYSQL database and displays it. header.php displays the header and links associated with index.php. header.php also includes a config.php while contains a class in it. This class loads some default variables in a constructor like so and echos them: For some reason index.php loads header.php, but header.php does not load config.php....therefore nothing gets echoed. Is this a limitation of php or something wrong with my coding?
Posted by gabeosx, 03-15-2007, 04:53 PM There's something wrong with your code (the part which we cannot see). I do not know of any limitation to nested includes in PHP...
Posted by lifewater, 03-15-2007, 06:27 PM I'm sorry, i realize this wasn't specific enough I have a small demo avaialble online for what i'm trying to do: 216.120.244.193/~lsdrift/test/index.php there are 6 files there: index.php, header.php, config.php, and the*.phps versions of each file so you can see my code. This is actually just a small example that im trying to do on a much larger scale, but I can't get it to work on a small scale either.
Posted by Engelmacher, 03-15-2007, 06:31 PM Why are you calling ob_start()? Better yet where's the semicolon after the call?
Posted by lifewater, 03-15-2007, 08:09 PM A long time ago I had a problem... that I can't seem to recall, and ob_start(); resolved it... so i ended up putting it in all the time and now I don't even know what I used it for :O Thanks for reminding me about the semicolon. I modified that file since it wasn't really necessary... but I still can't get it working. Any other advice?
Posted by Engelmacher, 03-15-2007, 08:56 PM The variables you're passing to echo are also completely invalid and probably being interpreted as undefined constants.
Posted by lifewater, 03-15-2007, 09:40 PM why are they invalid?
Posted by Engelmacher, 03-15-2007, 09:41 PM http://www.php.net/manual/en/language.variables.php
Posted by jvmombay, 03-15-2007, 10:56 PM try this on your config.php fooA="This"; $this->fooB="is"; $this->fooC="Broken"; echo $fooA ." ". $fooB." ". $fooC; } } ?> it runs on php4... though i haven't tested your "private" declaration on php5 but definitely won't run on php4.
Posted by Koobi, 03-16-2007, 11:36 AM i think it has to be: by the way, your echo statement will work like this as well (it might be easier for you to read statements like this ) because of the '$this->', you have to use the curly braces so that PHP doesn't throw a warning. before you used ob_* functions, did you recieve a message that said 'headers already sent'? if you were using PHP5, the 'var' in the class would have thrown a notice or a warning to the screen which would have in turn caused the 'headers already sent' error if you use the header() function or session_start(). even the echo would throw a notice because those variables are not defined. consider using error_reporting() like so: so that you don't see notices.
Posted by TonyB, 03-16-2007, 11:29 PM Very bad idea do not turn off notices... They can help you find potential issues that could arrise down the road. So for example We never declared $c and for some reason if say register globals was on well then someone could give c an undesired value of say 25 thus avoiding our loop assuming we assumed c would start at 0. Of course this can apply to vars where user input would never happen. I just can't think of any right now Generally speaking though notices are self explanitory and if not a quick search can tell you why. Trust me they are there for a reason
Posted by Engelmacher, 03-17-2007, 12:34 AM And that reason does not apply to code running on a production server unless you have custom error handlers that prevent the default messages PHP generates from being spewed all over the page.
Posted by Koobi, 03-17-2007, 02:18 AM I believe all error output sent to the screen should be disabled and custom error handlers deployed so that you have total control over what will render on the browser.
Posted by TonyB, 03-17-2007, 02:20 AM If you code it properly there will not be any messages. You get notices when you don't declare variables and other things you should not do that risk security are just a bad idea in general. If you are running in production change your error_reporting on the script level. In this case the solution to the notices is to simply turn them off rather than actually fixing them. That's just a bad idea
Posted by Engelmacher, 03-17-2007, 07:25 AM That's an interesting idea. So when your database server goes down or a proxy server spoofs a field in the request header in a nonsensical fashion you did not anticipate or some other external resource your script is dependent upon becomes otherwise unavailable do you not get any error messages or are you just so busy rolling your eyes that you don't see them?
Posted by TonyB, 03-17-2007, 01:39 PM Just a simple example here You can surpress a function based errors, check if it returned false or the unexpected value and display an error you want. Since database errors is one of the problems you mentioned I figured it was a good example. Plus if you don't want any errors in a production environment you turn all errors of completely not just notices.
Posted by Engelmacher, 03-17-2007, 05:41 PM It wasn't, but I'm sure whatever you're doing is fine for whatever it is you write.
Posted by horizon, 03-17-2007, 10:38 PM You could also use: to see if there's actually an established connection.
Posted by Koobi, 03-18-2007, 02:28 PM Talking from experience I can tell you that in case you want to view all the errors for some reason, it's not fun doing a global search and replace for the '@' sign. This is why I still believe that it's better to have absolute control over your output (and input ) because then, you can handle it according to what you wish to do with it, at the time.
Posted by horizon, 03-18-2007, 06:34 PM Then, let the codes speak for you:
Posted by TonyB, 03-18-2007, 07:49 PM I'm not sure what the purpose of removing them would be if you use them in the right situations. mysql query's, connections ect. If you want to see the error yourself down the road you just display the mysql_error. You could do this for the user even but still make it reasonably nice looking. Of course I bet people are using the @ for situations where they probably shouldn't. Like something stupid such as Rather than checking for valid values of say $b and $c someone just puts a @ infront! I'm not sure if str_replace will actually error on this situation but you get the idea. On top of the fact if you're using PHP 5 there is little point of whole @ all together. You want to catch errors all you do is use a try catch block. This way for errors you could throw back to your own exception class. This exception class could be set to have debug on which in turn will actually display errors for you. Thus users never see errors but in development you could quickly turn them on to see mysql errors, str errors or whatever.
Posted by Koobi, 03-24-2007, 05:54 PM taking the lowest common denominator into consideration, let's consider a case with PHP4. i code an application which runs into many files spanning a total of about 50,000 lines of code. about 20% of those lines are mysql_query() calls. i prepend all mysql_query() calls with the '@' sign. 3 months down the line, for some reason (which i can't think of right now ), i decide i want to see the raw mysql_query() error message. wouldn't this mean that i'd have to search for every instance of '@mysql_' and replace it with 'mysql_'? whereas, if i user error_reporting() to enable/disable my error display (you are right in saying errors should be displayed during development. i should have mentioned that), all you have to do is edit one file...perhaps a config file that is included in every page. it seems as though the pros of using error_reporting() outweigh the pro's of using the '@' sign in most typical cases.
Posted by horizon, 03-24-2007, 10:00 PM It would seems you're talking about the "@" for PHP commands and not for email address . . . If it can help anyone, I only use '@' sign when I'm not depending from PHP scripts that does not handle user levels. If so, then I only show server errors towards admin users rather than regular users. This way, visitors / users won't question webmasters regarding the site's maintenance. This technic does not take several days to build. Actually, it can be done from a class file that handles error results in matter of hours or so.
Posted by TonyB, 03-25-2007, 02:54 PM If you coded a PHP program that was 50,000 lines you would not be calling mysql_query everywhere. You'd be using a class to handle MySQL
Posted by Koobi, 03-25-2007, 03:12 PM that was merely an example. my point is, why use @ when it has more of a potential to cause difficulty in maintenance when you can use another method that is easier to handle? if you're very small app that's 4-5 scripts large, then you can suppress errors using @...although using error_reporting won't hurt here either. but if you're seriously building a large application, you have to think about maintenance. in most large projects, most of your time is consumed maintaining it (no matter how well you've planned/coded it) and adding features. and silly things like this can eat up valuable time. you can suppress errors using @, but it should be the last option or maybe second to handling errors the way PHP intends you to, using error_reporting which is why it exists. i guess we all have our own opinion based on our coding experience, but i find this method the easiest and if the fact that error_reporting is mentioned as the recommended method for handling errors in the PHP manual is anything to go by, it appears that the PHP dev community and I share the same opinion.
Posted by maxymizer, 03-25-2007, 03:35 PM An experienced (php) developer already knows what error might come up from functions that are used in the code. What you mentioned trough your posts is a perfect example of a person who codes large applications without using a framework or object oriented code to improve maintainability and readability. Talking about mysql_query() specifically, the only error you might encounter is "invalid resource id" in case you didn't establish a connection prior to calling mysql_query. And as TonyB said - as of PHP 5 you have try catch to handle your error control.
Posted by TonyB, 03-25-2007, 03:48 PM I'm not saying supress all errors by any means and it's a good concept to be turning off error reporting. However if we're working in an open source or commercial piece of software which basically means we don't know all configurations. We may very well not know the possible PHP limitations or even worse they modify the code or remove reporting. They could remove reporting due to maybe say mods. I'm working on a piece of software right now where this comes into play where the users may not want error reporting disabled due to additions they made. There are a few options that do not rely on error_reporting definition. The first being set @ on functions that can produce errors that we don't want to see or we may want to format them differently. The next is using set_error_handler and then formating them once again. In PHP5 we may want to use a try catch block to catch these errors.