Closed (fixed)
Project:
XML sitemap
Version:
6.x-1.x-dev
Component:
xmlsitemap_menu
Priority:
Critical
Category:
Bug report
Assigned:
Reporter:
Created:
9 Dec 2008 at 05:41 UTC
Updated:
2 Jan 2009 at 19:10 UTC
Jump to comment: Most recent file
Comments
Comment #1
sumitshekhawat7331 commentedDo one thing...open .module file under xmlsitemap and remove all spaces and extra line.
Comment #2
whiztech commentedWhat do you mean with all spaces and extra line?
Comment #3
avpadernoThat is obviously not the solution to the problem. I could then suggest to delete all the content of the file, to resolve the issue :-).
As the module files are written, the only problem could be any characters present before the initial
<?php, or any calls todrupal_header()(orheader()) done after a call toecho()(or its aliasprint()).I will check this on the next hours.
Comment #4
eddiemonge commentedthis affects all pages as well. i am getting all my pages blanked out after i submit anything. checking the logs it shows the cannot....headers message.
Comment #5
whiztech commentedI also get the blank page error after submtting anything. Hope to see a fix soon enough.
Comment #6
AlexisWilke commentedI found the error.
The xmlsitemap_menu/xmlsitemap_menu.module starts with character 0xFEFF in UTF-8 which no one can see without a little bit of work...
Removing that character fixes the problem.
If you have a binary editor, delete the first 3 bytes (EF BB BF) and it will work.
I have gvim and can fix the problem by doing this:
set fileencoding=iso8859-1
then write the file.
I'm not too sure that posting a patch would help for this one.
Thank you.
Alexis Wilke
Comment #7
avpadernoI was having trouble understanding the reason of the error; I could not see it because I test the module on Mac OS X, which handles the UTF-8 encoding.
I think those characters are the UTF-8 BOM, but I don't see any settings in my editor to not make it output that in the file.
I will change the settings of my editor so that it uses a different encoding.
Like temporary fix, I think it's enough to open the file with a text editor, and save it using an encoding that is not UTF-8.
Thank you very much for your help.
Comment #8
eddiemonge commentedtry loading the attached file and see if it works for everyone
Comment #9
AlexisWilke commentedNo good. 8-)
This one will fix the problem on your computer.
Thank you.
Alexis
P.S. the content at the start of the file:
Notice the extra 0xEF 0xBB and 0xBF in your file. The encoding of 0xFEFF in UTF-8. That's a space (white) character that has a width of zero (0). Used in some special circumstances when you want to separate two words by a space, but do not want the space to show up. I is also used at the beginning of UTF-8, UTF-16, UCS-2, and UCS-4 files so you can detect that their encoding easily. As mentioned earlier, it is called BOM (byte order mark). More info here:
http://www.unicode.org/faq/utf_bom.html#BOM
Comment #10
avpadernoIt should be better insert the modified file like plain text. There is not need to compress a file that is not so big; plus it would be viewable directly from the browser.
Comment #11
AlexisWilke commentedYou would not see any difference since the BOM is an invisible character. This is quite a peculiar bug. Actually, I think that PHP should be capable of ignoring the BOM so as not to generate such errors...
Thank you.
Alexis Wilke
P.S. also I'd have to change the extension:
The selected file xmlsitemap_menu.module can not be attached to this post, because it is only possible to attach files with the following extensions: jpg jpeg gif png txt xls pdf ppt pps odt ods odp gz tgz patch diff zip test info po pot.
Comment #12
avpadernoAs long as the file is not saved in UTF-8 with BOM, there would not be a problem.
This is the copy of the module without any BOM; rename the file, and replace the old module file.
Comment #13
avpadernoComment #14
avpadernoIt has been fixed in CVS.
Comment #15
germinal commentedI didnt get the CVS yet.. but the other solutions given here don t work... I don t get the header error anymore... just a blank screen...
does the CVS solve the issue?
Comment #16
avpadernoI don't know; I have never had the issue on Mac OS X, but it handles UTF-8 encoding natively.
To know if the latest development snapshot works, somebody who had the issue should try using it.
Anyway, to get the copy of the code contained in the CVS it's enough you download the latest development snapshot.
Comment #17
germinal commentedWhat is the difference between OS X and XP/VISTA?
EDIT: my problem is solved..
seems my site was still running the older version of xmlsitemap! now it s fixed.. no header issues!
thanks!
Comment #18
AlexisWilke commentedI'm running with the latest version (Terms & Files turned off though). And I did not have the issue (I had to update many things and it worked just fine.)
Thank you.
Alexis Wilke
Comment #19
avpaderno@germinal: The difference is that the text encoding used by the applications on Mac OS X is UTF-8; that means, I guess, that when PHP interpreter opens a script to execute it, it doesn't get the BOM characters because they are filtered out from the system function it calls to get the file content.
Comment #20
germinal commented@Kiam@avpnet.org
I run OS X but my site is running on unix server.... and I edit my files via ssh most of the time... so in that case I guess the OS is not relevant?
Comment #21
avpaderno@AlexisWilke: May you try enabling xmlsitemap_file.module? If that would be the module which causes the problem, you can its files from your server.
If you don't have any problems with that module, that would be a confirmation that there isn't a bug, or there isn't a bug in XML Sitemap.
Comment #22
AlexisWilke commentedgerminal,
Since xmlsitemap is not critical to your site, try turning it off and do what you usually do and see whether the blank screens still appear. And you probably want to create another post for those because it probably has nothing to do with the old bug.
The difference with Mac OS/X is certainly that their web server does NOT emit the BOM (which is done by Apache because they assume that the file could be anything and the first two characters may not be a BOM but just plain data!)
Thank you.
Alexis Wilke
Comment #23
avpaderno@AlexisWilke: Thanks for your support. :-)
I checked the modules files and there aren't any BOM characters; therefore the original problem should not be present anymore.