fivesparrows

No problem, I understand the issues with making changes like this across the entire server farm... We just have lots of clients parked on our reseller accounts that like to use the tool to make quick/simple web page content updates in-house (they don't use if for any complicated changes or to add new pages). Installing another tool is just not a great option for them. That is why we were hoping that we could make the change ourselves and have it apply to only that client account (or only our reseller account). Are their security risks with the other suggested tool? I like that this one is tied to the cpanel login (so that you are making changes without relaxing file permisisons). Most of the other ones that we have tried caused us to greatly relax file permissions. This recently resulted in a client site being de-faced by a hacker (they replaced the index.htm file), so I am just a bit leary about relaxing file permisisons these days. But thanks again for all of the attention on this one, hopefully we will see a cpanel fix soon.

I did a little more looking, and there is an active cpanel bug report on this issue (bug report 1023 on bugzilla.cpanel.net). So, hopefully we will see a fix soon (and not need the scan work-around). The discussion on it indicates that this is a recently introduced bug, cpanel installations rolled back to release 10.8.1-S114 don't experience the problem. So how about it TCH-Thomas, can we get the work-around put in place until cpanel releases a fix?

Hi Everyone... This seems to be a common problem that a number of people are running up against. There is a good communication thread on the wysiwygpro site regarding this issue, here is the link: http://www.wysiwygpro.com/xForum/topic.asp?TOPIC_ID=1399 The issue seems to be a character set conflict, and there are several solutions discussed. Here is the last post that seems to be a correction for the issue: ----------------------------- Begin Other Post ----------------------------------- I had the same problem after a cpanel upgrade. I was bewildered, because other programs that use WYSIWYGPro did not have this problem, only the HTML Editor in cpanel's File Manager. I tried several of the (very good) suggestions above with no success. I tried changing all charset and encoding references to utf-8 and then I tried making all of them iso-8859-1... still no good. Then I noticed that if I made an edit using special characters like spanish accents, etc., saved it, then viewed the page in a browser, it was OK. It was only when I opened the file in HTML Editor again, that the strange characters appeared. If I saved, then the strange characters were there when the page was viewed in a browser. If I backed out without saving the file was OK... So the problem (with cpanel's implementation of WYSIWYGPRO, anyway) is on the way into the editor, not as it is saved. So I edited the file: /usr/local/cpanel/base/3rdparty/Wysiwygpro/template I found the place where it includes editor_class.php and added a line to also include editor_fucntions.php. For example: include_once ('/usr/local/cpanel/base/3rdparty/WysiwygPro/editor_files/editor_class.php'); include_once ('/usr/local/cpanel/base/3rdparty/WysiwygPro/editor_files/editor_functions.php'); Then further down, where it inserts the code into the editor with the line: $editor->set_code($body); I added in a line to use the fixcharacters function before inserting $body into the editor, like this: $body = fixcharacters($body,'utf-8'); $editor->set_code($body); That cleared everything up for me. -------------------------- End other post -------------------------- But, I have no idea how to get at the "/usr/local/cpanel/base/3rdparty/Wysiwygpro/template" file to make this correction? Maybe one of the TotalChoice support experts can help us with this?