adamheine

I had this problem too. I think I’ve gotten rid of the user (though only time will tell). If you can’t upgrade, or better yet do a clean install, try some of the tips here along with using this Exploit Scanner plugin to help you find offending files.

I used the plugin and found that all my files were clean, but the user was still there. I think it was there from a previous hack that I’d dealt with. You seem to have been able to get rid of the user via database changes. I was able to do it using WordPress admin (sort of), and I’ll put that procedure here for others as well (I’m using WP 2.7.1):

(1) Go to the users tab. The offending user (mine was named “WordPress” with the e-mail address “[email protected]”) will suddenly disappear when the page is fully loaded.
(2) Mouse over the users and the ‘Delete’ link. You’ll notice the URL to delete a user is the same for every user except for the user_id, like this: https://www.yourdomain.com/wp-admin/users.php?action=delete&user=3&_wpnonce=a9f12f3d4f
(3) What you need to do is find the user_id of the hacked user. To do this, I looked at the HTML source of the user admin page and searched for the user’s name and e-mail address. It will be in a fairly convoluted <tr> element, but with some patience you should be able to compare this with the other elements to find the ID of the bad user (you can even find the entire delete link in here, in which case the next step is easier).
(4) When you find the user id, copy the delete link for another user, paste it into a new browser window, and change the number after “user=” to be the same as the offending user’s ID. Then hit enter.
(5) You should be sent to a confirmation page, and the page should have the name of the correct user (double-check this – you don’t want to accidentally delete a real user!). Confirm and delete the sucker.

I think if you’ve successfully removed all the hacker’s other scripts, the user should be gone for good. Good luck!

There are a number of functions in there, so it depends on what you want to do.

If you want to show random pictures, use this function (it’s not even in the file that alex mentioned :-P): nggDisplayRandomImages(number_of_pics, height, width);

Put each of those numbers (number_of_pics, height, and width) inside ‘ marks. If you want the thumbnails not to be stretched then put ” for both height and width. For example, if you want six, unstretched pictures, you’d type this: nggDisplayRandomImages('6', '', '');

There’s a similar function to show recent images: nggDisplayRecentImages

Those functions pull from all galleries, I think. I’m not sure how to limit them. Maybe Alex can help you with that.

That worked. I removed that part of the code in nggWidget.php. In the ngg_widget_output fuction, I changed this:

$out .= '<img src="'.nggallery::get_thumbnail_url($image->pid).'" style="width:'.$options[$number]['width'].'px;height:'.$options[$number]['height'].'px;" title="'.$image->alttext.'" alt="'.$image->alttext.'" />';

to this:

$out .= '<img src="'.nggallery::get_thumbnail_url($image->pid).'" style="height:'.$options[$number]['height'].'px;" title="'.$image->alttext.'" alt="'.$image->alttext.'" />';

Thank you for your help.

You can see the problem here (scroll down to the bottom, “Selections from the Photo Gallery”): https://faithfulheartministry.com/. If you don’t see any stretched pictures, try hitting refresh (you shouldn’t have to do it more than once or at most twice before a portrait-sized picture shows up).

I’m not using the widget, because I need the pictures on the front page of the site. Instead, I’m calling the function directly like this:

<div class="ngg-widget">
		<?php nggDisplayRandomImages('3','192','144'); ?>
	</div>

@alexrabe,

I believe I used to use this function: nggDisplayImagesWidget($thumb,$number,$sizeX,$sizeY,$mode,$imgtype)

In the galleries, it looks like the thumbnails are being created properly. It’s just that the nggDisplayRandomImages function (or rather the ngg_widget_output function) forces all thumbnails to a certain size. I would think it would be as easy as allowing each thumbnail to just be the size it is, rather than forcing an artificial height/width on it.

– Adam

I have a similar question. I would like to allow an Editor-level user to have access to a plugin that has added a menu under the Options tab, but I don’t want the user to have access to all of WP’s core Options.

I have the Role Manager plugin, but if I allow Editors to manage Options then the user can accidentally mess stuff up. Is there a way to allow the user access to only part of the Options page? Specifically, a part that has been added by a plugin?

*sigh*

The problem had to do with a plugin. Specifically, the 0.10beta-R18 version of the Extended Live Archive plugin. There doesn’t appear to be a fix at the moment, so I’ll just have to deactivate and find another way to do archives.

I figured out what the problem was. I’m posting the solution here in case anyone else has the same problem.

The issue was in the mod_rewrite rules (for me, they are in my .htaccess file in the main WordPress directory). It’s supposed to look something like this:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /itsara/
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [S=50]
RewriteRule ^(about-us)/feed/(feed|rdf|rss|rss2|atom)/?$ /itsara/index.php?pagename=$1&feed=$2 [QSA,L]
RewriteRule ^(about-us)/(feed|rdf|rss|rss2|atom)/?$ /itsara/index.php?pagename=$1&feed=$2 [QSA,L]
...
RewriteRule ^([0-9]{4})/([0-9]{1,2})/([^/]+)/trackback/?$ /itsara/index.php?year=$1&monthnum=$2&name=$3&tb=1 [QSA,L]
</IfModule>
# END WordPress

Mine had extra rules before “#BEGIN WordPress“. I bet they were hang overs from before I upgraded to WP 1.5. In any case, they were interfering with the rules below that did paging properly. All I had to do was delete everything before “#BEGIN WordPress” (though not without making a backup, just in case!).

Is it okay to bump after over a month with no reply? Sorry if it’s not, I really am trying to be patient.