<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>

CC BY-SA 3.0
2015-04-08T17:33:17.470Z
Wow... nice catch and thanks for sharing.
Brad Bell
CC BY-SA 3.0
2015-04-08T17:31:47.853Z
2015-04-08T17:31:47.853Z
nateiler
<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>

CC BY-SA 3.0
2015-04-07T23:01:08.433Z
Was anyone able to determine what the issue with this was?
nateiler
CC BY-SA 3.0
2015-01-21T22:05:57.927Z
Is it just the entries that are 404'ing or every page of the CP?
Brad Bell
CC BY-SA 3.0
2015-01-21T23:57:21.543Z
Just the entries.
Mike
CC BY-SA 3.0
2015-01-21T23:58:17.597Z
Some .htaccess rule interfering with the request?
Brad Bell
CC BY-SA 3.0
2015-01-22T00:06:48.373Z
Just posted .htaccess contents. Doesn't look like anything out of the ordinary but then again I'm not overly familiar with Craft.
Mike
CC BY-SA 3.0
2015-01-22T01:04:27.250Z
Can you share what's in your craft/config/general.php file?
Brad Bell
CC BY-SA 3.0
2015-01-22T02:12:53.703Z
It appears to be empty.
Mike
CC BY-SA 3.0
2015-01-22T03:20:37.127Z
Maybe someone else has some ideas... I'm a bit stumped.
Brad Bell
CC BY-SA 3.0
2015-01-25T23:38:52.127Z
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?
Mike
CC BY-SA 3.0
2015-01-26T01:44:52.490Z
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.
Brad Bell
<entries><error><404>
Admin entries 404'ing
# 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.

Any tips would be greatly appreciated.
-- Update
Here's the contents of the .htaccess

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.php

**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:
(?:[a-zA-Z][a-zA-Z0-9_]*))\/(?P\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.  

---

