ajparker

As I recall – all I did was find the header background image and cropped out some of the height – resaved it, and used that instead of the default header background. I think the css and styling already is designed to not repeat the background and that the header block is the same size as the background. Although it’s been I while since I tweaked it – you may need to skim through the css to make certain that the css doesn’t give more space for the header – but start with the background image in the theme.

Ok – first off…. readme.txt has nothing that says mutex. I read through and then grep’ped the file…

[northcarolinagenealogy][~/www/wp-content/plugins/wp-super-cache]$ cat readme.txt | grep -i mutex
[northcarolinagenealogy][~/www/wp-content/plugins/wp-super-cache]$

NOTHING – but THANKS for at least mentioning file locking….

[northcarolinagenealogy][~/www/wp-content/plugins/wp-super-cache]$ cat readme.txt | grep locking
13. sem_acquire() errors such as “failed to acquire key 0x152b: Permission denied in…” are a sign that you must use file locking. Edit wp-content/wp-cache-config.php and uncomment “$use_flock = true” or set $sem_id to a different value.

thanks for mentioning locking it got things caching on one of my sites.

It’s really best to make the edit through something like phpmyadmin – login – select your wordpress database, then look for the wp_options table – then browse the table for the active_plugins row (or you could search for plugin) (on mine this option is listed as option id 39 – not sure if this is always the same.) In phpmyadmin you’ll have a pencil to the left of the row – this is a link to edit the entry.

The whole thing looks kind of like this…

a:19:{i:0;s:35:”TBValidator/trackback_validator.php”;i:1;s:35:”adsense-manager/adsen….. etc etc…

The first two were the suspicious ones in mine – unfortunately I didn’t document things as I went – I just deleted from the first i: to the end ” after the second rogue plugin. I made sure that the option at the bottom of the page was to save and clicked GO.

Then I went in and deleted the one file in the themes folder – the other seems to give permission denied still. (Even after a permissions change.) After all of this, I discovered that the edit essentially disabled all plugins – so I re-enabled my legit plugins.

I don’t know enough about the database to know if it would cause the sky to fall to delete the active_plugins key entirely and then run the upgrade.php again to reinitialize – but that might be an easier fix for most if that’s safe. (Could someone speak to this?)

Good luck!

This is something I found on a site that had been recently hacked. Look for a wp-info.txt file in your main wordpress install directory (if you’ve wiped the contents out it may be too late to look for it.) But the latest hack seems to install 2 phantom plugins that don’t show up in your admin panel list of plugins – only in the wp-options table of the wordpress database (you’ll have to look via phpmyadmin). More details in… https://www.ads-software.com/support/topic/168964?replies=30 that thread – including comments.

It looks like those phantom-encrypted/encoded plugins are how they’ve “altered” the display version number.

The first tip off I had something was wrong on one of my installs was upgrading to the new 2.5.1 – for some reason it claimed it was still running 2.5 – I wiped everything and tried again – still it claimed to be 2.5 – I checked the files and the version 2.5.1 is listed in the files – so I started looking closer – found the wp-info.txt as well as the WordPress user.

I also found the /tmp/ file listed as a plugin and one in the classic theme folder which had identical encrypted/encoded content – removing the plugins was the last change that fixed the version number – these plugins were only shown in the database field – not in the admin area.

Hopefully that’s ALL the damage.

BTW – I did a workaround on this particular page by going into phpmyadmin which may not be an option for everyone…. I selected my site’s database, then the wp_posts table. Then navigated to the post number (which displays next to a post or page entry in the list), then dropped that one from the table. (Posts and pages are treated the same in the database.)

I’m having the same issue trying to delete a page. I just went through the 2.0.3 upgrade on one site and had moved wp-admin wp-include and wp* in the main folder got moved to a bkp folder (wp-content overwrote everything) unfortunately, so I’ve had to recopy my template and plugin files. But, now that I’ve got everything straight, I can’t delete a testing page that I wrote after the upgrade. (I’m logged in as admin…) I saw a reference when this has come up before that perhaps not all the wordpress files had been removed before upgrade, but it seems that was fairly thoroughly done.

I did the database upgrade on login, everything LOOKED to go correctly.

I’ve even gone through a second time and blew EVERYTHING away and re-copied the files and that doesn’t seem to do it. I thought maybe there was a browser cookie issue, tried another browser to login, still no luck. Any other suggestions would be welcome.

It may be a php memory_limit problem… I ran into the same difficulty with trackbacks and it might be worth a try to put php_value memory_limit = 32M in your .htaccess (or modify php.ini if you have access to it.)

https://www.averyjparker.com/2006/04/08/wordpress-trackback-problem-finally-solved/

That’s, at least what solved the problem in my case.

It may be a php memory_limit issue – that was the case for me. Trackbacks “suddenly” stopped working at one point, I tried every suggestion I could find and then upped the /etc/php.ini memory_limit to 32M (.htaccess can be used as well php_value memory_limit=16M )….
https://www.averyjparker.com/2006/04/08/wordpress-trackback-problem-finally-solved/

I’ve just posted an article on A solution for this problem…. https://www.averyjparker.com/2006/04/08/wordpress-trackback-problem-finally-solved/

Judging from what I’ve seen there may be several different causes for this over wordpress’ existence. I tried the mysql fix (blanking the to_ping entries), that didn’t work… I also have the most current release 2.0.2 as of the moment.

I have 4 installs running out of one VPS and one of the sites suddenly stopped sending trackbacks. (The one with the most posts…) Basically the solution (in my case) for this (and a blank page after editing/saving a post) was to increase php’s memory_limit directive (default is 8M, I upped it to 32M)… it can be done either in /etc/php.ini for those that can access those files, or possibly in .htaccess by “php_value memory_limit 32M” (Someone else might vouch for that second solution I haven’t tested that one…)

Basically the tip off was in one discussion thread I saw a user mention that even the execute-pings.php didn’t work for them, they upped the php_value memory_limit to 16M and could at least do execute-pings.php, but not a trackback from a post…
So instead of upping the memory_limit to 16, I tried 32M and everything works – trackbacks – no blank page after posting…

I hope that helps someone out.