Applying patch also fixed upload problem, but has now broken wysisyg editor. This is a major showstopper bug for me at the moment. What can I do to submit traces/help fix?
55 Posts 13097 Views
If I remember correctly, the WYSIWYG editor actually broke as soon as I tried the upload - installing the patch wouldn't fix it. So i did a basic reinstall first, then applied the patch, and that fixed the WYSIWYG editor.
I took a backup of my DB first of all, before i did reinstall, just in case!
Thanks LinseyM, I did see that in your earlier post but to no avail.
For me the TinyMCE editor breaks when applying patch, regardless of whether I have attempted upload/folder creation/etc before patching. This is happening to me on fresh installs on 3 different (Debian/RH/Arch) systems, with clean databases.
If you look carefully, you can see the data get passed from the database into TinyMCE in raw form (brief flash of white HTML on black), but breaks when TinyMCE tries to use it as WYSIWYG.
This patch causes failures both reading into TinyMCE and writing out of it, as can be verified by entering data into TinyMCE then checking database->SS_mysite->SiteTree.
So a guess would be the tempfile used as an intermediary between DB and TinyMCE.. Know where that is stored?
Sorry, can't help you there. I really can't remember if I reploaded any files before i did a reinstall. Sorry.
Hopefully someone else knows the answer to this?
There seems to be some confusion about the file uploading problem in 2.4.0 and the patch available for it.
The upload problem will only manifest itself when the PHP setting open_basedir ([url]http://php.net/manual/en/ini.core.php[/url]) is specified for the PHP environment running SilverStripe. The problem occurs because SilverStripe will move the uploaded file into its temporary dir (if open_basedir is in effect) using move_uploaded_file() ([url]http://se.php.net/manual/en/function.move-uploaded-file.php[/url]). It will later during validation check that file is really an uploaded file using is_uploaded_file(), which will fail since the file was moved to the temp dir earlier.
The patch provided for this problem ([url]http://open.silverstripe.org/attachment/ticket/5547/2.4.0-FileUpload.diff[/url]) works by checking if open_basedir is in effect and if it is, it will handle the file slightly differently. It will also set the file permission to that specified by Filesystem::$file_create_mask to ensure that file can then be accessed by SilverStripe before finishing the upload.
As for the problem with TinyMCE breaking, it would seem unlikely that it is directly related to the file upload patch (I fail to imagine how it could possible produce such a side effect, but few things are truly impossible). I am using the patch on all my sites running SilverStripe 2.4.0 with an open_basedir restriction, and it seems to be working fine and without any noticeable side effects. A more detailed description of the TinyMCE problems would be great.
- Will TinyMCE work from a fresh install?
- If it works from a fresh install, will applying the patch and doing nothing else break it? (No database or manifest build is required for the patch to kick in.)
- If so, how was the patch applied? I would recommend using (assuming you are a Linux user)
$ patch -p1 < ../path/to/the/patch.diff
from the SilverStripe root directory.
I know it does seem unlikely that the file upload would break the WYSIWYG editor, but that is exactly what happened to me.
The train of events was: I had installed the site, set up pages & templates and was putting in content, so I'd already been using the editor.
I then went to the Files section to upload some images that I needed to use. When I tried to upload them I got an error. Assuming it was just permissions or something I decided to go back and enter the rest of the page content and then deal with the upload issue.
However, after navigating back to the content area, the WYSIWYG editor had no content in it. Now am not necessarily saying that the tiny mce editor itself was broken, but certainly something was wrong in the chain of events that puts the page content into the editor.
Looking back through my notes I did in fact reupload all the files, then rebuild. This didn't help, so I did a reinstall. The tiny mce worked again and at that point I installed the patch.
Well, am sure that makes everything as clear as mud! I couldn't quite believe it myself either, but for some reason, thats what happened.
your description sounds very interesting. unfortunately i do not have much experience in php so i wont give up and go through the fils.
as i mentioned before i did all the fils in its order as it is in the documentation.
1. unzip and installed the cms - everything ok! - blackcandy default settings - .de SSv.2.4.0
2. uploaded the broken fils wich are documented for the upload error
4. upload works - :D SUPER!
5. backend content - wysiwyg editor broke :( BAD!
as i described before the content in the frontend of my site was still visible with all the "wellcome etc..... bla blub" but the wysiwyg editor has no content and when you put something in it nothing hapened. i did also try the installation in .en but its all the same. by the way i didnt had any error messages that shows me that something went wrong. i cant understand why the hell the wysiwyg editor breaks if the fils i reinstaled only matters for the upload!? ... any idea?
i tryed the installation over four times -
thank you but your way dosent work for me :( !
still x.x m.
Hello LinseyM and moloko, thank you both for clarifying things for me.
I think I get it now and has been able to reproduce the problem. Removing the patch, attempting an upload (which fails) and then visiting "Pages" and selecting a Page does render an empty TinyMCE content field. Which is very interesting.
As far as quick fixes go, apply the patch to be able to upload files. If you have tried to upload files before applying the patch (or for that matter had file uploads failed for other reasons and are experiencing the blank TinyMCE problem), restarting the web browser seems to do the trick (at least with FireFox 3.6.6 on Ubuntu and Windows).