i've set up all my php stuff on a new machine and i'm getting really lots of notices warnings.
my code is working properly without errors on my old machine.
eg. the following line (which should get a recordset value) will cause a notice:
$ID = $rs[id];
the reason is the missing quotes for the id fields, but also things like calling $_GET on a non-existing value will cause notices.
anyone knows what's the reason for this?
i'd love keeping the "simple" way of coding like on my old machine without having to hassle with quotes on recordsets or tons of isset() - any ideas?
thanks
The PHP installation in the new machine has a more robust configuration that shows notices, and not only errors. That's good. I would never write or accept in my server a PHP script that fires some notice.
This kind of "lazy" coding (forgive me, I want to help you!) brings to future issues (code is hard to read and to debug) and, indirectly, security concerns ("lazy" code is often flawed). Fix everything that fires up a notice. :)
And, if you can, learn some more advanced PHP: go for object-oriented programming, encapsulation, information hiding, etc... This is how things are done nowadays and they work better than before. Old PHP scripts, built around notice suppression and register_globals, were somewhat dump.
The reason for the notice is because you have an "undefined constant." If you do not put quotes around an intended string, php will treat it as a constant. If it's not defined, php treats it as a strong. Take the following example:
$array = array(
'one' => 'right'
, 'two' => 'wrong'
);
define('one', 'two');
echo $array[one]; //echoes "wrong"
Also, you will get a notice if you try to access a key in an array that is not defined (such as $array['three']; above). PHP is nice enough to do this for you as other languages will error out (or worse).
The notices are not just to bug you. They are to let you know there's a problem in your code that you should strongly consider addressing.
Sounds like your error reporting level differs between machines. Compare the error_reporting levels in your php.ini's across machines.
It sounds like you have a different error_reporting value set on the two servers. Check your php.ini and set accordingly.
Related
I have looked far and wide but haven't been able to find anything related to this specific situation, I am a backend developer and always write (something similar to):
if (!defined("something")) define("something", true);
instead of just
define("something"; true);
The second snippet will trigger a Notice if the file is included more than once. Similar situation with array indexes:
$data = array();
echo $data["does not exist"];
will trigger a notice, so my preferred way is to:
$data = array();
if (isset($data["does not exist"]) echo $data["does not exist"];
else echo "Missing info";
PHP has the ability to suppress these messages but I keep them enabled because I consider these checks good practice, but I lack the evidence to prove that they are needed and recently a coworker argued that there is no effect in coding without the checks.
Are you aware of any security implication in not writing the checks? or am I perhaps being paranoid and disabling the notices is acceptable?
PS: Not sure if this question is more suitable for StackOverflow but feel free to let me know and I'll try to move it.
Disabling notices during development is not acceptable, as it points out problems with your code. Ideally, your code should be able to run with the E_ALL, and E_STRICT error reporting levels, and still not report any errors. Exact details are dependant on the PHP version, documentation can be found here.
I do not think either option is more, or less insecure than the other, unless there is another security issue it may somehow be masking. I believe that either form is bad practice though.
When a site is in production it is important to only log errors, and set ini.display_errors off. Reducing the error reporting level in production may be useful if it is impossible to deal with code producing large amounts of certain errors, but that code should be rectified.
I do believe that code should avoid generating notices, it may be a "lesser" issue, but it is still an issue which should be taken care of at development time.
The correct way to avoid these errors is simply to avoid including files more than once. (See: include_once(), or require_once()) If you are using a framework, it likely includes a method to handle includes for you. Consult the relevant documentation, and ensure that you are using their implementation for including files.
Avoiding notices is a good practice.
Probably you should learn a little bit of defensive programming and follow The Right Way.
Hiding errors and notices during the development can cause serious problems in future.
Usually, notices tells you about bad programming style or non-obvious bugs, which tends to tricky bugs, unmaintainable code and security vulnerabilities.
Good code never produce notices and errors because it controls the situation when they can happens.
There are plenty of ways to handle errors and exceptions in system. I worked with plenty of frameworks and believe me they don't rely on display_errors and ini_config flags.
PHP has advance facility to handle errors and exception that generated by code using set_exception_handler and set_error_handler. So if you want to hide errors then you can turn off display_errors but you should put above two functions to log your errors.
Defensive programming is very useful if you want to sit back and relax after uploading work over production side.
Ruby and some other languages have a very convenient feature: symbols. They look like in-place constants. Now I wonder if the following approach by simulating symbols in PHP with an at sign before an unquoted string is a valid approach.
$array = [#key => "value"];
echo sprintf("%s PHP symbols with a %s\n", #testing, $array[#key]);
I understand there are certain drawbacks against formal constants and the like, which are same as for Ruby's symbols: consider typing errors. Are there any other considerations against using this approach?
If by "valid" you mean "can be run", then yes, it is a valid approach (but by that standard, it is also valid to make all of your strings into HEREDOC's). But simply because PHP will accept the syntax, does not mean that the syntax is without problems.
The first I can think of are that
You are actively suppressing an error, which costs processing time
Your co-workers will need an explanation as to what is going on, which costs developer time
You are working against the natural definitions of the language (PHP simply isn't Ruby)
Since you have to use a sigil for variables anyway, you're not actually cleaning the code.
You are suppressing an error (a notice, to be exact). not only this costs processing time as mentioned in cwallenpoole's answer, but also the error is there for a reason. The reason is:
Notice: Use of undefined constant hello - assumed 'hello' in ...
You are relying on some constant being undefined - which is exactly what the notice is trying to tell you. If a constant of that name is defined, you will grab its value instead.
In Ruby, :__LINE__ is something quite different from __LINE__. The former is a symbol - it equals itself no matter where you use it. The latter is a number, and a magical variable that changes its value on every line. In PHP, #__LINE__ is the same as __LINE__, because there is no error to suppress. Oh, and there's one special "symbol" that is extra-fun to debug: #exit, AKA #die.
In Ruby, you can use all sorts of symbols including operators and keywords. These (and many more) are all valid: :+ :* :< :<< :[] :[]= :while :case :x=. With a pair of parentheses, you can even use symbols like :case= and :while=. In PHP, none of these work. You'll end up with a parse error. It won't even be suppressed. The only exception is #[] in PHP 5.4, which produces an empty array. On the other hand, lots of PHP expressions are not valid Ruby symbols: #(1+1) === #2 #1 == #'1'
Ruby's symbols are not equal to anything else. This is the purpose of their existence. Sure, they have some nice properites like to_s and to_proc, but their original purpose is to serve as identifiers separate from any possible user input. This is sorta nice for example if you are using symbols to represent tokens in a lexer stream, such as [:lparen, 1, :plus, "rparen", :rparen]. In PHP, undefined constants are strings. In Ruby, ?test != "test". In PHP #test === "test" (assuming you dindn't define a constant named "test" to equal something else).
you can't even assume non-magic constants won't change. You can't even attribute to malice what can be explained with bad coding. Nothing like that is of worry in Ruby:
//in library code:
$this->status = #done; // bad
//outside library code:
define('done', "no"); // very bad
define(#done, "yes"); // even worse
echo #no; // prints "yes"
//in library code:
if($this->status == #done){
//won't execute
}
echo #die;
echo "this won't get printed!";
You shouldn't rely on constants being undefined, and you shouldn't use error suppressing to hide the error messages telling you that. You shouldn't use special notation to pretend two things are not equal when they are. Also, can you trust the users of your library to not redefine constants at runtime?
Warning:
The following answer contains analogies that are meant, purely to illustrate a point. Under no circumstances do I mean to even suggest you contemplate the possibility of someone (you or anyone else) actually sitting down and doing the things I mention. That way madness lies
Though other answers have explained the main issue with using #<str>, It supressing a notice, it's important to stress this a bit more.
When using the supressing # (of death) the notice does not magically dissapear it is still being issued. After a while logs will get clogged with notices, making it harder to find that one fatal error that could be in there. Even if there is no fatal error, it still slows the code down.
Why encourage people to write code that throws notices? Just because you like the ruby syntax? come on, if you don't like a language, don't use it. I know: legacy code, you have to... well then, do it, don't try to make it feel and look like Ruby. They're not the same language. Everything that reminds you of the fact that you're working with a different language should be seen like a tool. Different languages require different mindsets, and different ways of thinking about a problem.
Imagine writing Lisp, but change the syntax to SQL queries. How much bad code will that generate. The syntax forces you into an SQL mindset, whereas you should be thinking in functions.
But for God's sake, don't that way madness lies!! It's a fools errand, it's even worse than parsing HTML with regex. It'll make even Cthulhu cry like a little girl
Oh, and # not being used to supress errors once it's in common usage? Do you really believe that? So you expect a lot of people to write bad code, until some IDE plugin is released that doesn't complain about the abuse of the # sign. And then, you expect the PHP contributors to take notice, and find a new operator to supress errors?
Honestly. I don't want to be rude, but that's like expecting Microsoft to release the source of windows8, because some people have gotten used to linux being open source.
Another thing: As I said, suppressing notices isn't going to help you when debugging the code. It's well known that PHP has way to many functions (and reserved keywords) in its core/global namespace. If you, and your co-workers get in the habit of abusing the # operator, you could just end up with code like this:
$foo[#die] = [#exit, #constant];
Have fun debugging that onholy mess of unclear errors. Honestly...
The key in your code would be seen by PHP as an unknown constant.
In most languages this would halt the compiler, but PHP mutates it into a string in an effort to keep running. It throws a warning, but keeps going anyway. This is just bad, and you really don't want to be doing it, much less doing it deliberately.
# in PHP is for suppressing errors. It does nothing else.
Your #key will still be bad practice just as key would be and would function in exactly the same way, but the # will hide the error message that would normally be generated.
Using # error suppression in PHP is bad practice for a whole bunch of reasons (‡ see note below), but using it as a way to hide deliberately bad code is terrible. Please don't do this.
The fundamental point here is that you're using PHP, so you should write PHP code. Trying to write Ruby code in PHP is never going to work.
You should work with the language you're using, not against it.
‡ For some thoughts on why error suppression is bad practice, you may want to read this: Suppress error with # operator in PHP
One final thought: This thing of PHP converting unknown constants to a string exists in the language purely for legacy compatibility reasons; it's one of the really awful bits of bad language design that date back to the early days. A lot of the other bad stuff from early PHP has been deprecated in recent versions; this hasn't yet, but there's no good reason for it still to exist, so I kinda hope they find a way to deprecate this "feature" too. If they do, that will instantly stop your idea from working, regardless of any merits it may have.
I've inherited some legacy code, within which if I turn on:
error_reporting(E_ALL);
I get literally hundreds of messages all over our site, all of them like:
Warning: include_once() [function.include]: Failed opening '../inc/variables.php' for inclusion (include_path='.:/usr/local/lib/php') in /var/www/html/xyz/xyz/xyz/payment.class.php on line 9
Notice: Undefined index: validateArrayName in /var/www/html/xyz/xyz/xyz/payment.class.php on line 3417
Notice: Undefined variable: objInstructor in /var/www/html/xyz/xyz/xyz/classes/metatags_class.php on line 44
Is this a bad thing? The site works fine otherwise, but I'm wondering if its
(a) a really bad thing and
(b) even if not, is it worthwhile to go fix all these issues?
There is lots of things you cannot test from the UI of an application. Stuff that happens under the hood. Unless your application is fully Unit-Tested or Functional Tested, you are likely not seeing the whole picture by clicking yourself through it.
You should definitely look into the Warnings. The developer probably didnt include variables.php for fun, so you should double check that payment.php works as expected.
Notices are less severe but they are still indicators of sloppy code. Usually, they are not that hard to fix, so unless you are on a very tight budget, fix them.
You also might want to change error_reporting from E_ALL to -1. That will enable all erros plus E_STRICT errors and anything that might be added to PHP in later versions.
The site works fine otherwise
Hmm, the failing include_once() does not ruin anything? In that case (i.e., you're not using anything - variables, globals, functions - from ../inc/variables.php) just remove the line.
You can probably ignore notices ("ugly" code), but should keep an eye on warnings (missing functionality). For legacy code always balance effort and benefit. If it works (and you're willing to accept potential security breaches), let it run ... but phase it out over time. If you're not that confident, rewrite.
Try finding where the file ../inc/variables.php is present (it is not present at /var/www/html/xyz/xyz/xyz/inc/variables.php where it is supposed to be), since the file /var/www/html/xyz/xyz/xyz/payment.class.php is trying to include it. I have a hunch that this file contains the definitions (initializations) of all the variables you are seeing in the warnings.
If after including the correct variables.php file, you get the same 'Undefined variable' warnings, in my opinion there is no need to go and modify 'legacy code' to define all the variables.
See how it goes.
Are you sure your site works fine? Do you have a good unittest suite that's run regularly to make ABSOLUTELY sure?
Failed file includes are almost always bugs (or truly horrible coding practice). If your set ever does unexplained or weird things, these problems are likely the cause. If it really has so many problems, are you sure it wouldn't be faster to rewrite it in a clean, consistent, careful style?
In general, yes you should fix these problems if you intend to continue developing this code base. If it's an orphan project or you expect to rewrite from the ground up, don't bother.
I have turned on error_reporting(E_ALL) and run this code:
$topic_id = (int) safe_query($_GET['top_id']);
if($topic_id > 0)
include("topic.php");
And get this error: Notice: Undefined index: top_id. Is it that bad what I do? If yes then why? Should I check if $_GET['top_id'] isn't empty before I give its value to $topic_id? Why? Thank you.
One of the reasons why I do it is to prevent unexpected behaviours.
Code should always reflect the intention of the programmer. If a behaviour depends on some mysterious process in the background, eventually it will come and bite you in the ass when you are knee deep within bugs and debugging.
Traditionally, attempt to access an array with a key that doesn't exist causes a crash (probably in unmanaged environment) or an error. PHP silently 'fixing' this in background is great for beginners, but bad for debugging. Your code will work, but may give you unexpected result.
Take for example, your code. Say the calling page forget to specify the top_id, or misspelt it as topid, and PHP goes on its merry way. It didn't include topic.php, and nothing happens. The code works fine. PHP doesn't complain. What's wrong?
Now, your code is short. What happens when it is longer? Nested deep within many lines, between different functionalities? For your case it isn't a big deal, but when doing complex array manipulation it will make debugging harder.
I understand the question now. I'd suggest using isset just to be safe. I'm assuming you don't have a topic_id that is 0.
It's not really a problem here, since you only take action on it if it's set anyway. However, you're just lucky that the unset value evaluates to false. Also, it'd be annoying to continue having it give you the warning. You'd probably be best suited by doing what others have suggested, checking if it's set before using it. It might be easiest to just set up a function that does that, especially if you're going to be checking a lot of GET parameters.
Whatever you do, don't just turn the warning level down to suppress the warning; in this case, it doesn't hurt to assign from the unset variable, but in the future it could indicate an actual error.
"And get this error ... Is it that bad what I do?"
Well, it's not giving you an Error. It's giving you a Notice. Notices are "ignored" (that is, not echoed) on production servers.
Essentially, PHP is telling you what Extrakun is saying in his answer. You should take notice to a potential mistake that could lead to a real error later.
So, "Is it that bad what I do?" ... maybe not. But, then again, PHP is also not giving you an error. It is giving you the right amount attention that the code segment deserves - a Notice.
I changed the option in the Joomla configuration section to show all errors (E_ALL) and my component is basically unusable.
As an example, in a view (editapp) I have a template, default.php, which contains things like:
<input class="text_area" type="text" name="application_name" id="application_name" size="50" maxlength="250" value="<?php echo $item->application_name" ?> />
Now because of $item->application_name when I run this the first time (a new record), there will be notice errors everywhere Trying to get property of non-object
This is because the same template is used for saving and editing. I followed tutorials and they seemed to do it this way.
What is the go here with PHP development. Should I be checking these things? if(isset($item-)) {...}, what is the best practice for PHP development?
I agree with the others - go for no errors. In fact, I suggest going beyond E_ALL and adding in E_STRICT, which is how I do all my development. There are good reasons for each of those notices, and you'll do well to be rid of them. The most notable reason is that the notices typically point out small bugs that can make it much harder to find and fix bigger bugs down the road. It's not too different from the idea of using assertions: they help you squish bugs as quickly as possible.
As to your specific example, rather than using isset() right before referencing it, I recommend initializing the object to a sane base state going into the page (perhaps using isset() at that point). For example, you might set the application_name value to an empty string. This will enable you to keep your output statement nice and clean but properly address the notice by making sure the variable is initialized before using it. (FWIW, in many languages, using unitialized variables causes an even more aggressive response in the form of a compile-time error.)
It is absolutely worth getting rid of the errors and warnings in your code for a couple reasons:
Every error gets written to the error log. If they're inconsequential, you've polluted your error log with information that's in no way helpful.
Most warnings are indicative of bigger errors. The unset variable you're referencing can cause problems down the road in situations you may not have thought of.
Others who are using your template may not have the ability or knowledge to turn off errors, resulting in them not using your code.