Answers.Body: <p>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:</p>
  
  <pre><code>craft/app/etc/web/UrlManager.php:387
  </code></pre>
  
  <p>A quick test:</p>
  
  <pre><code>&lt;?php
  $path = 'entries/homepage/1-homepage';
  $regexPattern = 'entries\/(?P&lt;sectionHandle&gt;(?:[a-zA-Z][a-zA-Z0-9_]*))\/(?P&lt;entryId&gt;\d+)(?:-(?:[\p{L}\p{N}\._\-]+))?';
  
  var_dump(preg_match('/^'.$regexPattern.'$/u', $path, $match));
  </code></pre>
  
  <p>Should output in: 1 but was resulting in 0</p>
  
  <p>The server is running a very old (from 2006) version of PCRE (PHP 5.3.3). </p>
  
  <p>Running the following command:</p>
  
  <pre><code>pcretest -C
  </code></pre>
  
  <p>Resulted in the following version:</p>
  
  <pre><code>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
  </code></pre>
  
  <p>This issue does not persist with the following version of PCRE (from a local Vagrant box):</p>
  
  <pre><code>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
  </code></pre>
  
  <p>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:</p>
  
  <p>I tried adding this to my .htaccess file (FYI: I do not recommend setting this to 2Mb):</p>
  
  <pre><code>php_value pcre.backtrack_limit 2097152
  php_value pcre.recursion_limit 2097152
  </code></pre>
  
  <p>Hope this helps</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-08T17:33:17.470Z
Answers.Text: Wow... nice catch and thanks for sharing.
Answers.UserDisplayName: Brad Bell
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-08T17:31:47.853Z
Answers.LastActivityDate: 2015-04-08T17:31:47.853Z
Answers.UserDisplayName: nateiler
Body: <p>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.</p>
  
  <p><img src="https://i.sstatic.net/S6F9v.png" alt="404"></p>
  
  <p>Any tips would be greatly appreciated.</p>
  
  <p>-- Update</p>
  
  <p>Here's the contents of the .htaccess</p>
  
  <pre><code>&lt;IfModule mod_rewrite.c&gt;
  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]
  &lt;/IfModule&gt;
  </code></pre>
  
  <p>general.php</p>
  
  <pre><code>&lt;?php
  
  /**
   * 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(
  
  );
  </code></pre>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-04-07T23:01:08.433Z
Comments.Text: Was anyone able to determine what the issue with this was?
Comments.UserDisplayName: nateiler
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-01-21T22:05:57.927Z
Comments.Text: Is it just the entries that are 404'ing or every page of the CP?
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-01-21T23:57:21.543Z
Comments.Text: Just the entries.
Comments.UserDisplayName: Mike
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-01-21T23:58:17.597Z
Comments.Text: Some .htaccess rule interfering with the request?
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-01-22T00:06:48.373Z
Comments.Text: Just posted .htaccess contents. Doesn't look like anything out of the ordinary but then again I'm not overly familiar with Craft.
Comments.UserDisplayName: Mike
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-01-22T01:04:27.250Z
Comments.Text: Can you share what's in your craft/config/general.php file?
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-01-22T02:12:53.703Z
Comments.Text: It appears to be empty.
Comments.UserDisplayName: Mike
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-01-22T03:20:37.127Z
Comments.Text: Maybe someone else has some ideas... I'm a bit stumped.
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-01-25T23:38:52.127Z
Comments.Text: It appears that even when they click New Entry to create content, it takes them to a 404 page. Does that trigger any further thoughts?
Comments.UserDisplayName: Mike
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-01-26T01:44:52.490Z
Comments.Text: Not particularly... if you can't get it supported send some CP/FTP creds over to support@buildwithcraft.com and we'll take a stab at it.
Comments.UserDisplayName: Brad Bell
Tags: <entries><error><404>
Title: Admin entries 404'ing
ThreadText: # Admin entries 404'ing
  
  (Asked by: username_0 on 2015-01-21)
  
  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.
  
  ![404](https://i.sstatic.net/S6F9v.png)
  
  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]
  </IfModule>
  
  ```
  
  general.php
  
  ```
  <?php
  
  /**
   * 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(
  
  );
  
  ```
  
  **Tags:** entries, error, 404
  
  > **Comments:**
  > **username_2**: Is it just the entries that are 404'ing or every page of the CP?  
  > **username_0**: Just the entries.  
  > **username_2**: Some .htaccess rule interfering with the request?  
  > **username_0**: Just posted .htaccess contents. Doesn't look like anything out of the ordinary but then again I'm not overly familiar with Craft.  
  > **username_2**: Can you share what's in your craft/config/general.php file?  
  > **username_0**: It appears to be empty.  
  > **username_2**: Maybe someone else has some ideas... I'm a bit stumped.  
  > **username_0**: It appears that even when they click New Entry to create content, it takes them to a 404 page. Does that trigger any further thoughts?  
  > **username_2**: Not particularly... if you can't get it supported send some CP/FTP creds over to support@buildwithcraft.com and we'll take a stab at it.  
  > **username_1**: Was anyone able to determine what the issue with this was?  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2015-04-08. Score: 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:
  
  ```
  craft/app/etc/web/UrlManager.php:387
  
  ```
  
  A quick test:
  
  ```
  <?php
  $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
  
  > **Comments:**
  > **username_2**: Wow... nice catch and thanks for sharing.  
  
  ---
  
  