WordPress.org

Ready to get started?Download WordPress

Forums

Blank editor pane when editing large page only (5 posts)

  1. dde7
    Member
    Posted 2 years ago #

    I'm building a WordPress blog on a site hosted by Network Solutions; my site is http://dedicto.com/ (no posts yet, only pages; still under construction). I'm building an annotated bibliography (well over 200 annotated entries so far) on mainly political topics, as a single large page:

    The bibliography page displays normally in the browser, but I now get an apparently blank editor pane in the visual editor when attempting to edit the bibliography. Selection of the apparently blank area reveals ASCII text with HTML markup (not visually displayed text such as would normally appear), and any attempt to switch to the HTML editor by clicking the HTML editor tab fails. These problems occur only on the large bibliography page; the editor works normally on other, smaller pages. These problems only appeared recently; until it reached its present size, the bibliography could be edited normally.

    Known versions of potentially relevant software:

    • Firefox 14.0.1
    • WordPress 3.4.1
    • theme: Twenty Eleven 1.4
    • plugin: Jetpack 1.5
    • plugin: Simple Local Avatars 1.3.1
    • plugin: Social Login 3.2
    • plugin: XCloner 3.0.7

    I've used XCloner to make a backup of the most recent version of the site, so there should be little risk of data loss; but my site will be of little value without the ability to grow the bibliography to arbitrary size, so this is a very serious problem from my perspective.

    I've found one article on the Web that sounds as though it might be relevant to this problem:

    http://www.undermyhat.org/blog/2009/07/sudden-empty-blank-page-for-large-posts-with-wordpress/

    However, the definitive solution proposed in this article involves editing the PHP.INI file, since the author traces the problem to the underlying PHP engine rather than to WordPress per se. I would be willing to try this solution, but on my Network Solutions site I am apparently unable to access the PHP.INI file (at any rate, I cannot find it). I would really appreciate a solution that would work from within WordPress, if one is available. However, if access to the PHP engine is absolutely necessary (as this article seems to imply), I am prepared to ask Network Solutions for help of that kind.

    Some insight into what is really going on here would be greatly appreciated. Thank you!

  2. cubecolour
    ɹoʇɐɹǝpoɯ
    Posted 2 years ago #

    Try creating a new php.ini in the directory where WordPress is installed. If that is not supported by your host you will need to contact their support.

  3. dde7
    Member
    Posted 2 years ago #

    Thanks. But what should go in the PHP.INI file? Normally if I were attempting something like that I would make a copy of the existing PHP.INI, but since I can't access its location on Network Solutions, I can't even copy it, much less modify it in place. The suggested fix from the article I linked to is only two lines. I'm concerned that making a PHP.INI from just those two lines will break WordPress by omitting other needed settings.

  4. cubecolour
    ɹoʇɐɹǝpoɯ
    Posted 2 years ago #

    I have just looked at the article you linked to and the suggested fix outlined requires apache to be stopped & started which means that it looks like you won't be able to try it. I think you need to discuss your issue with support at your hosting company.

  5. dde7
    Member
    Posted 2 years ago #

    Thanks. Indeed, it sounds like I'll have to go to Network Solutions. Maybe I'll show them this discussion (and post back here as to what experiences I have with them). Your advice is appreciated.

    If I don't get a good resolution from Network Solutions, maybe I'll try what you first suggested anyway. The restart of Apache is presumably just to get PHP to reread PHP.INI; on a large ISP like Network Solutions, that may happen periodically anyway.

    Longer-term, though, it would be good if WordPress developers could find a solution that would avoid the need to go outside WordPress itself. If (as appears to be the case) this problem is simply a result of page size, I can't be the only one affected, by any means. A hard maximum limit on usable page size will fundamentally restrict the range of functionality of WordPress.

Topic Closed

This topic has been closed to new replies.

About this Topic