Forums Backend error [SOLVED]

Worker Joined: Jan 17, 2007 Posts: 170

When I try to access: http://www.burnt-clan.com/backend.php or forumsbackend.php

I get this error:

Code:

XML Parsing Error: xml declaration not at start of external entity


Location: http://www.burnt-clan.com/backend.php


Line Number 2, Column 1:<?xml version="1.0" encoding="iso-8859-1"?>


^

weird... it worked a couple of days ago.

registered · Posted: Wed Mar 21, 2007 2:34 pm

There's a blank line before the start of the <?xml line
Not sure why that is

Posted: Wed Mar 21, 2007 7:03 pm

I can't find any blank lines... infact I can't even find <?xml

my backend starts with: <?php

Posted: Thu Mar 22, 2007 4:41 am

I´ve checked your backend.php at validome.org and there is a break on line 2 also "Cannot modify header information - headers already sent by".
Upload the original backend.php and forumsbackend.php and see if this helps.
These files are both 100 % valid.

Posted: Thu Mar 22, 2007 5:31 am

thanks susan.

I've uploaded those two files again but still the same issue.

I've also noticed that header error you got and I have asked for support from the guys who made the theme.

registered · Posted: Thu Mar 22, 2007 6:35 am

ozbutcher, having that error show up in the XML output will cause it to be invalid (not sure if that is what is being said, so sorry if this post is not applicable). There is a FAQ here on the site that might possibly help you with the "cannot modify header information".

Posted: Fri Mar 23, 2007 5:58 am

I've checked out the FAQ on the header issues and have inserted some code into my mainfile.php but it didnt fix the problem. I was only getting 1 line of errors but one of my users posted a huge screen shot of them Sad

would this still be the same issue even though i've inserted the code mentioned in the faq?

Posted: Fri Mar 23, 2007 6:32 am

Quote:

ve uploaded those two files again but still the same issue.

Then the only other thing that I can think of is something was added to your mainfile.php and an edit is messed up somewhere or it could be sending output to the browser. There should be NO echo's / print's / header / etc. statements in mainfile.php (unless they are inside a function). Something is sending output to the browser BEFORE it gets to the header line in these backend scripts.

Posted: Fri Mar 23, 2007 6:33 am

Sorry, just thought of something else: make sure there is not a blank line after the ending ?> in either mainfile.php, config.php and rnconfig.php.

Posted: Fri Mar 23, 2007 9:23 am

I really appreciate your efforts in trying to solve the problem Smile

I compared my mainfile.php to the orginal that came with nuke. There was one change which I did, to fix a problem I had with the point tracking mod. I assume I can't paste all the code in so I took a screenie of it. But doesnt look like it uses any echo or print statements.

I also rechecked my php's for spaces and surprisingly I did find a space at the end of my config.php and rnconfig.php!! but I swear I have only been using TEXTPAD to edit them no other program!? how can they get there??

Worker Joined: Dec 05, 2006 Posts: 180

I dont know just thinking.
all the $prefix's in the config and database are the same?

Posted: Fri Mar 23, 2007 8:40 pm

yeah they are the same worker.

I'm gonna try contacting my host to see if those options in the FAQ are being used. will report back.

Posted: Sat Mar 24, 2007 8:38 am

ozbutcher, try changing the {$prefix} to just $prefix. Not sure if that is it, but you could also try commenting out those added lines and see if it works.

It has to be what you have modified or something related to the FAQ.

Posted: Sat Mar 24, 2007 10:34 am

thanks montego... Smile

I've gotten some response from my host and they said I should put the code from the FAQ into the htaccess file as they wont do the php.ini thing. Looks like its solved the problem with the theme header errors Smile

Now if I can just get my RSS feeds to work again!! Razz

I will go through and check every single .php for spaces.

Posted: Wed Mar 28, 2007 1:21 am

when I look through my .php files nearly every 2nd one has a empty line space after the ?>

how can this be?? I use textpad and upload with WS FTP. I've checked half of them but there's probably a good many more.

Is this whats causing my backend errors?

Posted: Wed Mar 28, 2007 6:49 am

No, something is sending output before its time. It could even be an error. Did you ever try commenting out those lines you added to mainfile.php? It is funny (or not) that I just looked at those highlighted lines above again, and you are missing a closing right bracket } on the if statement that you added... I am betting that is it.

Posted: Wed Mar 28, 2007 8:37 am

Okay I replaced the mainfile.php with the orginial one that came with nuke v2.10 but still the same error.

I checked the above code... I should have highlighted that last bracket too... its part of the code I changed so there isnt a missing bracket.

*puzzled* what files get called when I execute backend.php? could one of those files have been affected?

Posted: Fri Mar 30, 2007 8:44 am

I stumbled onto the problem! Smile

It was by pure accident!! I just had to report back on this!!!

After reading the other post in this board about backend problems I noticed the link to http://feedvalidator.org

I ran my site and it came up all okay except for some errors in the Title of 1 article I had!!

I had a look at the article title which was:
New Host, Site Upgrade & New Theme!

Anyway... upon removing the "&" the backend started working again!! It must be that titles CAN NOT contain the character "&"

Sorry for all the trouble about this!

registered · Posted: Fri Mar 30, 2007 9:14 am

Glad you found it. Perhaps the forumsbackend.php script needs to do some more escaping for XML.

Posted: Fri Mar 30, 2007 9:31 am

Actually I experienced a similar problem with the standard backend.php on the home page. The wysiwyg editor escapes an ampersand if you put it in the body of an article but not if you put it in the title. I'm wondering if we should somehow run the title text thru the same process and edits that the body text goes through. Having an ampersand in the title will generate an invalid feed.

Posted: Fri Mar 30, 2007 4:31 pm

While this probably should go in our bug tracker and I will take responsibility for putting it there, I've been looking preliminarily at a solution. It seems like the critical thing is to keep the title field of the stories table from having any unescaped htmlentities in it. It's pretty easy to locate the places where this field is updated or inserted in /modules/news/admin/index.php. Should we just add a $subject=(htmlentities($subject)) before any table updates are done?

Or would it be preferable to run the title field on the input screen thru the wysiwyg editor? But I think there are at least two input screens, one for submit news and one for an admin entering a new article ... and possibly an edit news screen too.

Posted: Fri Mar 30, 2007 6:12 pm

Could also modify the backend scripts to scrub the titles, etc before outputting them.

Posted: Fri Mar 30, 2007 6:31 pm

Yeah, but I'd rather keep the stuff from getting into the database in the first place. Your step might still be needed for some "legacy" material but at least on my site it was a simple edit to take care of the problem in the article that offended RSS. For that matter I just changed & to the English word "and".

Usually I think it's best practice to catch "errors" such as this as close to the source as possible and that's why I like so much the work Kguske has done with the wysiwyg editor. At the same time, I was just thinking that if we can find a single "choke point" like in news/admin/index.php and fix everything there it might be sufficient.

Posted: Fri Mar 30, 2007 7:31 pm

So do you consider it an error to have & in the title field of a news story in a database table for example?

The patch series really did a number on me on this.

Posted: Fri Mar 30, 2007 7:36 pm

My understanding is that we want & to be stored and & to be rendered and that htmlentities will do this ... at least the storing part.