Just a curious question.
I noticed that when you generate a non fatal php error,
<b>Warning</b>: implode() [<a href='function.implode'>function.implode</a>]: Invalid arguments passed in...
but the links are nonsense.
If they are going to link it why do they not link it to the php manual?
or is there someway you can reroute the errors yourself?
There are 3 php.ini settings that control this behaviour
By setting html_errors = 0 no links will be created.
The value of docref_root will be prependend to those URLs, value could be http://www.php.net or some other url more suitable for you. For example http://www.php.net/function.implode is a valid url.
Finally, there is docref_ext, which - if it exists - must start with a dot and this will be appended to the link. Useful if you need to add for example ".html" to the end of the links.
Good starting point in the documentation for all 3 is: http://www.php.net/manual/en/errorfunc.configuration.php#ini.html-errors
As for why - it makes it easier for beginner developers to figure out what any given error means.
My guess? So that the PHP developers can right-click and use "Copy Link" or the like to copy certain things out of errors rather than having to worry about highlighting the right text.
Related
I have to make a template in the TinyButStrong language, but I have no access to the PHP side. I'm just able to modify my template and to upload it on my ERP.
Anyway, the PHP side is working well.
I tried to put an if statement in my ODT template file, but when rendering it doesn't work.
My condition:
[if [tab.product_type]!=1; then ‘[tab.product_ref]’; else ‘0’; block=table:table-row]
I verified value of tab.product_type, and the value is 0 or 1.
I tried many syntaxes, but none is working well. The only thing that it shows is:
.
Where did I make a mistake? I really don't understand, because I tried many syntaxes and I still get this line.
Little update :
I saw that the "when" is more adapted to this usage.
I found a syntax but I'm still having bad results. I made this :
[tab.product_ref;block=table:table-row;when [tab.product_type]!=1]
Anyway, it's giving me lines where tab.product_type is 1.
Why ?? I really don't understand how this language works...
I'm having the weirdest issue. I've tried referencing other similar answers here, but none seem to fix my issue.
I have the following regex in PHP
/if\s+(?:(.*?)\s*==\s*(?:UrlStatus|DeadURL)|in_array\s*\((?:UrlStatus|DeadURL),\s*(.*?)\s*\))\s*then\s+local\s+arch_text\s+=\s+cfg.messages\['archived'\];(?:(?:\n|.)*?if\s+(?:(.*?)\s*==\s*(?:UrlStatus|DeadURL)|in_array\s*\((?:UrlStatus|DeadURL),\s*(.*?)\s*\))\s*then\s+Archived = sepc \.\.)?/im
It's a messy regex I know, it's supposed to parse code from a module of various versions from different location. It works perfectly in regex101, but preg_match returns false, indicating an error occured. The regex you see is pulled straight from a var_dump. Also pulled from the var_dump is the string being tested. I have included the excerpt that is supposed to match it below.
if is_set(ArchiveURL) then
if not is_set(ArchiveDate) then
ArchiveDate = seterror('archive_missing_date');
end
if "no" == DeadURL then
local arch_text = cfg.messages['archived'];
if sepc ~= "." then arch_text = arch_text:lower() end
Archived = sepc .. " " .. substitute( ```
In the full block of text it takes 81,095 steps to match.
Could it have something to do with that?
Getting a read from preg_last_error(), it returned 6, which maps to the constant PREG_JIT_STACKLIMIT_ERROR.
PHP 7 uses a JIT compiler for preg_match with a small stack size limit. Disabling it allows preg_match to do its job.
This can be done in the php.ini file, or on the fly in the script by using ini_set( 'pcre.jit', false );
I'm working on an e-commerce site as part of an online PHP class at Treehouse.com. I ran into an issue where one of the menu items was displaying incorrectly as can be seen here: http://herkuhleez.com/shirts4mike/
Upon looking for an answer in their forums, another student concluded it was an issue with the newer versions of PHP as the older versions had no display issues with the exact same code as seen here: http://cheetahcandy.com/shirts4mike/
The first example (with the error) is running PHP version 5.4.24 and the second one is running 5.2.17. My localhost server is running 5.5.6 and I have the same error as the first example.
This student however discovered a work around in newer versions by simply changing any php variable names that are the same as the css selector names, at least when the php is written inside a tag's class attribute.
My QUESTION is: Is this a bug in these newer versions of PHP or is this working as intended as some sort of auto-correct function?
EDIT* Here is the forum discussion over at Treehouse: https://teamtreehouse.com/forum/build-a-simple-php-application-adding-active-states-to-the-navigation-php-versions
If you have a look at your CSS on the site with the error, you will notice that your class .section.shirts has the following css on line 605 of style.css
padding-bottom: 42px;
background: #fff
Funnily enough if you take both of those out, it looks exactly the same as the other website.
In addition, the class also has an error in it:
shirts <br /> <b>Notice</b>: Undefined variable: section in <b>/home4/herkuhle/public_html/shirts4mike/inc/header.php</b> on line <b>17</b><br />
I would have a look at header.php on line 17 to see what is causing that.
MORE INFORMATION
EDIT: This question seems to relate to a predefined project available at an educational site. The OP seems to be confused as to why the exact same code fails on some servers, and seems to work others. They were thinking it was something to do with the PHP version. It is more likely as a result of the suppression of warnings server side. To suppress warnings you could simply add:
error_reporting(E_ERROR | E_PARSE);
However; it would be far better to define or test the variable properly [in this case $section] and not simply mask the issue.
Using a PHP variable called $section along with a CSS selector of the same name will work
..Just because you can do something, doesn't mean you should..
Anyway, it is not a CSS error per se, but it certainly doesn't help in this circumstance.
Take note that the error/warning in your code has the word section in it:
<li class="shirts <br /> <b>Notice</b>: Undefined variable: section .....">
Both examples have a CSS style called section.shirts:
.section.shirts {
background: none repeat scroll 0 0 #FFFFFF;
padding-bottom: 42px;
}
As a result of the placement of the error/warning, most browsers will interpret your class as to include any of the words found within the quotes (eg; shirts undefined section etc) and apply them all as styles if found in your CSS. In your version of the page, as a result of the placement of the error, you are applying the styling above. The other site does not have an error/warning with the word section within double quotes inside a class so it does not apply that particular styling.
There is no correlation between PHP variables and CSS selectors (read: There is no conflict between PHP Variables and CSS Selector Names/variables in current, older or dare I say it, future versions of PHP) with the same name unless you generate an error in your resultant HTML in an unfortunate position. In this case, you have done this by creating an error between double quotes inside a class.
Fix your error and your styling will apply as expected. No bug here (other than line 17 in your code :)
Without seeing your code, to fix your error/warning:
[Unlikely] Maybe add a $ in front of section where applicable in your code if it is missing somewhere (like this $section)
Maybe ensure you are defining $section before you test it in your if statements
Maybe Use isset when testing $section if you don't know if it was previously initialized.
So in summary, the word section is rendered inside your HTML within an error/warning and interpreted as part of your CSS class structure as discussed.
Why does it work on older versions of PHP?
If you are wondering why it works in other environments, have you considered that maybe it has nothing to do with the PHP Version - Perhaps in other environments with the same error/warning, they have configured PHP to suppress the display of errors and or warnings.
Without the error, the word section would not appear inside your class; ergo - no style issue.
From the PHP Manual:
Relying on the default value of an uninitialized variable is
problematic in the case of including one file into another which uses
the same variable name. It is also a major security risk with
register_globals turned on. E_NOTICE level error is issued in case of
working with uninitialized variables, however not in the case of
appending elements to the uninitialized array. isset() language
construct can be used to detect if a variable has been already
initialized.
For more information about your particular error, see this previous answer.
Just have a look in your HTML markup and you 'll recognize the following php notice:
<b>Notice</b>: Undefined variable: section in <b>/home4/herkuhle/public_html/shirts4mike/inc/header.php</b> on line <b>17</b>
Just have a look in your header.php file around line 17. Your problem is a follow up of this php notice. Looks like a css class isn 't defined properly.
Basically, php -l does not detect any syntax error, given this code:
<?php
date®;
?>
Obviously, it's an error when you execute it.
Is there any alternative or additional linter to use for PHP?
EDIT:
Thanks alot guys. Apparently it is a valid constant name, as the documentation suggests ([a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*).
It only errors because you haven't a constant definition for date®
If, somewhere in another script file before an include of your test file you have:
define('date®','Value');
this would be valid (albeit meaningless) and would run without error
So syntactically this file is valid, and a lint check duly reports it as such
What you are looking for is php_check_syntax (http://php.net/manual/en/function.php-check-syntax.php).
Let me correct my answer. It will not detect the latter code as an error (as noted in the comments, this isn't erroneous code). Though, you should stick with the latter function if you want to check file for errors.
I'm trying to get some PHP example code to work on PHP version 5.3.4, Apache 2.2.17 on Windows.
The example says I need PHP 4.0 and above with CURL and contains:
<?
$function = $_GET['function-if-exist'];
$test = "Test";
?>
<? =$test ?>
I don't understand why I'm getting the following errors:
My PHP doesn't understand <? and wants <?PHP instead.
My PHP doesn't like <? =$test ?> and wants something like
<?PHP echo $test ?>
$function = $_GET['function-if-exist']; causes the error "Undefined index" but presumably works for the folks that developed it.
Can anyone help me understand why their code is not working for me?
1) <? is the "short tag". Most servers are configured to not allow short tags. This can be changed in php.ini.
2) Again, short tags. Also I think you can't have a space before the =, but the main problem is the short tags setting.
3) $_GET accesses the query string, so when loading your script you need myscript.php?function-if-exist=something
It is more ideal to check if the parameter is set before continuing to prevent errors being thrown, e.g.
if(isset($_GET['function-if-exist']))
{
$functionexists = $_GET['function-if-exist'];
}
the short tag notation is disabled in your php.ini
you need to remove the space before your equal sign
your _get array contains not the expected index, what url do you enter to access the page?
I don't understand why I'm getting the following errors:
My PHP doesn't understand
To be able to use short tags you will have to enable them via config ... http://www.tomjepson.co.uk/tutorials/35/enabling-short-tags-in-php.html
My PHP doesn't like and wants something like
Once you switch on the short tags you will be able to echo using ... important the equals signs must be touching the ? not variable.
$function = $_GET['function-if-exist']; causes the error "Undefined index" but presumably works for the folks that developed it.
The $_GET is populated according to what is in the url. To get a value in $_GET['function-if-exist'] the url accessing the script should be something like mydemo.php?function-if-exist=hello
Hope this helps you
Quick answers to 1 and 2 are enable the short_open_tag option into the php.ini file, for the last one is set the error_reporting to a less strict mode.
The reasons of not to adopt such measures are:
the short tag clashes with the xml declaration and is disabled on different host, if you need to manipulate xml or if you need to write portable code is better to resort to the long tag syntax. You lose the ability to echoing data with = but it is a small annoyance to me.
Warning and notices, as php forgive a lot the programmer for missing variables declaration are a blessing for debug. Keep then raised and you will address a lot of mispellings.
Are you sure that function-if-exist is a correct index for your hash? I would check the index first the access them. If the index don't exists is a probable hint that something is going wrong with your code and you should check the reason of the missing.
Better to stop now, as anyone can write a book on this topic, and several ones already done ;)