I met with 2 problems:
1. A have alias for my article - /name1 . So when I go to edit page it looks like /node/12/edit ,
instead of /name1/edit. I think it supposed to be like in the last variant. Isn't it?
Maybe the reason in the second problem:
2. When I try clear cache I always get smth like this: "Fatal error: Allowed memory size of XXX bytes exhausted (tried to allocate 47 bytes) in D:\xampp\htdocs\sitename\includes\menu.inc on line 3624".
By the way, the file and the line number can be different ( e.g. ...\database\database.inc on line 429).
When I found out at drupal.org that php memory limit can cause this error I tried 256M, 512, even 1GB. No change.
So I restore the site from backup and added last modules (sub-pathauto one of them). And error appeared again. I don't know what's the problem, but it can be in compatibility with other path modules. I have redirect, globalredirect on my site.
Comments
Comment #1
ACD commentedin addition: the bug doesn't tie with redirect and globalredirect modules, it appears even when those two are disabled and deleted
Comment #2
muriqui commentedJust ran into this on a client's site, as well... The site normally runs fine with PHP's memory_limit at 500M and max_execution_time at 60s. Tried to add a new content type, and it crashed out with memory exhausted. Tried bumping up the limits several times, and ultimately had it tuned up to 1500M and 120s, but that still wasn't enough. Disabling subpathauto instantly fixed the problem. So, I ran it through xdebug to see what was going on, and found that when submitting the "add new content type" form, subpathauto_url_inbound_alter() was getting triggered hundreds of times, with each run triggering menu_rebuild() as a result of the
$item = menu_get_item($path);statement on line 25 of subpathauto.module.Comment #3
aron novakI can confirm that it's still a problem that occurs sometimes. I will try to provide a patch soon.
Evil workaround if you must proceed:
at subpathauto_url_inbound_alter(), as a first statement, add "return;" when you experience this. Let the caches fill, your system should be back, remove the return and then do a menu_rebuild() (from drush for example)
In my case i could not disable subpathauto, as drush pm-disable subpathauto resulted in this same memory-crunching
Comment #4
chili.hh commentedI can prove this issue as well. Ran into this error after updating from v7.x-1.1 to 7.x-1.3.
In my case it seems that this issue arises in conjunction with xmlsitemap.
Snippet from my backtrace:
The above snippet is the part which is always repeating, so it might be the case of two competing url alter calls... but that's just a guess without having stepped intp the code...
Comment #5
rooby commentedI am seeing the same thing as #4.
It seemingly started happening after I saved the configuration of a view.
Comment #6
rooby commentedComment #7
rooby commentedThis is a duplicate of #1790508: Site unavailable after module update and there is a patch there that fixes the issue.