<p>I can think of a couple things why this is happening:</p>
<h1>1) Custom code doing a save operation.</h1>
<p>If you're hooking into <a href="https://craftcms.com/docs/plugins/events-reference#entries-onSaveEntry" rel="nofollow noreferrer"><code>onSaveEntry</code></a> for example,  Craft also lets other plugins have a chance at calling their own save code as well.</p>
<p>So when you do a <code>saveEntry</code> (or other element), Craft is going to <em>repeat</em> that call when you do it from your own code, basically putting you into an infinite loop because it keeps getting called until the server times out.</p>
<p>The fix is to make sure  you only call <code>saveEntry</code> once. There's a couple ways to do this depending on what you're trying to do.</p>
<p>One way to debug this would be to a create super simple plugin, using <a href="https://github.com/lindseydiloreto/craft-businesslogic" rel="nofollow noreferrer">Business Logic</a> or <a href="https://pluginfactory.io" rel="nofollow noreferrer">PluginFactory</a> that listens for the <code>saveEntry</code> event and <a href="https://craftcms.stackexchange.com/questions/2905/how-to-log-info-from-an-onsaveentry-event">logs it</a>.</p>
<p>If you see the plugin's log fill up, then some plugin is putting itself into a loop more than once.</p>
<h1>2) runTasksAutomatically is not being called</h1>
<p>Over time, Craft generates a lot of cache files, sessions, etc. Craft will automatically do some housekeeping for you and clean this up, however, the <a href="https://craftcms.com/docs/config-settings#runTasksAutomatically" rel="nofollow noreferrer"><code>runTasksAutomatically</code></a> config doesn't run on some server setups, forcing you to do the maintenance yourself. It's like a stuffed up drain, if it doesn't run for awhile, it takes longer to purge.</p>
<p>If your server doesn't support cron, you could use an uptime monitoring service like <a href="https://uptimerobot.com" rel="nofollow noreferrer">Uptime Robot</a> or Pingdom to trigger the task call for you periodically.</p>

CC BY-SA 3.0
2017-10-09T07:42:14.750Z
Ok, so to debug things, if #1 is the culprit, would disabling all third-party plugins resolve the issue? And where would I see info about `runTasksAutomatically`? I looked in both the Server Info and Craft Logs screens but found nothing to indicate it wasn't successfully running. The server _does_ appear to have gzip enabled though, which the docs mention is incompatible with `runTasksAutomatically`. So I'm guessing that's the culprit?
Sandwich
CC BY-SA 3.0
2017-10-10T17:57:45.220Z
I've updated my answer for a couple ways you could test this for both.  #2 is more insidious. It seems to only happen on Apache, not nginx. I've used PHP's FPM on both and Apache has always given me problems. No need for cron on nginx, it just works.
RitterKnight
CC BY-SA 3.0
2017-10-11T11:02:03.373Z
Ok, cool... I still would like to know if disabling 3rd-party plugins would address #1; I barely have any installed, and the site is still in development, so it's easy to do. As for #2, the sysadmin already disabled gzip (and replaced it with "php compression"), so I'll be testing that for a bit.
Sandwich
CC BY-SA 3.0
2017-10-11T22:07:40.587Z
@Sandwich: yeh disabling would do the same thing.
RitterKnight
CC BY-SA 3.0
2017-10-07T16:14:35.680Z
2017-10-10T18:03:35.223Z
2020-06-17T08:56:27.903Z
RitterKnight
<p>Occasionally—I'd say about 30-40% of the time—when submitting a form in the backend, be it saving an entry, updating a custom field, etc, the page will just sit there, loading. This can and often does continue for ~ 299.88 seconds, after which it will proceed to the next screen as if nothing ever happened.</p>

<p>I've looked through the console log, but all the timestamps seem to be within a second of each other, so nothing jumps out as the step where things are getting hung up. I suspect a server problem, but I'm posting here just in case anyone can point me in a more specific direction than "there's a problem somewhere".</p>

<p>To date, this has not occurred on the frontend, but there aren't any frontend forms to submit, either.</p>

<p>Pastebin of the console log (the load time is on line 725): <a href="https://pastebin.com/aB4JkrBv" rel="nofollow noreferrer">https://pastebin.com/aB4JkrBv</a></p>

<control-panel><timeout>
CP form submissions occasionally reaching PHP's 300 second timeout
# CP form submissions occasionally reaching PHP's 300 second timeout

(Asked by: username_0 on 2017-10-07)

Occasionally—I'd say about 30-40% of the time—when submitting a form in the backend, be it saving an entry, updating a custom field, etc, the page will just sit there, loading. This can and often does continue for ~ 299.88 seconds, after which it will proceed to the next screen as if nothing ever happened.

I've looked through the console log, but all the timestamps seem to be within a second of each other, so nothing jumps out as the step where things are getting hung up. I suspect a server problem, but I'm posting here just in case anyone can point me in a more specific direction than "there's a problem somewhere".

To date, this has not occurred on the frontend, but there aren't any frontend forms to submit, either.

Pastebin of the console log (the load time is on line 725): <https://pastebin.com/aB4JkrBv>

**Tags:** control-panel, timeout


---

## 1 answers

### Answer by username_1 on 2017-10-07. Score: 3

I can think of a couple things why this is happening:

# 1) Custom code doing a save operation.

If you're hooking into [`onSaveEntry`](https://craftcms.com/docs/plugins/events-reference#entries-onSaveEntry) for example, Craft also lets other plugins have a chance at calling their own save code as well.

So when you do a `saveEntry` (or other element), Craft is going to *repeat* that call when you do it from your own code, basically putting you into an infinite loop because it keeps getting called until the server times out.

The fix is to make sure you only call `saveEntry` once. There's a couple ways to do this depending on what you're trying to do.

One way to debug this would be to a create super simple plugin, using [Business Logic](https://github.com/lindseydiloreto/craft-businesslogic) or [PluginFactory](https://pluginfactory.io) that listens for the `saveEntry` event and [logs it](https://craftcms.stackexchange.com/questions/2905/how-to-log-info-from-an-onsaveentry-event).

If you see the plugin's log fill up, then some plugin is putting itself into a loop more than once.

# 2) runTasksAutomatically is not being called

Over time, Craft generates a lot of cache files, sessions, etc. Craft will automatically do some housekeeping for you and clean this up, however, the [`runTasksAutomatically`](https://craftcms.com/docs/config-settings#runTasksAutomatically) config doesn't run on some server setups, forcing you to do the maintenance yourself. It's like a stuffed up drain, if it doesn't run for awhile, it takes longer to purge.

If your server doesn't support cron, you could use an uptime monitoring service like [Uptime Robot](https://uptimerobot.com) or Pingdom to trigger the task call for you periodically.

> **Comments:**
> **username_0**: Ok, so to debug things, if #1 is the culprit, would disabling all third-party plugins resolve the issue? And where would I see info about `runTasksAutomatically`? I looked in both the Server Info and Craft Logs screens but found nothing to indicate it wasn't successfully running. The server _does_ appear to have gzip enabled though, which the docs mention is incompatible with `runTasksAutomatically`. So I'm guessing that's the culprit?  
> **username_1**: I've updated my answer for a couple ways you could test this for both.  #2 is more insidious. It seems to only happen on Apache, not nginx. I've used PHP's FPM on both and Apache has always given me problems. No need for cron on nginx, it just works.  
> **username_0**: Ok, cool... I still would like to know if disabling 3rd-party plugins would address #1; I barely have any installed, and the site is still in development, so it's easy to do. As for #2, the sysadmin already disabled gzip (and replaced it with "php compression"), so I'll be testing that for a bit.  
> **username_1**: @username_0: yeh disabling would do the same thing.  

---

