Ticket #279 (closed Bug: fixed)

Opened 8 years ago

Last modified 7 years ago

UTF-8 BOM chars are being rendered on the page

Reported by: jlindenbaum Owned by:
Priority: Normal Milestone: FCKeditor 2.4.2
Component: General Version: FCKeditor 2.4.1
Keywords: FCKreleaser Cc:

Description

Hi,

The 2.4 interface - without any alterations to config or similar - loads without problems.

The 2.4.1 interface - without any alterations to the config or similar - loads with ASCII preceeding the editor.

Here's my implementation:

<div id="newPostBox">

<?php include("./cn-fckeditor/fckeditor.php"); $fcke = new FCKeditor('content'); $fcke->BasePath = "./cn-fckeditor/"; $fcke->Create(); ?>

</div>

Here are the ASCII characters preceeding the interface. Contact me if you want a screenshot.



I am using the latest FireFox 2 and latest upgrades to IE 7 on XP SP 2 Professional.

Untested on different OS / in different browser.

Keep up the awesome work.

Regards, Johannes

Attachments

overview.php (2.7 KB) - added by jlindenbaum 8 years ago.
Explanation will follow as comment by jlindenbaum

Change History

comment:1 Changed 8 years ago by fredck

  • Owner set to fredck
  • Component changed from UI : Toolbar to Server : PHP

Do you think you are able to attach a test case PHP page that shows us the problem? This thing seams to be related to the overall page structure, other that the encoding used to save it.

comment:2 Changed 8 years ago by fredck

#286 is a DUP of this one.

Changed 8 years ago by jlindenbaum

Explanation will follow as comment by jlindenbaum

comment:3 Changed 8 years ago by jlindenbaum

Here's the explanation for the overview.php

overview.php is part of our newest software development. The whole software is pre-alpha and will be released very soon as a beta under GPL / LGPL.

We, as usual, rely on FCKeditor as our wysiwyg editor, because hands down - it's the best.

Back to the poing. We are still using ISO instead of UTF-8 encoding. The file is included by a main file that includes / loads all other files. If you require that file I'll be pleased to post it.

comment:4 follow-up: ↓ 6 Changed 8 years ago by fredck

It seams that the problem is that the fckeditor.php file contains the UTF-8 BOM since version 2.4.1. This is related to a bug on FCKreleaser.

As a quick fix, just save fckeditor.php without the BOM and probably things will start to work.

I'll be working to fix the FCKreleaser.

comment:5 Changed 8 years ago by fredck

  • Owner fredck deleted
  • Keywords FCKreleaser added
  • Summary changed from 2.4.1 loads with ASCII symbols preceeding editor. to UTF-8 BOM chars are being rendered on the page
  • Component changed from Server : PHP to General
  • Milestone set to FCKeditor 2.4.2

comment:6 in reply to: ↑ 4 Changed 8 years ago by bvanaerde

Replying to fredck:

As a quick fix, just save fckeditor.php without the BOM and probably things will start to work.

When doing this, half of the characters are gone. Now it only shows "" instead of "". My guess is the BOM needs to be removed from another file too.

comment:7 Changed 8 years ago by bvanaerde

When removing the BOM from fckeditor_php4.php (or fckeditor_php5.php, depends on which one you're using), all characters are gone.

comment:8 Changed 8 years ago by fredck

  • Status changed from new to closed
  • Resolution set to fixed

Fixed with [226] and [227].

Click here for more info about our SVN system.

comment:9 Changed 8 years ago by fredck

#310 is a DUP of this one.

comment:10 Changed 7 years ago by alfonsoml

#344 has been marked as dup

comment:11 follow-up: ↓ 12 Changed 7 years ago by onpubco

  • Status changed from closed to reopened
  • Resolution fixed deleted

This bug appears to be back in the most recent subversion code, where the BOM (i.e.: ) is being rendered before the editor is rendered. This happens when using fckeditor.php to include fckeditor and when serving pages using latin1 encoding (my code is not UTF8 compatible, unfortunately).

comment:12 in reply to: ↑ 11 Changed 7 years ago by fredck

  • Status changed from reopened to closed
  • Resolution set to fixed

Replying to onpubco:

This bug appears to be back in the most recent subversion code, where the BOM (i.e.: ) is being rendered before the editor is rendered. This happens when using fckeditor.php to include fckeditor and when serving pages using latin1 encoding (my code is not UTF8 compatible, unfortunately).

I've created a tool to check for UTF-8 BOM in PHP files at our trunk ([924]). The only file that was found was "_dev/releaser/fckreleaser.php". I've removed the BOM from that file too.

So, it seams that you are having a different issue.

comment:13 Changed 7 years ago by onpubco

  • Status changed from closed to reopened
  • Resolution fixed deleted

Fred, it looks like the UTF8 BOM is creeping in from fckeditor.html. If I re-encode this file from UTF-8Y to UTF-8 or latin1 then the problem goes away.

comment:14 Changed 7 years ago by onpubco

Hi, the BOM also may be present in fckdialog.html or other code it's including.

comment:15 Changed 7 years ago by onpubco

Wait, perhaps I was mistaken, I ran the fckreleaser.php script, and now it seems the BOM is no longer being outputted in the browser. I guess I shouldn't be trying to include the SVN code without first running fckreleaser.php. Sorry for any confusion this may have caused.

comment:16 Changed 7 years ago by fredck

  • Status changed from reopened to closed
  • Resolution set to fixed

It is not a problem to have the BOM in .html files. You should be aware of .php files only.

Note: See TracTickets for help on using tickets.
© 2003 – 2012 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy