Static placeholder triggering a cache set on every request or always part of the SQL queries

I’ve got a static_placeholder in my base template for the footer of the site.

            <div class="wrapper"><!-- Start wrapper -->

                {% block base-static-footer %}
                    {% static_placeholder "footer" site %}
                {% endblock base-static-footer %}

            </div><!-- End wrapper -->

This testing is happening on my local machine running memcache, in debug mode, without being logged in. Cache settings;

CMS_PAGE_CACHE = False
CMS_PLACEHOLDER_CACHE = True
CMS_PLUGIN_CACHE = True

# -- CMS CACHE DEFAULTS INCREASED -- #
CMS_CACHE_DURATIONS = {
    'menus': 3600,  # default: 3600
    'content': 3600,  # default: 60
    'permissions': 3600,  # default: 3600
}

As I understand it, all static placeholders are cached, and I’ve had my breakpoints in PyCharm to watch what’s happening with all the placeholders on my homepage & it looks as though the footer calls the cache.set as expected.

However if you monitor the debug toolbar on each page refresh, there are 2 cache sets, one comes from the static footer, the other from the cache version.

Now step forward 24 hours & I’m seeing between 54 & 15 SQL queries per request, and in each instance, the static footer is part of the database hits, so today I’m not even seeing the cache sets that I was yesterday (no code/config changes in that time). SQL query;

SELECT ••• FROM `cms_staticplaceholder` WHERE (`cms_staticplaceholder`.`code` = 'footer' AND `cms_staticplaceholder`.`site_id` = 1) LIMIT 21

The end of the stack on that query is;

/Users/mwalker/Sites/proj/lib/python2.7/site-packages/cms/templatetags/cms_tags.py in render_tag(670)
  rendered_contents = nodelist.render(context)
/Users/mwalker/Sites/proj/lib/python2.7/site-packages/classytags/core.py in render(106)
  return self.render_tag(context, **kwargs)
/Users/mwalker/Sites/proj/lib/python2.7/site-packages/classytags/helpers.py in render_tag(87)
  output = render_to_string(template, data)
/Users/mwalker/Sites/proj/lib/python2.7/site-packages/classytags/core.py in render(106)
  return self.render_tag(context, **kwargs)
/Users/mwalker/Sites/proj/lib/python2.7/site-packages/cms/templatetags/cms_tags.py in render_tag(1121)
  'creation_method': StaticPlaceholder.CREATION_BY_TEMPLATE})

Also, I’m seeing queries relating to other apps which sit on other pages via an app hook, but show as coming from {% static_placeholder "footer" site %} when you inspect the query in the debug toolbar. In this instance, the body attribute of the LatestNews model is a PlaceholderField;

SELECT COUNT(*) FROM `news_latestnews` WHERE `news_latestnews`.`body_id` = 50

Is that query triggered because the ID of LatestNews.body (PlaceholderField) could potentially be 50? It seems an odd query, given the template tag is static_placeholder and it might have an ID of 50, but then why does it query my app’s placeholder field?

And if it helps, the bottom end of the stack on that query is;

/Users/mwalker/Sites/proj/lib/python2.7/site-packages/cms/templatetags/cms_tags.py in render_tag(1137)
  content = render_placeholder(placeholder, context, name_fallback=code, default=nodelist)
/Users/mwalker/Sites/proj/lib/python2.7/site-packages/cms/plugin_rendering.py in render_placeholder(115)
  if placeholder.has_change_permission(request) or not placeholder.cache_placeholder:
/Users/mwalker/Sites/proj/lib/python2.7/site-packages/cms/models/placeholdermodel.py in has_change_permission(118)
  return self._get_permission(request, 'change')
/Users/mwalker/Sites/proj/lib/python2.7/site-packages/cms/models/placeholdermodel.py in _get_permission(107)
  for obj in self._get_attached_objects():
/Users/mwalker/Sites/proj/lib/python2.7/site-packages/cms/models/placeholdermodel.py in _get_attached_objects(227)
  return [obj for field in self._get_attached_fields()
/Users/mwalker/Sites/proj/lib/python2.7/site-packages/cms/models/placeholdermodel.py in _get_attached_fields(157)
  if field.count():

[Aiky30]

Hello @marksweb,

Thank you very much for your contribution to the django CMS project. The django CMS project has recently joined forces under the banner of the newly founded django CMS Association to revive the development of django CMS. For this reason we have analyzed all pull requests and issues in detail and decided which ones fit the product vision we want to go with django CMS.

Due to the age of this issue we are unable to safely accept the contribution. If you feel this issue is still required please inform a member of our technical committee: [e-mail].

Nevertheless we thank you for your participation and would like to emphasize that we do not want to discourage you in your contribution to the django CMS project. On the contrary, we encourage everyone who is interested in the success of django CMS to join us!

If you want to learn more about the work of the technical committee, our product vision and how you can become a member of the dCA, you can find all information here:

• The Technical Committee of the django CMS Association
• Technical Roadmap and Product Vision for django CMS
• How to become a member of the django CMS Association

We are looking forward to every companion who would like to shape the future of django CMS together with us!

If you have any questions, feel free to reach out to Nicolai, our Community Manager: [e-mail]

Sign up for the Association now!

[mkoistinen]

Hi @marksweb I’m not in a position to spend any time on this for the foreseeable future. Sorry. Perhaps you can add some test cases, etc., to your monkey-patches and make it a pull request?