A site I am working on that is built using PHP is sometimes showing a completely blank page.
There are no error messages on the client or on the server.
The same page may display sometimes but not others.
All pages are working fine in IE7, Firefox 3, Safari and Opera.
All pages are XHTML with this meta element:
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=utf-8" />
It appears that I have fixed the problem by adding this PHP code:
header('Content-type: text/html; charset=utf-8');
I have read that this problem may be caused by XHTML, encoding, gzip compression, or caching, but nobody has been able to backup these guesses.
As the problem was intermittent I am not confident that my solution has actually solved the problem.
My question is, are there reproducible ways of having IE6 show a blank page when other browsers display content?
If so, what causes it and what solves it?
This is a content-type problem from IE.
It does not know how to handle application/xhtml+xml.
Although you write xhtml+xml, IE only knows text+html.
It will be the future before all agents know xhtml+xml
change your meta tag with content type to content="text/html;
Sounds like bug #153 "Self Closing Script Tag" bug in IE, which is well known to cause blank pages.
Due to IE's bug, you can NEVER code the following and expect it to work in IE.
<script src="...." />
(if the tag is self closing, you are in for a world of pain)
Instead, always code as;
<script src="...."></script>
I had a similar problem that was language specific - only the page with multibyte characters didn't show in IE6 and IE7. Turns out in these two browsers, the order of the Content-Type meta tag and the title tag is a big deal. So putting the tag (which contained Japanese characters) after the meta tag fixed the problem.
Not sure if this exactly matches your experience. It depends on which specific version of IE (including service packs) is being used.
A known rendering issue with IE6 SP2 & IE7 (both use the same rendering engine) is the existence of orphaned tags in your HTML. This may be an orphaned div or script tag.
<script language="javascript"> // no closing tag
alert('hello world');
<body>
hello world
</body>
The above renders just fine in IE6 SP1 and Firefox, but you will only see a blank page in IE6 SP2 & IE7.
There are certain other tags that must have a separate closing tag. Check that any <div> and <script> tags have an ending </script> or <div> tag, not just a closing slash at the end of the opening tag. Another one is <textarea>. You have to have both tags.
You can test if this is occurring with your site if you can View Source of your blank page and get the source html even though your page is blank.
You should serve pages with the Content-Type header as text/html to IE users. You don't need to change the meta tag, just leave it as application/xhtml+xml (IE will ignore it).
I got this bug due to a typing error.
I wrote the meta tag :
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15" />
Thanks to you i corrected it to :
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
and i haven't the problem now.
Related
I have a php page. The code is:
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
<meta name="viewport" content="width=device-width">
<?php include("some_file.php"); ?>
<title>Calculadora dos Custos do Automóvel</title>
</head>
<body>
<p>aaa</p>
</body>
</html>
As you can see nothing is wrong.
Though, view source of Firefox gives red erros and w3 validator gives also errors.
I'm around this for two days, and it is so strange. I suppose it has to do with some strange characters php might be inputting into the HTML code but I'm not sure. Or perhaps the encoding considering that the code has Portuguese characters.
There are two BOMs just before the <title> tag. Remove them (e.g. delete everything between the second <meta> and the <title>) and everything should work fine.
From what I see here you are using Notepad++ and we already cleared that the problem is because of BOM of the php files that you include before title.
To solve this for each file that you use open in Notepad++ and from menu choose Encoding -> Encode in UTF-8 without BOM and save the file. Do this for all your files in the probject (php files).
You should not have anymore that special characters in front of title.
Also make sure you start the <?php tag at the beginning of the file (no white spaces or new lines before) and if the file contains only php you don't have to use closing ?> tag. This way you are sure that you will not have spaces at the end of the file.
As others have said BOMs are a problem when including PHP files, even if those files do not echo anything
PHP includes
At the time this article was written, if you include some external
file in a page using PHP and that file starts with a BOM, it may
create blank lines.
This is because the BOM is not stripped before inclusion into the
page, and acts like a character occupying a line of text.
You should ensure that the included files do not start with a BOM.
in: http://www.w3.org/International/questions/qa-byte-order-mark
Detecting BOMs
You can online detect BOMs within the content of your HTML page using the W3C Internationalization Checker
There is something before
<title>
remove everything before title tag
try to save your file with UTF-8 encoding
You certainly have a problem with the white space before in your tag. Please rewrite your code afresh using your replacing the spaces with spaces from your keyboard.
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
<meta name="viewport" content="width=device-width">
<title>Calculadora dos Custos do Automóvel</title>
</head>
<body>
<p>aaa</p>
</body>
</html>
I am wondering why php does certain things twice, instead of once, when a certain meta tag is in the html portion of the file and the file is browsed by Firefox.
The code is like this:
<? /*...normal php code, including writing record to MySQL...*/
send('dan#example.com',$subject,$body);
?>
<!DOCTYPE html><html>
<!--PROBLEM on next line-->
<META http-equiv=Content-Type content="text/html; charset=utf-8">
<head>
<title><?= $thisPage?></title>
<link href="<?= $cssURL?>css.freedom-and-purpose.css" rel="stylesheet" type="text/css" media="screen, projection" />
<?
include $dataPath . 'data.php';
?>
The result is TWO records written the database and TWO emails sent, whenever the page is called by FIREFOX. IE and Chrome not producing the problem.
There is a lot of other code in the program, but the reason I showed the portion above is that removing the line that starts with
<META...
solves the problem.
That meta tag is in there because one of the packages I run included it in their code sample.
So, what is that meta tag causes php to double do on DB-writes? And same thing on sending email?
Chances are this is actually a request for favicon.ico being caught by your main PHP file. Putting an empty file in favicon.ico or preventing your PHP from handling that URL should do the trick
enter code hereI would suggest you go through your code in some details and check its formatting.
Phil mentioned the meta tag about which I agree with. His suggestion of <meta charset="utf-8"> would be my preference.
Secondly the line sending the email looks odd. Single quotes aren't an option in php for data replacement, so the line send('dan#example.com','$subject','$body); would result in an email with the subject "$subject" and body just "$body".
Additionally send('dan#example.com','$subject','$body); appears to be missing a quote after $body.
I would advise you to move away from short php tags for opening and closing chunks of php <? ?> and get in the habit of <?php for clarity and to ensure the server you're using processes the code correctly.
Finally, I hope include $dataPath . 'data.php'; adds a </head> and a <body> to the html, as you're currently missing those too.
I have a small problem, I'm using a .php page to show Russian characters. Now, I do this in two different ways. The text I take from the database shows fine, but if I show text like this
<h2>привет </h2> it doesn't show it at all. One thing worth mentioning is that I include my navigation file require_once "navigation.php" where I declare all the meta data etc.
So from navigation.php:
<meta charset="Cyrillic(Windows-1251)">
Solutions I've tried so far:
Adding encoding to .htaccess
Using php to output header encoding
Using Cyrillic(Windows-1251), UTF8, UTF16, iso-8859-5
Saving the file itself as UTF8
And I'm out of ideas. What I don't understand is how echoing the text from database works, but the HTML version doesn't.
Here this should work
<meta http-equiv="Content-Type"
content="text/html; charset=ISO-8859-5">
<h2>привет </h2>
So the problem was somewhere in the JS. For this project, I was given complete HTML works, just to hook PHP to it. The HTML, among other things, had this:
<script type="text/javascript" src="js/cufon-yui.js"></script>
<script type="text/javascript" src="js/cufon-replace.js"></script>
I have no idea what it does except it makes fonts smaller (why use JS for that is beyond me). So simple removal of that left me with a bit bigger font size, but working Cyrillic characters.
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
I am using SilverStripe as a CMS (http://www.silverstripe.com/services/why-choose-us/open-source-cms/) instead of Joomla or Drupal, and it has been a great experience for the most part so far. This problem however, is so strange that I am not even sure that SilverStripe has anything to do with it. Basically, links to CSS files that are set in a template are losing their leading slash when the markup is output to the browser. Obviously this can be very problematic.
This is the head section in the relevant template:
<!DOCTYPE html>
<html>
<head>
<% base_tag %>
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<meta name="viewport" content="width=720, maximum-scale=1.0" />
<title>$Title</title>
<link rel="stylesheet" type="text/css"
href="/framework/admin/thirdparty/jquery-notice/jquery.notice.css?m=1342411326" />
</head>
The links are actually generated into the template dynamically, but I put this one link in myself to isolate the issue. Even manually added into the template, the link markup will end up with href="framework/admin/thirdparty/jquery-notice/jquery.notice.css?m=1342411326", the original link minus the leading forward-slash,/. Does anyone have an idea how this might happen? Doesn't matter if I'm in Chrome, Safari or Firefox, they all behave the same.
I have noticed I can "fix" the issue by breaking the whole document. If I add a character before <!DOCTYPE html>, the href on the css link is pointing at the root again with the leading slash. Is this because of the doctype, the base tag, or some strange combination of the two?
One of the stranger issues I've come across...
By default, SilverStripe leaves off the leading slash on purpose, and uses the base tag to ensure that the links point to the right place. The reason that this was done was to make it easier to build sites that would still work if the site is run in a sub-URL, so that a development site, for example, might be at http://localhost/mysite/.
This is the reason why everything goes to hell in a handbasket if you get rid of the base tag - SilverStripe was built expecting it to be there.
However, it shouldn't be stripping off leading slashes on URLs. The most likely thing that would be doing this is the ContentNegotiator class, and that would lead to different behaviour if you mucked with the doctype.
It used to be on by default but in 2.4 and 3.0 it should be off by default. What version of SilverStripe are you using?
Try appending an extra / at location from where the link is generated.
have you tried base tag?
If this won't work, you can try putting there whole link eg. http://website.com/framework...
I don't know why every time I try to include my header using PHP’s include there's a top margin. I checked it using Firebug and it says there's a 22px offset margin on the top. Is anybody experiencing this problem? I think it's a CSS propiety: top: 22px. But nothing can change it even if I write h1 style="top: 0px; margin-top: 0px;". I think it's a php-CSS mystery that will never be solved.
edit: The only way to get rid of that top margin offset or whatever it is, is to add the follow properties to the H1: top: 0px;
position: absolute;
Will those properties generate more problems in the future?
is there a better way to solve this top margin-offset problem?
edit2: I think there's a problem with the encoding. Is there a conflict between the encoding of the included file (header.html) and the index file?
My index goes like this:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" />
<title>Untitled 1</title>
<link rel="stylesheet" type="text/css" href="style2.css" />
</head>
<body>
<div id="page-wrap">
<?php include_once("header2.html"); ?>
</div>
</body>
</html>
With this CSS:
* {
padding: 0px;
margin: 0px;
}
My header.html (the one that’s being included):
<h1>Header 2</h1>
And that’s the output:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" />
<title>Untitled 1</title>
<link rel="stylesheet" type="text/css" href="style2.css" />
</head>
<body>
<div id="page-wrap">
<h1>Header 2</h1> </div>
</body>
</html>
God its so simple that I really dont know where the top margin is coming from (in all browsers).
It only happens when I use php includes.
The source code looks the same as when I dont use php include.
This is pretty weird, but I copied & pasted your output HTML into Notepad++, and there was a strange character just prior to the h1. When pasting it into Notepad, the h in the h1 was subscripted.
Therefore, it looks to me like you may have an erroneous (or unexpected for PHP) character in your included HTML (or in the PHP including it). My suspicion? The dreaded UTF-8 BOM. Try to change the encoding of your included HTML file to eliminate the BOM (which I've always had problems with when dealing with PHP).
Edit: Yep. Just verified with a hex editor. There's a byte-order mark at the beginning of your included HTML. I don't know which editor you use, but you should have the option to change your text encoding settings.
See this for more info about PHP & the BOM.
You ought to post your generated HTML, like by copying what you see when you select "View Source" from your web browser. Oftentimes, I've seen mysterious blank lines in PHP-generated HTML because PHP is configured to output errors and warnings. Even if this is not caused by that, we can more-easily diagnose the problem if we see the outputted HTML.
I experienced the same problem...so what I did to fix it was to add an html opening comment at the beggining of the first file and an html closing comment at the beginning of the second file. This encloses the BOM (or whatever is appearing in between the files) inside a comment so it's not outputted in html.
For example:
#header.php
<?php ?>
<html>
<!--
#body.php
<?php ?>
-->
<body>
...
I tried to fix the problem converting between encoding formats in notepad++ to no avail. So this is only a temporary fix til I find a better solution to the problem.
well, without knowing what's in your php include, it's hard to tell, but make sure there's no CSS inside of it. also make sure that CSS you're loading is getting found and loaded. i debug by changing the background color or something else visual so u can be sure it's loading.
i'd bet anything that it has nothing to do with the php include it's self. like previously mentioned, there may be some css in the included file that is doing it, but i've never seen php anything like what you are describing.
i would look at the doctype declaration [temporarily remove it to see what happens], and remove the current html declaration tag and replace it with a plain <html> tag [again just temporarily, to debug]
A lot of times an extra new line will be at the end of a PHP script file you are including after the ?> tag. This will cause an extra character to be included in the generated output. You can remedy this problem by not having a closing ?> tag at the very end of your file. PHP knows to "assume" that it's closed.
Do you have the option to give us a link? I just tried locally a couple of things and you may get this "unwanted" new line for apparently "no reason" at all between your content and the "doctype" declaration, if there is a nonprintable character. Try to delete all characters after the ">" and take a look at it with a hexeditor to make certain of it. Please provide us more info.
Thats very interesting, because I just used your markup and your css. I also put it into an php file and included a html file. But there is no margin. Nowhere.
So make sure your browser is able to find the css file with
* { margin: 0; padding: 0 }
And I suggest you to use a reset sheet like this one - http://meyerweb.com/eric/tools/css/reset/index.html.
p.s. if you own some webspace, put it online and send us a link.
Dreamweaver drives me nuts with it's automatic BOM additions. Here's the fix:
http://www.adobe.com/support/documentation/en/dreamweaver/mx2004/dwusing_errata/dwusing_errata2.html
I am using notepad and I selected from the menu -> Encoding->Encoding with UTF-8 without BOM and it worked just fine. This should be done for every included file. I think this is the solution to your problem. Have a nice evening.
I almost killed my keyobard trying to solve to problem.
Then I tried PSPad editor, change explicitly .inc or .php to UTF-8 and IT WORKED !!
I had one time this problem and here is the way to fix it - its really problem in charset.I have spent 10 hours to find it. In my situation I change at all php files(all php files, all tpl(if you have) files) charset from UTF-8 to UTF-8 without bom and save it and try then. After that you can also make at .htaccess string "AddDefaultCharset UTF-8".