In my xampp it returns the following error, when i call functions without quotes ($_SERVER[SERVER_NAME])
Notice: Use of undefined constant SERVER_NAME - assumed 'SERVER_NAME'
What i must change in php.ini to correct this?
Thanks
UPDATE:
:) Sure i know, that if i add quotes, it will work, but i need to configure server to work without quotes too.
I clearly specify my problem. In my server it returns no warnings and no errors, if i do not use quotes. It is depend on xampp version. Now i install newer version of xampp on my local machine, and it show that notices, so i can't use my last projects, because there are handreds of that notices. (it returns such notice even when i use my defined variables, for example $myVariable[myItem]).
i can use
error_reporting(0)
But that will hide all errors. So i need to just specify new rules for my server, or use older version.
So, Why the downvotes?
Edit your php.ini to disable reporting of notices. find your php.ini by doing phpinfo()
error_reporting = E_ALL ^ E_NOTICE
Or do it in the script
<?php
error_reporting(E_ALL ^ E_NOTICE);
also consider setting display_errors = Off for live websites.
It's not constant, its an associative index. Use quotes:
$_SERVER['SERVER_NAME'];
Edit: If this is on a production environment and you simply need to hide these messages to buy you time to correct the real issue, add this to your page:
// Turn off all error reporting
error_reporting(0);
Don't change the configuration to fix your bad coding habits. This is what you should do:
$_SERVER['SERVER_NAME']
not this
$_SERVER[SERVER_NAME]
You could set the error level to ignore warnings, but you might miss some other important warnings if you do that. Just do it the proper way.
Don't change your php.ini, change your code:
$_SERVER['SERVER_NAME']
Also that is not called calling a function. $_SERVER is an associative array
Update
You must be able to add the quotes, suppressing those warnings is a very bad idea. That warning is basically a message saying "Your code is invalid, but I figured out what you meant soooo... you're lucky!". You won't always be that lucky if you choose not to use quotes.
The answer is that the boys that wrote PHP decided to change it for the sake of consistency in the PHP internals, ignoring the usability consequences to PHP programmers, and now you have to live with it. So you face the tough choice of either turning off all notifications or updating all your PHP defines.
PHP4 allowed the definition of unquoted constants and it was no problem. But I import perfectly good PH4 code to PHP5 and it breaks for no other reason than "you're a bad programmer".
If the authors of PHP wanted to do something truly useful then how about a notice for when a variable that has not been set (i.e. used as an lvalue in an expression) is used. I've had to deal with hundreds of bugs caused by misspelled variable names being allowed without any warnings from PHP.
Related
Is there a lint for Elixir (like for Javascript) which checks that every function has a type specification?
There is an Erlang compiler switch, +warn_missing_spec, which does this, but I'm having trouble getting it to work with Elixir at the moment, I think there is a bug with it's parsing of the ELIXIR_ERL_OPTS environment variable which is converting +warn_missing_spec into -warn_missing_spec which isn't a valid compiler option. I'm going to open an issue on the tracker, but thought you might like to know that this does indeed exist.
EDIT: As José mentioned below, the correct flag is ERL_COMPILER_OPTIONS. You can enable the missing spec warning during compilation by doing the following:
ERL_COMPILER_OPTIONS="warn_missing_spec" mix compile
Keep in mind you may get superfluous warnings from Elixir itself, for functions like __MODULE__. It should still be useful though. One last thing to note, I discovered this morning that there is a problem using this flag with mix compile, and that it's currently only warning about mix.exs. This is being fixed, and may even be fixed by the time you see this, but it's something to be aware of.
We are trying to use grunt-lesslint in our project, as our UI developer is comfortable fix errors in less file. grunt-recess seems more powerful but not sure if it can point errors in less file itself. I am unable to comprehend enough from lesslint page, and there do not seem to be many examples. Does anyone know the following:
How to prevent lesslint from displaying on the console. I use formatters and the report file is generated, but it also prints on console, which I do not want to.
How to make lesslint fail only in the case of errors (not warnings). Also csslint seems to report errors also, while lesslint mostly gives warnings only, why is that so? Does lesslint throw errors as well? How to make it fail only in case of errors?
I tried using 'checkstyle-xml' formatter, but it does not seem to use it (I have used in jshint and it gives a properly formatted xml, which it does not give for lesslint).
Is it possible to compile less (many files or directories) in conjunction with lesslint? Any example?
Thanks,
Paddy
I'd say it's more of a common practice to display stdout for this kind of thing; the JSHint plugin does it, as does any other linting plugin that I've used. If you get in another developer that uses Grunt they'll probably expect stdout too. If you really want to override this, use grunt-verbosity: https://npmjs.org/package/grunt-verbosity
Again, this is a convention in Grunt; if a task has any warnings then it fails. The reason being if you lint a file and the linter flags something up it should be dealt with straight away, rather than delay it; six months time you have 500 errors that you haven't fixed and you're less likely to fix them then. Most linting plugins allow you to specify custom options (I've used CSS Lint and that is very customisable), so if you don't like a rule you can always disable it.
This should work. If there's a bug with this feature you should report it on the issue tracker, where it will be noticed by the developers of the plugin. https://github.com/kevinsawicki/grunt-lesslint/issues
Yes. You can set up a custom task that runs both your linter and compile in one step: something like grunt.registerTask('buildless', 'Lint and compile LESS files.', ['lesslint', 'less']); note that you'll have to install https://github.com/gruntjs/grunt-contrib-less to get that to work. Also note that, failing linting will not compile your LESS files; mandate that your code always passes the lint check; you'll help everyone involved in the project.
I am trying to trim the leading "the" in a query that returns the titles of articles in Joomla, so that results are displayed in alphabetical order and the leading "the", if present, is disregarded. The module responsible for this is the Article Category (which is Joomla core module) and the file I think I should modify is helper.php in modules/mod_articles_category.
I replace the following line:
$articles->setState('list.direction', $params->get('article_ordering_direction',
'ASC'));
With this:
$articles->setState('list.direction', $params->get('article_ordering_direction',
'TRIM(LEADING \'THE \' FROM a.title) ASC'));
However, if I enable the debug mode, the TRIM is not showing. SO I guess, that I need to make the change somewhere else. Sorry but I am not familiar with Joomla so don't really know where this query is coming from. Any pointer is very much appreciated.
Okay, the short answer is no, I don't believe you can modify a query from a module, just like this. I haven't worked with modules, but I have some experience with components, so I would suggest two approaches:
Try to query the database yourself from the module, not by using setState, but building the query yourself.
You can cheat. Since Joomla has already done the heavy lifting for you, you could just manipulate the result object (i.e. $list) rearranging it and stripping off whatever you don't want. I would also suggest that you treat your code as a layout override, that way you'll be able to update your site without overriding the changes you have made.
I'm very keen to update a number of our servers to PHP 5.3. This would be in readiness for Zend Framework 2 and also for the apparent performance updates. Unfortunately, i have large amounts of legacy code on these servers which in time will be fixed, but cannot all be fixed before the migration. I'm considering updating but disabling the deprecated function error on all but a few development sites where i can begin to work through updating old code.
error_reporting(E_ALL ^ E_DEPRECATED);
Is there any fundamental reason why this would be a bad idea?
Well, you could forget that you set the flag and wonder why your application breaks in a next PHP update. It can be very frustrating to debug an application without proper error reporting. That's one reason I can think of.
However, if you do it, document it somewhere. It can save you a couple of hours before you remember setting the flag at all.
If you haven't already you should read the migration guide with particular focus on Backward Incompatible Changes and Removed Extensions.
You have bigger issues than deprecation. Ignoring E_DEPRECATED will not suffice. Because of the incompatible changes there will also be other type of errors or, maybe, even worse, unexpected behaviors.
Here's a simple example:
<?php
function goto($line){
echo $line;
}
goto(7);
?>
This code will work fine and output 7 in PHP 5.2.x but will give you a parse error in PHP 5.3.x.
What you need to do is take each item in that guide and check your code and update where needed. To make this faster you could ignore the deprecated functionality in a first phase and just disable error reporting for E_DEPRECATED, but you can't assume that you will only get some harmless warnings when porting to another major PHP branch.
Also don't forget about your hack and fix the deprecated issues as soon as possible.
Regards,
Alin
Note: I tried to answer the question from a practical point of view, so please don't tell me that ignoring warnings is bad. I know that, but I also know that time is not an infinite resource.
I presume you have some kind of test server? If not, you really should set one up and test your code in PHP 5.3. If your code is thoroughly Unit Tested, testing it will take seconds, and fixing it will be fairly quick too, as the unit tests will tell you exactly where to look. If not, then consider making Unit Testing it all a priority before the next release, and in the meantime go through it all, first with E_DEPRECATED warnings disabled and fix anything which comes up, then with it re-enabled once you have time. You could also run a global find-and-replace for easier to fix errors.
I'm working in an embedded system (RTXC) where I need to disable the debugger functionality which is enabled through a #define command. However, when I change the #define to undefine, compilation goes off fine, but when the linker runs, it encounters an error about a symbol not existing that belongs to the debug code (which should have been taken care of by the debugger variable not being defined). Is there any way for Make to ensure that a preprocessor variable does not get defined or stays undefined ?
The answer to your question is no, Make can't absolutely prevent a variable from being defined by, say, a #define expression in the code.
You seem to have an elusive problem. It could be a bug in your Makefiles, a misspelled directive, a bad macro (if you'll pardon the tautology) or something trivial. I'd suggest burning the forest: cut out everything until the problem stops, then see where it was hiding. If you get down to HelloWorld and the problem persists, let us know.
No. You will need to fix the bug in your code.
More specifically, there is something that is referencing the debug side of things outside of an #ifdef. Make won't be able to help you there.
Another possibility is that you have a .o or something left over from a previous build; you might want to try cleaning the build tree.