Broken wordpress permalinks on pages only

0 Views

Not sure when it happened but the custom permalinks for pages on my client’s WordPress site have broken. I can fix it by reverting back to the default permalinks and then using the custom permalinks, but they break again whenever my clients edits a page. Blog posts, archives, tags, categories, and custom post types permalinks all work fine, it’s only pages that 404 when using custom permalinks.

The site has an .htaccess file with 666 permissions with the following in the file:

Read More
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

It also has mod_rewrite enabled.

Using WordPress 3.1.3

It’s not the plugins because I have disabled all of them and the permalinks for pages still don’t work.

Please help.

Post Views: 0

Related posts

Leave a Reply

3 comments

  1. Do you have a custom post type? This is exactly the kind of behavior you will see from have a custom post type with a slug that matches the slug of your pages. For example, if you have a page called “portfolio” and a post type called “portfolio”, both with a slug of “portfolio”, 404s are going to be thrown for some of these.

  2. I was using the Custom Post Type UI Plugin and had generated the following code (which I added to the functions file) for a custom taxonomy through the plugin:

    register_taxonomy( 'video_type',
    array ( 0 => 'video' ),
    array( 
        'hierarchical'    => true,
        'label'           => 'Type',
        'show_ui'         => true,
        'query_var'       => true,
        'rewrite'         => array( 'slug' => '' ),
        'singular_label'  => 'video_type'

    Somehow that code broke the theme. In Custom Post Type UI you can either create custom posts types and taxonomies and keep the plugin active or use the beta function to copy and paste generated code to your function file. So I ended up deleting that code and keeping the plugin active.

  3. This happened to a client’s WordPress installation after a malicious attack. The .htaccess file had been tampered with and the theme’s functions.php had a new obfuscated function at the top of the file.

    Reverting to the standard .htaccess file and removing the offending function fixed the problem for me.

    (Of course, that’s not to say other files were not compromised.)