Getting line of Javascript (document.write) at top of pages, template editor broken

[Tomeeboy]

We're in the process of testing out our vBulletin conversion and are experiencing a couple weird issues.

The first seems to happen when you are forwarded to, or follow a link to, a specific post in a thread (for example, after you post a message, or if you follow a link from a search of somebody's posts). At the top of the page, a single line of raw Javascript code is output:

document.write(' [IMG]http://media.ign.com/akamai/pixy.gif[/IMG] -1)) { fetch_object('currentPost').scrollIntoView(true); }">

I'm assuming that the browser is supposed to jump directly to the appropriate post anchor, but instead it just stays at the top of the page.

Any ideas what might cause this?

We're experiencing a similar issue with the built-in template editor, except it is rendering the editor completely useless. Instead of the actual editor loading, we get a bunch of plain text output with some form elements that don't work and give an "object required" error if you click on them. Here's a picture, as this will probably help:



I have a feeling that these issues may be related, but so far we haven't been able to figure out the cause. Thanks in advance!

Update: Another broken feature is the Style Downloading. We're attempting to copy styles over from the test forum to the live one and it seems the XML is not being built correctly. Thought I would mention this in case all of these things are somehow related or have a common denominator.

[Andy Huang]

Looks like there was a bad template setting some where and the warning about it could cause problem was ignored and had the template saved...

Please try to create a new style with no parent style; this new style should be the same as the default style... at which point your forum would at least not error out. Then it's a painstaking process to go through each of the last template you've edited, and try to save them again to see if it triggers an error. When you do find that particular template, you will need to either fix the template error, or revert it to the original state.

[Tomeeboy]

Looks like there was a bad template setting some where and the warning about it could cause problem was ignored and had the template saved...

Please try to create a new style with no parent style; this new style should be the same as the default style... at which point your forum would at least not error out. Then it's a painstaking process to go through each of the last template you've edited, and try to save them again to see if it triggers an error. When you do find that particular template, you will need to either fix the template error, or revert it to the original state.

Thanks Andy. Unfortunately, this is with a fresh install of vBulletin 3.7 using the default theme. We haven't edited any templates because we CAN'T edit any templates. We had the problem on both our test site and live site with roughly 4 or 5 fresh installs of vBulletin 3.7.

I should also mention that the HTML output on the Edit Template page I posted a screenshot appears incomplete. It starts with option box form code and ends with closing divs and other tags that were never opened.

[Steve Machol]

Well you have add-ons such as vBAdvanced which do require modifying templates.

To troubleshoot this, first reupload all the original vB non-image files (except install.php). Make sure you upload these in ASCII format and overwrite the ones on the server. Also be sure to upload the admincp files to whichever directory you have set in your config.php file. Then run 'Suspect File Versions' in Diagnostics to make sure you have all the original files for your version and that none show 'File does not contain expected contents':

Admin CP -> Maintenance -> Diagnostics -> Suspect File Versions

[Note: In some cases you may also need to remove any of the listed .xml files in the includes/xml directory.]

Next, disable all plugins.

Note: To temporarily disable the plugin system, edit config.php and add this line right under <?php

define('DISABLE_HOOKS', true);

Then if you still have this problem, create a new style and choose no parent style. This will force it to use the default templates. Finally empty your browser cache, close all browser windows then try again. Make sure you change to the new style and view your forums with it. Do you have the same problem?

[Tomeeboy]

Well you have add-ons such as vBAdvanced which do require modifying templates.

To troubleshoot this, first reupload all the original vB non-image files (except install.php). Make sure you upload these in ASCII format and overwrite the ones on the server. Also be sure to upload the admincp files to whichever directory you have set in your config.php file. Then run 'Suspect File Versions' in Diagnostics to make sure you have all the original files for your version and that none show 'File does not contain expected contents':

Admin CP -> Maintenance -> Diagnostics -> Suspect File Versions

[Note: In some cases you may also need to remove any of the listed .xml files in the includes/xml directory.]

Next, disable all plugins.

Note: To temporarily disable the plugin system, edit config.php and add this line right under <?php

define('DISABLE_HOOKS', true);

Then if you still have this problem, create a new style and choose no parent style. This will force it to use the default templates. Finally empty your browser cache, close all browser windows then try again. Make sure you change to the new style and view your forums with it. Do you have the same problem?

Tried all of those steps, but still experience the same issues :\ Is there anything else we could try? As I mentioned, this has been happening through multiple fresh installs of vBulletin 3.7. We've had about a half dozen people testing on different computers, with different browsers as well.

Could this possibly be some kind of parsing issue with XML or Javascript that is being included in some specific fashion?

[Lynne]

Doing a search of the code you are seeing shows this to be spit out from both the class_groupmessage.php file and the class_postbit.php file. Have you tried reuploading those files? If you have, have you tried downloading a new vb from the members area, unzipped it, and uploading that new file?

[Tomeeboy]

Doing a search of the code you are seeing shows this to be spit out from both the class_groupmessage.php file and the class_postbit.php file. Have you tried reuploading those files? If you have, have you tried downloading a new vb from the members area, unzipped it, and uploading that new file?

Already tried reuploading everything, even from a fresh zip from the member area. We had this issue all through the release candidates, so we basically reuploaded the files every time a new version came out too.

[Steve Machol]

If you really have removed or disabled all your add-ons and done everything else suggested, then fill out a support ticket at:

http://members.vbulletin.com/membersupport_contactform.php

Please include a complete description of the problem and be sure to include the login info to your Admin CP, phpMyAdmin and FTP in the 'Sensitive Data' field.

[Tomeeboy]

If you really have removed or disabled all your add-ons and done everything else suggested, then fill out a support ticket at:

http://members.vbulletin.com/membersupport_contactform.php

Please include a complete description of the problem and be sure to include the login info to your Admin CP, phpMyAdmin and FTP in the 'Sensitive Data' field.

Yes, unfortunately none of that worked. Believe me, we want the problem fixed, as we're less than a day from a forum relaunch and one of these issues is quite visible to visitors (and the others are problematic for us).

I'm not sure I can provide all of that sensitive data in a support request, though. vBulletin support or not, I'm not comfortable giving anyone that much access to our web server and user information. If that's the absolute only way we can get this taken care of, then we may not have much choice, but I'd rather avoid it if possible.

I'm attempting to attach a copy of our PHP Info in case there is information in it somewhere that may reveal a setting that is causing our problems. It is slightly modified, as I had to remove any information that we don't want in public view, but that was mainly limited to usernames, IP addresses, directory paths, server names, etc... Nothing that should hinder troubleshooting.

It will be easier to view the file if the extension is changed to .html from .txt... that was the only way I could upload it. Thanks in advance to anyone who takes a look.

[Steve Machol]

There is nothing in phpinfo I see that would cause that error. In my experience something like that is caused by a modification, not PHP.

Unfortunately if you do not want to fill out a support ticket with the requested info, then we have no other way to help. Sorry.

[Wayne Luke]

The original javascript string error is caused by vBAdvanced's integration system. They have the fix on their website for it. I would hope the latest version of vBAdvanced includes the fix. You will need to apply the fix from their website or remove forum integration from your setup.

[Tomeeboy]

Thanks for the response Wayne. I looked into the vBAdvanced bug and it certainly sounds like the same issue we're experiencing (at least for the line of javascript at the top of pages). The latest version of vBAdvanced does in include the fix, but we're already running it. I went ahead and checked the file that causes this issue anyway, per their manual fix instructions, and the file already has the fix coded into it. Looks like we're back to square one, unless there are other files capable of causing that issue.

I'm still really curious to figure out what is brekaing our template editor and XML style downloading, as those two things are really cutting down on some productivity. Even if the problem were still related to vBAdvanced, can that have any effect on these two features as well?

Also, any idea if PHP or XML short tag settings could possibly be causing any of this?