Answers.Body: <p>This should be fixed for the upcoming 3.2.11 release.</p>
  
  <p>To get the fix early, change your <code>craftcms/cms</code> requirement in composer.json to:</p>
  
  <pre><code>"require": {
    "craftcms/cms": "dev-develop#87fd6ca6b0c57f524c8ccae895c13eb9724d0efa as 3.2.10",
    "...": "..."
  }
  </code></pre>
  
  <p>Then run <code>composer update</code>.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-08-31T13:25:19.000Z
Answers.Text: FWIW, I just updated to v3.3.0.1 and I'm still seeing this sort of behavior.
Answers.UserDisplayName: Jason Morehead
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-08-14T16:01:33.827Z
Answers.LastActivityDate: 2019-08-14T16:01:33.827Z
Answers.UserDisplayName: Brandon Kelly
Body: <p>My blog has a date archive page that uses a variation of <a href="https://craftcms.com/guides/creating-an-archive-page-for-entries#grouping-by-year-and-then-month" rel="nofollow noreferrer">this code</a>. Here's the code that I've been using:</p>
  
  <pre><code>{% set allEntries = craft.entries.section('entries').type(['posts','reviews']).limit(null).all() %}
  
  &lt;ul&gt;
  
  {% for year, entriesInYear in allEntries | group("postDate.year") %}
      &lt;li&gt;
  
          &lt;h3&gt;{{ year }}&lt;/h3&gt;
  
          &lt;ol&gt;
          {% for month, entriesInMonth in entriesInYear|group("postDate|date('F Y')") %}
              &lt;li&gt;&lt;a href="/archives/{{ month|date('Y') }}/{{ month|date('m') }}"&gt;{{ month|date('M') }}&lt;/a&gt;&lt;/li&gt;
          {% endfor %}
          &lt;/ol&gt;
  
      &lt;/li&gt;
  {% endfor %}
  
  &lt;/ul&gt;
  </code></pre>
  
  <p>Basically, it printed out a list of the years and months in a grid a la <a href="https://kottke.org/everfresh" rel="nofollow noreferrer">kottke.org's "Monthly archives" section</a>. But after upgrading to Craft v3.2.9, the code no longer works. Instead, the page just displays a generic "Internal Server Error" message.</p>
  
  <p>Looking at the error logs, the server ran out of memory trying to run the above code. If I remove the above code, then the page loads in a snap.</p>
  
  <p>As a test, I streamlined the code by removing the nested grouping:</p>
  
  <pre><code>{% set allEntries = craft.entries.section('entries').type(['posts','reviews']).limit(null) %}
  
  &lt;ul&gt;
  
  {% for year, entriesInYear in allEntries | group("postDate.year") %}
      &lt;li class="dtsY u-flexWrap"&gt;
  
          &lt;h3&gt;{{ year }}&lt;/h3&gt;
  
      &lt;/li&gt;
  {% endfor %}
  
  &lt;/ul&gt;
  </code></pre>
  
  <p>But that still results in the same memory-related error.</p>
  
  <p>FWIW, my blog has 4,100+ entries spanning 22 years, so is there just too much content for the above queries to handle? And if so, are there ways to optimize the code and/or make it less dependent on DB queries? While I can increase the server memory, I'd prefer to find a template-based solution first.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-08-10T18:49:35.147Z
Comments.Text: Is the page cached at all using the Craft `{% cache %}` tags?
Comments.UserDisplayName: andrew.welch
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-08-11T02:55:26.620Z
Comments.Text: Yes, the `{% cache %}` tags are used on that template. However, the page doesn't even load so that it can be cached. It always results in the aforementioned "Internal Server Error."
Comments.UserDisplayName: Jason Morehead
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-08-11T04:54:07.760Z
Comments.Text: Same issue here - I have had an open bug with the Craft folks about this for a couple weeks...have not got a solution yet... ( & even increasing memory very substantially does not solve it).
  
  
  (@andrew.welch this was the same bug I was having they initially thought was maybe Seomatic related, and you put me on to Redis (which is handy, but didn't solve this)...it's definitely not Seomatic but some post 3.2 change with grouping I think.
Comments.UserDisplayName: Jeremy Daalder
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-08-12T23:47:54.803Z
Comments.Text: Going to go ahead and vote to close this as a bug... we're looking into the issue and should have it resolved soon.
Comments.UserDisplayName: Brad Bell
Tags: <templating><craft3><performance><archives><memory>
Title: My month/year archive template code no longer works in 3.2
ThreadText: # My month/year archive template code no longer works in 3.2
  
  (Asked by: username_0 on 2019-08-10)
  
  My blog has a date archive page that uses a variation of [this code](https://craftcms.com/guides/creating-an-archive-page-for-entries#grouping-by-year-and-then-month). Here's the code that I've been using:
  
  ```
  {% set allEntries = craft.entries.section('entries').type(['posts','reviews']).limit(null).all() %}
  
  <ul>
  
  {% for year, entriesInYear in allEntries | group("postDate.year") %}
      <li>
  
          <h3>{{ year }}</h3>
  
          <ol>
          {% for month, entriesInMonth in entriesInYear|group("postDate|date('F Y')") %}
              <li><a href="/archives/{{ month|date('Y') }}/{{ month|date('m') }}">{{ month|date('M') }}</a></li>
          {% endfor %}
          </ol>
  
      </li>
  {% endfor %}
  
  </ul>
  
  ```
  
  Basically, it printed out a list of the years and months in a grid a la [kottke.org's "Monthly archives" section](https://kottke.org/everfresh). But after upgrading to Craft v3.2.9, the code no longer works. Instead, the page just displays a generic "Internal Server Error" message.
  
  Looking at the error logs, the server ran out of memory trying to run the above code. If I remove the above code, then the page loads in a snap.
  
  As a test, I streamlined the code by removing the nested grouping:
  
  ```
  {% set allEntries = craft.entries.section('entries').type(['posts','reviews']).limit(null) %}
  
  <ul>
  
  {% for year, entriesInYear in allEntries | group("postDate.year") %}
      <li class="dtsY u-flexWrap">
  
          <h3>{{ year }}</h3>
  
      </li>
  {% endfor %}
  
  </ul>
  
  ```
  
  But that still results in the same memory-related error.
  
  FWIW, my blog has 4,100+ entries spanning 22 years, so is there just too much content for the above queries to handle? And if so, are there ways to optimize the code and/or make it less dependent on DB queries? While I can increase the server memory, I'd prefer to find a template-based solution first.
  
  **Tags:** templating, craft3, performance, archives, memory
  
  > **Comments:**
  > **username_1**: Is the page cached at all using the Craft `{% cache %}` tags?  
  > **username_0**: Yes, the `{% cache %}` tags are used on that template. However, the page doesn't even load so that it can be cached. It always results in the aforementioned "Internal Server Error."  
  > **username_2**: Same issue here - I have had an open bug with the Craft folks about this for a couple weeks...have not got a solution yet... ( & even increasing memory very substantially does not solve it).   (@username_1 this was the same bug I was having they initially thought was maybe Seomatic related, and you put me on to Redis (which is handy, but didn't solve this)...it's definitely not Seomatic but some post 3.2 change with grouping I think.  
  > **username_3**: Going to go ahead and vote to close this as a bug... we're looking into the issue and should have it resolved soon.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_4 on 2019-08-14. Score: 1
  
  This should be fixed for the upcoming 3.2.11 release.
  
  To get the fix early, change your `craftcms/cms` requirement in composer.json to:
  
  ```
  "require": {
    "craftcms/cms": "dev-develop#87fd6ca6b0c57f524c8ccae895c13eb9724d0efa as 3.2.10",
    "...": "..."
  }
  
  ```
  
  Then run `composer update`.
  
  > **Comments:**
  > **username_0**: FWIW, I just updated to v3.3.0.1 and I'm still seeing this sort of behavior.  
  
  ---
  
  