Ben

Thanks Joss - that's a good workaround. I hadn't thought of that. Though, there would still be some instances with more than one image (varies template to template).

As long as your environments are hitting unique server names (dev.example.com, www.example.com), I don't think session collision should be a problem.

 

In the login form, do you have a CSRF token (the _post_token hidden input)? Any chance you're using a custom admin theme?

 

EDIT: You could try another setting, in config.php:

 

$config->protectCSRF = false; 

 

It's best to leave it enabled, but it might help rule out other issues.

Technically, current versions of ProcessWire shouldn't even receive that request if your htaccess is working properly.

 

Thanks Ryan. That may have something to do with the Linux/WIndows deviation - Windows (localhost dev) is on Apache and Linux is running nginx. I'll have to take a closer look at the .htaccess file and make sure to create a parrallel rule for nginx. I believe I may have overdistilled the test case above, a better example would be (apologies for the oversight):

 

http://www.example.com/news/*/news

 

I'll dig a little deeper into the rewrite rules angle.

 

EDIT: Forgot to mention -- I am just pasting the url into the browser. I'm running PW 2.2, PHP 5.4, and nginx.

EDIT #2: Digging deeper, I don't think the htaccess rules stop the behavior because they are encoded before leaving the browser - they're coming through in the logs as hexidecimal encoded characters.

I've seen a couple of these myself happen due to malformed markdown links, it's reproducible. To cause it - you take any page above the homepage, and add a special character (!@#$%^&*()) followed by a backslash. It'll throw the rootparent error.

 

For example, http://www.example.com/news/*/ seems to throw it consistenly in LAMP, though not in a Windows environment for some reason.

 

Not sure of the etiquette, perhaps I should've created a new thread rather than reanimate one that's over a year old?

I think it is normal, just checked and I see 7k session files - the oldest of which is from yesterday. The directory seems to be cleaning up after itself.

You may be approaching a hard limit of 32k if your filesystem is ext3, plenty of headroom if you're on ext4 though. I'd make sure that the files are being removed (automatically) - if not there may be a permissions issue.

Edit: incorrect. 32k is the ext3 limit for subdirectories, not files.