Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

Installing SilverStripe /

Getting SilverStripe up and running on your computer and on your web server.

Moderators: martimiz, Sean, biapar, Willr, Ingo, swaiba, simon_w

Content editor not displayed (ss 3.0)


Reply


8 Posts   1174 Views

Avatar
odjau

Community Member, 1 Post

15 July 2012 at 3:38am

Hello everybody,
I've been testing ss 3.0 for a few days. I like the simplicity of the back office but I'm currently having 2 blocking issues :

1 - content editor doesn't appear when I want to edit a page
2 - I'm not able to check permissions for new users

This is a fresh install of ss (no additional module, no code modification).

Does anybody have faced these issue before ? What can I do in order to find out the origin of these issue ?

Thank you for your help.

odjau

Avatar
snel

Community Member, 12 Posts

3 September 2012 at 1:19am

I'm not sure, if this is related. I have the following issue using SS 3.0.1:
When logging in, everything seems normal. Page-editor is displayed. As soon as I select another menu on the left (Security, Settings, Help), the right part of the admin-interface is cleared but not updated with the new content. When looking at the JavaScript Console, Error in jQuery is shown:

Uncaught Error: NOT_FOUND_ERR: DOM Exception 8 jquery.js:6497
jQuery.extend.clean jquery.js:6497
jQuery.buildFragment jquery.js:6232
jQuery.fn.extend.domManip jquery.js:6034
$.domManip jquery.entwine-dist.js:1234
jQuery.fn.extend.before jquery.js:5862
jQuery.fn.extend.replaceWith jquery.js:5990
jQuery.extend.each jquery.js:660
jQuery.fn.jQuery.each jquery.js:271
jQuery.fn.extend.replaceWith jquery.js:5983
(anonymous function) LeftAndMain.js:396
jQuery.extend.each jquery.js:654
$.entwine.$.entwine.handleAjaxResponse LeftAndMain.js:357
$.entwine.Namespace.Base.extend.one.one jquery.entwine-dist.js:1023
$.entwine.Namespace.Base.extend.build_proxy.prxy jquery.entwine-dist.js:1048
$.entwine.$.entwine.handleStateChange.$.ajax.success LeftAndMain.js:317
jQuery.Callbacks.fire jquery.js:1075
jQuery.Callbacks.self.fireWith jquery.js:1193
$.ajaxSetup.beforeSend.jqXHR.success jquery.ondemand.js:150
jQuery.Callbacks.fire jquery.js:1075
jQuery.Callbacks.self.add jquery.js:1110
$.ajaxSetup.beforeSend.jqXHR.success jquery.ondemand.js:149
jQuery.Callbacks.fire jquery.js:1075
jQuery.Callbacks.self.fireWith jquery.js:1193
done jquery.js:7538
jQuery.ajaxTransport.send.callback jquery.js:8324

Workaround is to reload the whole page which is annoying.

This behaviour was seen in
- Chrome (Version 21.0.1180.89)
- Safari 6.0 (8536.25)
- FireFox 11.0
all on Mac OSX Mountain Lion 10.8.1

Avatar
snel

Community Member, 12 Posts

3 September 2012 at 1:26am

Edited: 03/09/2012 2:36am

Just upgaded Firefox to Version 15.
Attached screenshot shows JavaScript Error

Found, that my issue is already adressed in this post: http://www.silverstripe.org/general-questions/show/20474

Avatar
USvER

Community Member, 6 Posts

3 September 2012 at 3:45am

I got the same issue becouse of SS was not installed properly. Try to reinstall. Make sure you have no warnings. Specialy with mod_rewrite(preaty url).

Avatar
snel

Community Member, 12 Posts

3 September 2012 at 4:43am

@USvER, thanks you for your advice. I just made a fresh install of ss 3.0.1 (I've attached screenshot of the server requirements-test).

The issue persists.

I also added following entry in _config.php
SS_Log::add_writer(new SS_LogFileWriter($_SERVER['DOCUMENT_ROOT'] . '/error_log.txt'), SS_Log::NOTICE, "<=");
but nothing gets logged so far.

Apache access-log gets entries with http-code 200 every time a menu is selected

Might be important to know:
The problem only is seen on Mac OSX 10.8.1 environment. The Windows 7 installation made on another development machine is not affected.

Avatar
poblom

Community Member, 25 Posts

3 September 2012 at 7:01am

Edited: 03/09/2012 10:35pm

I have the same problem with server running under OS X 10.6.8! Could it be a server or php config issue?? Where to look??

Browsing ss3.demo.silverstripe.org is no problem so not a browser issue.

Avatar
Alex Albino

Community Member, 1 Post

3 May 2013 at 6:51am

Edited: 08/05/2013 9:55am

Possible Fix:

I've encountered this before. I managed to follow the stack trace back to a call of jQuery's .replaceWith() method inside of a framework file:

framework/admin/javascript/LeftAndMain.js

... look for the "handleAjaxResponse" closure, around line 433.

The line that reads as follows:

// Replace panel completely (we need to override the "layout" attribute, so can't replace the child instead)
contentEl.replaceWith(newContentEl);

...is the culprit (in my case). The jQuery .replaceWith() function expects one of three parameters:

- An HTML string
- A jQuery wrapped element.
- A raw HTML DOM node.

...I was getting a jQuery wrapped object, but the object inside WAS NOT AN ELEMENT. It was a JSON object, which had a property named "CurrentForm" that contained an HTML string representation of the form. (Thanks, inventor of console.log()!)

I changed the code to the following:

// Replace panel completely (we need to override the "layout" attribute, so can't replace the child instead)
//contentEl.replaceWith(newContentEl); // ...original line of code

if (newContentEl[0] && newContentEl[0].CurrentForm) // Check to see if this is some kind of special jQuery wrapped object.
{
contentEl.replaceWith( newContentEl[0].CurrentForm ); // Grab that HTML string that's inside the object, use it instead.
} else {
// handle things as usual...
contentEl.replaceWith(newContentEl);
}

... Hope this helps. :-)
- Alex Albino

UPDATE: It turns out, this issue is a little higher up the stack. IGNORE THE PREVIOUS EDITS. JUST CHANGE THE FOLLOWING!!!

In the 'handleAjaxResponse' handler in framework/admin/javascript/LeftAndMain.js, change:

if(xhr.getResponseHeader('Content-Type') == 'text/json') {

...to

if(xhr.getResponseHeader('Content-Type').match( /^text\/json/, 'text/json' ) ) {

...and see if that works. It turns out that if you have the PHP.ini directive 'default_charset' set to something, your server will NOT reply with 'application/json' in the xhr header, but instead respond with 'application/json;charset=XXX' ...where XXX is the character set you have on your server. THEREFORE, the if-statement will fail when using the == operator ...we should instead use a regex match, as per the updated code snippet above.

Avatar
prwodux

Community Member, 7 Posts

26 June 2013 at 9:45pm

It didn't worked for me. Any other fix for this?