I've transferred a Craft site (I didn't build it) from staging to production. All the existing content is showing up on the front end but when I try to edit entries that aren't static pages, the edit pages are 404'ing.


Any tips would be greatly appreciated.

-- Update

Here's the contents of the .htaccess

<IfModule mod_rewrite.c>
RewriteEngine On

# Send would-be 404 requests to Craft
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/(favicon\.ico|apple-touch-icon.*\.png)$ [NC]
RewriteRule (.+) index.php?p=$1 [QSA,L]



 * General Configuration
 * All of your system's general configuration settings go in here.
 * You can see a list of the default settings craft/app/etc/config/defaults/general.php

return array(

  • Is it just the entries that are 404'ing or every page of the CP?
    – Brad Bell
    Jan 21, 2015 at 22:05
  • Just the entries.
    – Mike
    Jan 21, 2015 at 23:57
  • Some .htaccess rule interfering with the request?
    – Brad Bell
    Jan 21, 2015 at 23:58
  • Just posted .htaccess contents. Doesn't look like anything out of the ordinary but then again I'm not overly familiar with Craft.
    – Mike
    Jan 22, 2015 at 0:06
  • Can you share what's in your craft/config/general.php file?
    – Brad Bell
    Jan 22, 2015 at 1:04

1 Answer 1


I was able to trace my particular issue to an old PCRE version which resulted in long regular expression strings to silently fail... causing the 'preg_match' to not match the edit entries string found here:


A quick test:

$path = 'entries/homepage/1-homepage';
$regexPattern = 'entries\/(?P<sectionHandle>(?:[a-zA-Z][a-zA-Z0-9_]*))\/(?P<entryId>\d+)(?:-(?:[\p{L}\p{N}\._\-]+))?';

var_dump(preg_match('/^'.$regexPattern.'$/u', $path, $match));

Should output in: 1 but was resulting in 0

The server is running a very old (from 2006) version of PCRE (PHP 5.3.3).

Running the following command:

pcretest -C

Resulted in the following version:

PCRE version 6.6 06-Feb-2006
Compiled with
  UTF-8 support
  No Unicode properties support
  Newline character is LF
  Internal link size = 2
  POSIX malloc threshold = 10
  Default match limit = 10000000
  Default recursion depth limit = 10000000
  Match recursion uses stack

This issue does not persist with the following version of PCRE (from a local Vagrant box):

PCRE version 7.8 2008-09-05
Compiled with
  UTF-8 support
  Unicode properties support
  Newline sequence is LF
  \R matches all Unicode newlines
  Internal link size = 2
  POSIX malloc threshold = 10
  Default match limit = 10000000
  Default recursion depth limit = 10000000
  Match recursion uses stack

I ended up solving this issue by migrating the sever to an AWS instance running PHP v5.6 You could also upgrade/rebuild PHP, but there are too many dependencies on the server. I also tried increasing the backtrace and recursion limits, without success:

I tried adding this to my .htaccess file (FYI: I do not recommend setting this to 2Mb):

php_value pcre.backtrack_limit 2097152
php_value pcre.recursion_limit 2097152

Hope this helps

  • Wow... nice catch and thanks for sharing.
    – Brad Bell
    Apr 8, 2015 at 17:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.