thetanooki

That seems to have worked! That’s odd; maybe it can’t be removed?

Thanks for all your help! I’ll mark this as resolved, but I’m still curious as to why this worked and the other method didn’t.

If it helps, I’m on a relatively fresh install that I’m using to test out and tweak a new theme (and its child theme), so there are no plugins yet aside from the ones that come with WordPress.

<div id="postimagediv_new" class="postbox " >
<div class="handlediv" title="Click to toggle"><br /></div><h3 class='hndle'><span>Featured Image</span></h3>
<div class="inside">
<p class="hide-if-no-js"><a title="Set featured image" href="********/wp-admin/media-upload.php?post_id=93&type=image&TB_iframe=1" id="set-post-thumbnail" class="thickbox">Set featured image</a></p></div>
</div>

<div id="postimagediv" class="postbox " >
<div class="handlediv" title="Click to toggle"><br /></div><h3 class='hndle'><span>Featured Image</span></h3>
<div class="inside">
<p class="hide-if-no-js"><a title="Set featured image" href="********/wp-admin/media-upload.php?post_id=93&type=image&TB_iframe=1" id="set-post-thumbnail" class="thickbox">Set featured image</a></p></div>
</div>

Aside from ‘postimagediv_new’ they seem to be identical. I also just did a search right now through all the parent and child theme files. Aside from what we’ve added, there’s no other mention of postimagediv.

Just to check, since I wasn’t sure if I accidentally dragged and dropped some of the meta boxes and skewing my viewing options, so I checked the post page from a different (new) account. Both Featured Image boxes are still there, but the “original” one is already placed at a higher priority (just below Tags, and above all the custom boxes added by the parent theme. On my own account before we added the code, Featured Image was at the bottom, below the four custom boxes. I don’t imagine that’s directly helpful, but maybe it’s a clue?

Hi Chris,

Thanks for the reply! I definitely lost a bit of sleep last night trying to make some progress and this is definitely getting me in the right direction!

However, when I used your code in the functions.php file, it added a second Featured Image meta box up top (the thumbnail doesn’t seem to have proper padding on the right side; no big deal, but it’s odd), but it didn’t remove the first one from the bottom.

Does this have to do with the fact that meta boxes have to be added before they can be removed? Is it possible that I’m using the remove function before the default one is actually added? I’m using a functions.php file in a child theme, but I would assume the core file would be run first…

Also, in an attempt to figure out what was wrong, I tried changing ‘normal’ to ‘side’… which didn’t do anything. But shouldn’t it be side anyway, or does it not matter?

Thanks for your help esmi! I’ve managed to figure this out and resolve the issue, so I’ll just explain what I did here in case anyone comes across this thread looking for a solution.

In my case, turns out that the GD library was in fact missing. I had to log into WHM (I’m on a WHM/cPanel server), and towards the bottom of the left sidebar, I had to find Software > EasyApache (Apache Update). I loaded the previously saved config and kept most of the same options, but under the Exhaustive Options List in the PHP section I had to check to enable GD. From there, I recompiled Apache and the Image Editor was working fine from then on.

5.2.6 on the old server (that worked), 5.2.9 on the new one.

I started looking at media.php in the core files and noticed mention of “gd_edit_image_support” – I was told in the WordPress IRC channel that the GD library may be missing, and then told by my host that I’d need to “recompile apache with php to enable GD library” which I have no idea how to do ??

I also noticed that the old server was using Apache 2.2.10, while the new server is running 2.0.63. I’m not sure if this matters as much though…

OK, I’m pretty sure this isn’t WordPress or database related. Both sites (the main and the test) recently migrated from one server to another. I finally got the test site (where I know the editor was working before) installed on the new server, and the editor doesn’t show up their either.

Both WordPress installs are definitely updated to 2.9.2, so it must be a server thing that WordPress is checking before deciding not to provide the editor button. I’m triple checking to make sure all the file/folder permissions are the same to make sure that isn’t an issue.

If anyone knows what conditions need to be met for the editor to be visible, let me know. Otherwise, if anyone can help me figure out which core WP file the editor is in, maybe it will give me some clues as to where I need to look.

I’ve increase the allowed memory before, since WordPress would consistently timeout when attempting to export (roughly 8k posts and 11k comments). It was set at 128M. I decided to try reducing it to a more normal 32M, as well as upping it to 256M. No luck.

Is it designed to disable under any circumstances?

Hi esmi,

Thanks for the tips. Unfortunately I just finished trying all three of those suggestions, including switching to the default theme AND simultaneously sticking the plugins in a plugins.hold folder, and still couldn’t access the Edit Image button.

Are there any other options I can try? Or has anyone experienced similar issues and managed to figure out a solution?

Just a little update, this is almost certainly an issue of getting the Javascript to properly load. I tried hardcoding the scripts using script tags instead of wp_enqueue_script, and the slider worked fine. However, keeping with WP standards, I’d like for this to work through the proper methods. Does this look like it should work? At the moment, it doesn’t…

function load_scripts() {
    wp_enqueue_script('jquery');
    wp_enqueue_script('easing13', plugins_url('coda-slider/javascripts/jquery.easing.1.3.js'), array('jquery'));
    wp_enqueue_script('slider20', plugins_url('coda-slider/javascripts/jquery.coda-slider-2.0.js.php'), array('jquery'));
    wp_enqueue_script('featureslider', plugins_url('coda-slider/javascripts/featureslider.js'), array('jquery'));
}

function load_styles() {
    wp_enqueue_style('codastyle', plugins_url('coda-slider/stylesheets/coda-slider-2.0.css'), array(), false, 'screen');
}

add_action('init', 'load_scripts');
add_action('init', 'load_styles');

My understanding is that since this loads in the header, I shouldn’t need any additional code in the body, correct?

Nevermind. It took me a day to give in and post that I needed help, and I figure it out right after I post. ??

Oh the off-chance any of you check this topic again, how did you go about fixing the blank pages?

I seem to have had a similar iframe virus affect my site. I’ve changed the passwords and uploaded/installed a clean version of the latest WordPress. It seems all fine and dandy now until I import my old database, after which point all my pages go completely blank. (This was happening to the previously existing site too, almost as soon as the virus hit.)

Some of you mentioned this being a script at the end of your PHP files, but this is clearly a database issue for me. Still, I’d like to know what you did in your scenario to solve it.

It was a news blog of roughly 10,000 posts, including at least a few dozen original editorials. I’d like to save as much of it as I can, and I’m scrambling right now to find the most recent working backup.

Obviously, if it’s a database issue, the problem could be anywhere. When I backed it up a few days ago, it still produced a roughly 8MB file, though. I’ve not attempted to fix anything of this nature before… do you or anyone reading this have any suggestions as where might be good places to start if I were to look through the database tables for oddities that I might be able to fix manually? I would assume the problem’s in the core tables, but I honestly have no idea.

Quick question before I do that – I’m pretty sure the issue is database related, is that a possibility? Like I said, after the fresh install, everything was fine so far. I could see the blog, I could login, I could access the backend. It was only after importing the old database that I began getting blank screens – no other files or permissions were changed.

Thanks… but that brought me back exactly where I started. Fresh install went fine, but once the database was imported, blank pages.

If other WordPress users were also affected by this particular trojan and managed to solve the issue and/or get beyond the blank pages, let me know.

What script is it? By any chance does it involved iframes and links to unknown sites?