Edde

@ysamphy: You can delete your cookies manually from within your browser.
In Firefox, you select Options from the Tools menu; click the Privacy Tab. Click the Show Cookies button. Now find anything related to you domain in the list and delete the ones starting with “wordpress”.
In IE go Tools -> Internet Options -> General -> Browsing History (Settings) -> View Files. Remove all relevant cookies.

Alternatively, you might want to disable all you plugins as this saves memory. Since you can’t access the admin panel, removing them from the plugins directory is your only option. A quick way to do so, would be to rename your plugins/ directory to something like disable-plugins/ and create an empty plugins/ directory. This way you should be able to access the admin panel again. Depending on how well you theme was designed, your website might actually work (without the added functionality provided by the plugins). Then you could try adding plugins again (one by one) to see if any of these is causing the problem.

You can check for known issues on http://codex.wordpress.org/Plugins/Plugin_Compatibility/2.6
At the moment it seems Stattraq 1.1.1 is the only plugin with (related) issues (“Has problems with the changed cookie/login system”).
If you’re using this plugin, you might want to start with disabling this plugin by moving it out of the plugins/ directory.

@jamesisin: http://www.soundunreason.com/InkWell/index.php?2008/07/12/bring-out-yer-dead/ does work.

@alexrabe: the mentioned plugins make the zip-upload fail, even if there are only two plugins active: NextGEN Gallery and one from the list.

I don’t think it’s a memory issue either: the machine is dedicated to one website (for now it’s the only one running on it). There is 1GB of fysical memory, but below are the limits as known by NextGEN Gallery.

There are no PHP errors either. I really have no clue where to go next.

Server Settings

* Operating System : FreeBSD
* Server : Apache/1.3.41 (Unix) PHP/5.2.6 with Suhosin-Patch
* Memory usage : 12.17 MByte
* MYSQL Version : 5.0.51a
* SQL Mode : Not set
* PHP Version : 5.2.6
* PHP Safe Mode : Off
* PHP Allow URL fopen : On
* PHP Memory Limit : 128M
* PHP Max Upload Size : 64M
* PHP Max Post Size : 64M
* PHP Max Script Execute Time : 30s
* PHP Exif support : No
* PHP IPTC support : Yes
* PHP XML support : Yes

GD support

* GD Version : bundled (2.0.34 compatible)
* FreeType Support : Yes
* FreeType Linkage : with freetype
* T1Lib Support : Yes
* GIF Read Support : Yes
* GIF Create Support : Yes
* JPG Support : Yes
* PNG Support : Yes
* WBMP Support : Yes
* XPM Support : Yes
* XBM Support : Yes
* JIS-mapped Japanese Font Support : No

Hi,

I can delete drafts without problem, using WordPress 2.6 and Google XML Sitemaps 3.1.0.1

Edde

Hi Alex,

This doesn’t seem to be it 😐
Any other ideas?

Thanks!
Edde

*** SCRIPT START ***
debug test.php> initialize

This script demonstrate the Memory-limit failure of the current 1&1 Server. The Script should create 6 images with imagecreatefromjpeg(). But the PHP/GD hosting of 1&1 stopped the creating of images much earlier… and do not return any error message. This is reported in a Apache/1.3.34 Ben-SSL/1.55 PHP/4.4.8 environment.

PHP Memory Limit: 64M Usage before: 75.38 KB

[6x something like this:

debug test.php> code-lines: 44-36 time: 0.0249 mem: 80 KB
Calculated : 20.95 MB
Loading image 2400×1800.jpg, size 2400 * 1800, bpp 8, channels 3… done
debug test.php> code-lines: 36-44 time: 0.2548 mem: 21280 KB
Memory usage: 20.78 MB
Difference: 20.7 MB
Difference / (Width * Height * Bytes per pixel): 1.6750172839506
Destroyed. Memory usage: 79.75 KB

]

Mean fudge factor: 1.683123146206
*** SCRIPT END ***

@jinge: Well, to be honest, removing index.php from your permalinks wasn’t my idea. It was Otto42’s. Incorrect settings in .htaccess or permalink structure was what we both expected to be the source of your problems.

@gregrickaby (& Otto42): the canonical redirects indeed kick ass! gregrickaby: try changing the page slug of some test page to something new (after publishing). Then try to access the page at the old address. You will be redirected to the new location. That – and a zillion other reasons – is why WordPress rocks!

@jinge: the problem lies in the apache config / .htaccess if removing the .htaccess file solves the problem. Apache gives this error of you’re trying to make it do something it doesn’t want to do (apache config) or doesn’t understand (error in your file).

Putting back an old version of wordpress won’t help either: once you ran update.php the changes to the database are there to stay. Unless you restore a backup. I don’t think running WP 2.5.1 files in combination with a WP 2.6 database will improve things.

Try creating an empty .htaccess with the right permissions. Update your permalink structure and check if the file is updated correctly.
(remove old .htaccess, type touch .htaccess and then chmod 777 .htaccess).

I remember now I’ve had this error too: a lethal combination of customized WordPress permalinks and no .htaccess file to match.