Forum Replies Created

Viewing 8 replies - 1 through 8 (of 8 total)
  • I just cleaned up one of these for a client, and I think I got it all…

    Check your database for a user called “WordPress.Org”. It won’t show up in wp-admin because it was placed by an SQL injection or something and the first name is set to a bit of JavaScript that executes and removes all traces of the user on the Users page. Be sure to clean both wp_users and wp_usermeta in the database.

    Next, check Appearance > Custom Header and delete the currently set header(s). In the account I cleaned up, the main backdoor was the uploaded header, presumably set by the fake admin. It was a duplicate of the site’s real header image and set by CSS, so it was essentially invisible.

    Go through all of the main index.php files in your hosting account… domains, subdomains, other software packages — it doesn’t matter — and delete the base64 encoded PHP at the top of the file. If you don’t delete the script-filled image first, if anyone visits the site and downloads the image, the base64 bit will be injected into index.php again and the iframe will come back.

    Good luck.

    Having a problem as well. Something is leading to a 404 in the stats iframe in the dashboard. My entire domain is controlled by WordPressso this loads the WordPress front end inside of the admin panel’s stats iframe. Due to some frame busting JavaScript in my theme the Dashboard crashes completely — the 404 from the stats window breaks out of the iframe (which it should do given the code in my theme) and tries to load the stats iframe page again which just leads to a nasty redirection loop.

    For those affected and unable to access the dashboard, only the front dashboard page is affected from my testing– you can deactivate the stats plugin either by deleting its folder (wp-stats) inside of your plugins folder or visit:

    http://your.wordpress.url/wp-admin/plugins.php

    and deactivate it as normal.

    If you have access to your database, in the wp_options table, make sure ‘siteurl’ (should be record 1) and ‘home’ (around record 40) are set to the correct domain.

    If these are incorrect, replace the wrong domain name with the right one. To be safe, once you’ve done that and have access to your Dashboard, update your Permalinks once just to make sure the new domain is being used in all WordPress generated links on the outside.

    This post is old, but I had the same problem – and every search result in every search engine used the value I had set for the home page title. A couple of weeks ago, I turned off the rewrite titles option for All-in-One SEO and wrote my own function in functions.php to display a customized title. My search results are making sense again!

    Just let jQuery do the work. Have it find the <p> elements in all of the post divs… after the first one, insert your opening div tag and some CSS classes and then after the final one (or :before the next post div), add the closing div tag. Then you can manipulate that created div element any way you wish.

    studiochris

    (@studiochris)

    Looks as this was given the OK by Matt for 2.6. Maybe we’ll see it completed and in there, if not for 2.6, by 2.7.

    studiochris

    (@studiochris)

    Thanks for the update Bryan. Here’s the codex page for admin menu creation and it also contains links to the plugin API.

    On about the addon — it works well for arranging the widgets and moving from sidebar to sidebar (and adding widgets that are available in the “pool”) but any settings that are changed are not saved, and in fact, will wipe out all customization for the widget (only tried a text widget here). .. but for ONLY arranging widgets and moving from sidebar to sidebar, which is where the current admin loses, this is golden until a “fix” has been made for the new admin.

    I think I also read in the other thread that this wasn’t meant to be a total fix, but more of a supplement, and that’s exactly what it does. Thanks again.

    studiochris

    (@studiochris)

    After seeing part of the (possible) reason the widget interface was changed (more than 2-3 “sidebars”), I agree with its simplification, but I too dislike the way it works now. I, personally, would like to see simple drag and drop between 2-3 sidebars made possible again.

    This could also potentially solve the problem for those who keep text and RSS widgets prepopulated with content, and still work within the new re-coded widget framework. The solution there (drag and drop [or some sort of move right, move left control for when javascript is turned off] required) is to have a “Saved/Storage/Inactive” sidebar where these widgets are stored but are not visible on the front end of the site. This additional sidebar is just a normal sidebar added in through functions.php — or is even a “global” sidebar built into the core/added with a plugin — that isn’t called into any of the template files. Inactive Text/RSS widgets whose data needs to be retained are kept on that sidebar and just dragged/moved into the applicable sidebar when needed.

    Another solution would be a “change/move to other sidebar” button on each widget. Click the button, sidebar list selection pops up.. select a sidebar and the widget is moved there and data is retained (I don’t know if this is even possible using the new framework). Used in conjunction with the “Saved/Inactive/Storage” sidebar, we still get that functionality back — and it lives in some sort of harmony with the new system.

    I wish I could write this myself, but unfortunately, I can’t. Any plugin authors up for it?

Viewing 8 replies - 1 through 8 (of 8 total)