Giter Club home page Giter Club logo

django-sekizai's Introduction

Django Sekizai

pypi build coverage

Sekizai means "blocks" in Japanese, and that's what this app provides. A fresh look at blocks. With django-sekizai you can define placeholders where your blocks get rendered and at different places in your templates append to those blocks. This is especially useful for css and javascript. Your sub-templates can now define css and Javascript files to be included, and the css will be nicely put at the top and the Javascript to the bottom, just like you should. Also sekizai will ignore any duplicate content in a single block.

There are some issue/restrictions with this implementation due to how the django template language works, but if used properly it can be very useful and it is the media handling framework for the django CMS (since version 2.2).

Note

This project is endorsed by the django CMS Association. That means that it is officially accepted by the dCA as being in line with our roadmap vision and development/plugin policy. Join us on Slack.

Contribute to this project and win rewards

Because this is a an open-source project, we welcome everyone to get involved in the project and receive a reward for their contribution. Become part of a fantastic community and help us make django CMS the best CMS in the world.

We'll be delighted to receive your feedback in the form of issues and pull requests. Before submitting your pull request, please review our contribution guidelines.

We're grateful to all contributors who have helped create and maintain this package. Contributors are listed at the contributors section.

Documentation

See REQUIREMENTS in the setup.py file for additional dependencies:

python django

Please refer to the documentation in the docs/ directory for more information or visit our online documentation.

Running Tests

You can run tests by executing:

virtualenv env
source env/bin/activate
pip install -r tests/requirements.txt
python setup.py test

django-sekizai's People

Contributors

beniwohli avatar benjaoming avatar brutasse avatar dependabot[bot] avatar edwardbetts avatar finalangel avatar fsbraun avatar gst avatar jpvm5jyyre1vikl avatar mafermazu avatar marksweb avatar mickelus avatar nicolairidani avatar ojii avatar pakal avatar pannal avatar pre-commit-ci[bot] avatar timgraham avatar tomscytale avatar trumpet2012 avatar yakky avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

django-sekizai's Issues

TemplateSyntaxError with sekizai 0.10.0

Sekizai 0.10.0 raises a TemplateSyntaxError exception while trying to render line

{% render_block "css" %}

in the main django template.
The exception message says:

You must enable the 'sekizai.context_processors.sekizai' template context processor or use 'sekizai.context.SekizaiContext' to render your templates.

But the context processor is enabled in settings.py:

TEMPLATES = [                                                         
    {                                                                 
        'BACKEND': 'django.template.backends.django.DjangoTemplates', 
        'DIRS': [ os_path.join( BASE_DIR, 'templates' ) ],            
        'APP_DIRS': True,                                             
        'OPTIONS': {                                                  
            'context_processors': [                                   
              'django.template.context_processors.debug',           
              'django.contrib.auth.context_processors.auth',        
              'django.contrib.messages.context_processors.messages',
              ## for Django-CMS:                                    
              'sekizai.context_processors.sekizai',                 
              'cms.context_processors.cms_settings',                
              'django.template.context_processors.request',         
           ],                                                        
           'debug': True,                                            
       },                                                            
    },                                                                
]                                                                     

This issue only exists with sekizai 0.10.0, reverting to 0.9.0 fixes the problem.
Tested on Django 1.8.14, Python 3.4.3.

clarify why an invalid context exists.

If TEMPLATE_DEBUG is true, with some additional code complexity, validate_context could feasibly be more informative about why {% addtoblock %} may've failed. Specifically, it could actually do the necessary checks to test whether the context processor is installed, or a SekizaiContext is being used, and raise TemplateSyntaxError with more definitive messages explaining the nature of the problem.

[Docs] now sekizai is properly integrated in django-cms

README.rst

The last sentece should read:
There are some issue/restrictions with this implementation due to how the django template language works, but if used properly it can be very useful. Since django-cms version 2.2, it is the default media framework.

Or something like that.

Usage clarification

Could you please clarify:

Use one of the following:

  • Put sekizai.context_processors.sekizai into your TEMPLATE_CONTEXT_PROCESSORS setting and > use django.template.RequestContext when rendering your templates.
  • Use sekizai.context.SekizaiContext when rendering your templates.

Is this an "or" use here? Do one or the other?

Invalid block tag: 'endif'.

The question might concern classytags actually, but just in case - i'll write it here.

Consider this template for django-cms:

{% if something %}
{% else %}
{% load cms_tags sekizai_tags menu_tags %}
{% render_block "css" %}
{% render_block "js" %}
{% endif %}

Just this in template raises error - Invalid block tag: 'endif'. It does not matter what tag is the last one. Could be enblock just the same.

If you remove sekizay stuff, leaving template to:

{% if something %}
{% else %}
<h1>Hello world</h1>
{% endif %}

Then it renders just fine.

Error is generated within render_block templatetag code actually. If complete traceback is required then i can provide it, but i think creating simple test template for django-cms would work just fine. Using sekizai 0.7, classytags latest and django-cms 2.4.1

spaceless sekizai render_block

Hi!
When I wrap the template with {% spaceless %}, I get 500 error with Invalid block tag: 'endspaceless'
Thus, not to catch the exception I have to escape render_block tags like this:
{% spaceless %}"Anything here"{% endspaceless %} {% render_block "js" postprocessor "compressor.contrib.sekizai.compress" %} {% spaceless %}The rest of template{% endspaceless %}

"Sekizai data is unique" - but indent specific

if your template looks like this:

{% addtoblock 'js' %}
   <script src="my_script"></script>
{% endaddtoblock %}
{% addtoblock 'js' %}
      <script src="my_script"></script>
{% endaddtoblock %}

# The output will be:
    <script src="my_script"></script>
        <script src="my_script"></script>

Do you think that stripping rendered_contents in Addtoblock renderer is a good idea?

Template does not compile using with_data tag

I get an Invalid block tag: 'endblock' error when the template is being parsed (on dev server startup). Seems to be parsing past the end_with_data tag? My code:

{% block constants %}
    [javascript ....]
    {% with_data "plugins" as plugin_scripts %}
            {% for plugin_script in plugin_scripts %}
                {% if forloop.first %}[{% endif %}
                '{{ plugin_script }}'{% if not forloop.last%},{% endif %}
                {% if forloop.last %}]{% endif %}
            {% endfor %}
        {% end_with_data %}
   [more javascript...]
{% endblock %}

errors in helpers.py

[mod_wsgi, django1.4, django-cms2.3rc2.post0, django-sekizai0.6.1 work on apache], I am trying using django-cms2.3. I can access the first page of django-cms with django-cms logo (but sometimes it is 505 error, and after refreshing,the first page back again). When I access admin page of django-cms, I got 404 error. Errors about sekizai in apache log is

[error] [client 10.7.6.212]     if not validate_template(template[0], ['js', 'css']):
[error] [client 10.7.6.212]   File "/usr/lib/python2.6/site-packages/sekizai/helpers.py", line 98, in validate_template
[error] [client 10.7.6.212]     found = get_namespaces(template)
[error] [client 10.7.6.212]   File "/usr/lib/python2.6/site-packages/sekizai/helpers.py", line 89, in get_namespaces
[error] [client 10.7.6.212]     return _scan_namespaces(compiled_template.nodelist)
[error] [client 10.7.6.212]   File "/usr/lib/python2.6/site-packages/sekizai/helpers.py", line 79, in _scan_namespaces
[error] [client 10.7.6.212]     found += _extend_nodelist(node)
[error] [client 10.7.6.212]   File "/usr/lib/python2.6/site-packages/sekizai/helpers.py", line 52, in _extend_nodelist
[error] [client 10.7.6.212]     _extend_blocks(extend_node, blocks)
[error] [client 10.7.6.212]   File "/usr/lib/python2.6/site-packages/sekizai/helpers.py", line 25, in _extend_blocks

I that a compatible issue?

Allow running sdist setup.py test

For the next release, it would be helpful if the sdist uploaded to PyPi supported running setup.py test, e.g. by including and running runtests.py

libsass integration

This issue is to continue to evaluate strategies for integrating libsass into the workflow with django-sekizai as discussed in django-cms/django-cms#3600.

Since it seems as if there is no satisfying solution to do offline compression for files managed by Sekizai, one would have to install libsass on every production environment. This is not what we want.

Therefore I'd like to discuss a different approach. Instead of doing the compilation from *.scss to *.css, when the template engine "sees" this tag
{% render_block "css" postprocessor "compressor.contrib.sekizai.compress" %}
how about doing the compilation when the template engine "sees" this tag
{% addtoblock "css" %}<link href="{{ STATIC_URL }}css/my-style.scss" rel="stylesheet" type="text/x-scss" />{% endaddtoblock %}?

Then an auto generated file named, say <some-dir>/my-style-<somehashvalue>.css, could be added somewhere the the project's static (auto-generated) folder and delivered via PyPI.

Now, whenever Django is configured for production and Sekizai sees the tag addtoblock, then internally the file path is converted to the css file expected inside the auto-generated folder, but without compilation.

Do you think this is a feasible solution?

For details how libsass can be integrated with Sekizai and django-compressor, refer to this document: https://groups.google.com/forum/#!topic/django-cms/KO7K1iMIjmo

Cache cms placeholder with plugins that use sekizai

This is more a feature request or question than an issue.

In template:

{% cache 100 footer %}
  {% static_placeholder "footer" %}
{% endcache %}

If CMS plugin in placeholder footer uses sekizai then its sekizai content is not cached. Im aware of the Watcher that can help to catch changes in the context and set and restore sekizai data from cache, but it would be nice if it could be done just from template?

django.utils.importlib deprecation warnings

from django.utils.importlib import import_module is deprecated (removed in Django 1.9). If you don't mind dropping Python 2.6 support, we can replace it with from importlib import import_module.

Everything breaks if render_block is used in extended templates

We've got an existing setup and django-cms is only a small part of it, so we extend our usual templates with this one for cms pages:

{% extends "base_nomap.html" %}{% load cms_tags sekizai_tags %}

{% block head %}
{{ super }}
      {% render_block "css" %}
      {% render_block "js" %}
{% endblock head %}

{% block section %}sectionFlatpage{% endblock section %}
{% block title %}{% page_attribute page_title %}{% endblock title %}

{% block content %}
<h1>{% page_attribute page_title %}</h1>
{% placeholder "content" %}
{% endblock content %}

This breaks horribly:

TemplateSyntaxError at /p/a/
Invalid block tag: 'endblock'

It seems sekizai creates a custom parser for some reason, which means it can't be used in extended templates. I can't seem to find any workarounds for this bug.

Error: context must be a dict rather than SekizaiContext.

Good evening,
I got error:

TypeError at /en/login/
context must be a dict rather than SekizaiContext.
from sekizai.context import SekizaiContext

context = SekizaiContext(request, {'error': error, 'form': form})
return render_to_response('login.html', context)

`with_data` inside `addtoblock`

The following does not work:

{% addtoblock "css" %}
{% with_data "css-data" as stylesheets %}
{% for stylesheet in stylesheets %}
  <link href="{{ STATIC_URL }}{{ stylesheet }}" rel="stylesheet" type="text/css" />
{% endfor %}
{% endaddtoblock %}

It would be convenient to be able to use this so a compression postprocessor could be used on the "css-data" stylesheets.

Sekizai Tags asking for sekizai.context_processors.sekizai in template context processo when it already exists

While using Sekizai Tags, I'm getting this exception:

You must enable the 'sekizai.context_processors.sekizai' template context processor or use 'sekizai.context.SekizaiContext' to render your templates.

However, I followed the instructions provided at ReadTheDocs and set up TEMPLATE_CONTEXT_PROCESSORS as such with sekizai.context_processors.sekizai in TEMPLATE_CONTEXT_PROCESSORS:

TEMPLATE_CONTEXT_PROCESSORS = (
    "django.contrib.auth.context_processors.auth",
    "django.core.context_processors.auth",
    "django.core.context_processors.i18n",
    "django.core.context_processors.debug",
    "django.core.context_processors.media",
    "django.core.context_processors.request",
    "django.contrib.messages.context_processors.messages",
    "cms.context_processors.media",
    'sekizai.context_processors.sekizai',
    "multilingual.context_processors.multilingual",
)

Add prepend_data and prependtoblock

Sometimes it is useful to have more control where in the order you want a script or css file to be added. I would propose simple prepend_data and prependtoblock tags, which are very similar to existing tags, only they call context[varname][key].insert(0, value) and context[varname][name].insert(0, rendered_contents).

addtoblock with template block cache failing

Say I have the following code block (simplified for explanation):

{% render_block "head" %}

{% cache 600 "my-sekizai" %}
  {% addtoblock "head" %}
    <meta name="sekizai" content="is awesome">
  {% endaddtoblock %}
{% endcache %}

Now the first time, everything is fine; the <meta> is included. However the second things go wrong, now the {% addtoblock %} directive is ignored. Now I can understand why this happens, as sekizai does some processing that {% cache %} is not aware of, and therefor isn't cached. However, it is not what I consider expected behavior. I would have expected that the sekizai instructions would also have been cached.

Using Media classes with sekizai does not work es expected

Some widgets bring Media-classes, for example django autocomplete light (dal). dal suggests:

{% block footer %}
<script type="text/javascript" src="{% static 'admin/js/vendor/jquery/jquery.js' %}"></script>
{{ form.media }}
{% endblock %}

One could also use {{ form.media.js }}, but this is not working:

{% addtoblock "js" strip %}
    {{ form.media.js }}
{% endaddtoblock %}

Is this a problem of sekizai?

{% with_data %}...{% end_with_data %} shouldn't render new line

I find {% add_data %} and {% with_data %} to be a great way to collect style and JavaScript nonces for Content Security Policy.

Unfortunatelly, {% with_data %} template tag renders a new line (\n) and that breaks the validity of the meta tag with Content Security Policy. Can it be eliminated or replaced with a space?

Also it would be helpful if nested {% with_data "script_nonces" as script_nonces %}{% with_data "style_nonces" as style_nonces %}...{% end_with_data %}{% end_with_data %} were supported or if it allowed multiple variables in one template tag like {% with_data "script_nonces" as script_nonces and "style_nonces" as style_nonces %}...{% end_with_data %}.

sekizai + django-compressor

I've looked at the solution of #4 and https://gist.github.com/1311010. This helps and makes compressor work, but in a pretty incomplete way.

As the function doesn't pass any context to the CompressorNode as itself isn't passed any context, the RequestContext django-compressor needs for several features such as COMPRESS_DEBUG_TOGGLE isn't present and the functionality isn't working.

Would it be possible to pass the postprocessor the current context?

Adapt django-sekizai for Django 1.11

Django sekizai seems to also work on Django 1.11, but I haven't tested all possible cases.
Are there plans to release a new version of django-sekizai anytime soon?

Issue rendering addtoblock with SCSS in AWS S3

{% render_block 'css' postprocessor 'compressor.contrib.sekizai.compress' %}
    {% addtoblock 'css' %}
<style type="text/x-scss">
            @import 'app_static/scss/_mixin.scss';
            @import 'app_static/scss/_variable.scss';
            @import 'app_static/scss/_mobile.scss';
 </style>

{% endaddtoblock %}

The above code not rendering properly for the first load and when ever cached css file missing

render_to_string

How can I add css to my header when rendering something to a string that later gets displayed on a template that inherits from base.

Here it would make sense that only at then end when the base template is rendered it also grabs all addtoblock elements and pulls them into the header or something like that.

What do you think? Or do you have alternative ideas on how to handle it?

Using render_block in a if fail

This little code :

{% if user.is_staff %}<li><a href="{% url admin-index %}" {% render_block "nav-menu-admin" %}>{% trans "Administration" %}</a></li>{% endif %}

Return Invalid block tag: 'endif' template error

How can I fix it ?

Templates missing for test data

Hi!

Just a minor ting... but I think you've forgotten to put templates for tests up. I'm missing basic.html, inherit/varchain.html, eat.html and more... thought they just need to be pushed?

Anyways, it's just an excuse to say thanks for the great app and happy new years :)

Ben, django-wiki

Older version published as 0.8.1

It looks like the version published as 0.8.1 is in fact an older one and doesn't match the 0.8.1 tag on GitHub.

To replicate: use {% sekizai_tags %} in a Django 1.8 app.
This results in:
TemplateSyntaxError: 'sekizai_tags' is not a valid tag library: ImportError raised loading sekizai.templatetags.sekizai_tags: cannot import name VariableNode

The fixes for Django 1.8 compatibility (in 0.8.1) are not present in what pip installs as 0.8.1.

`addtoblock` doesn't work in extended template

Imagine that I have template base.html:

{% load sekizai_tags %}
<body>
    {% render_block "js" %}
</body>

Then I extend it in home.html:

{% extends 'base.html' %}
{% load sekizai_tags %}
{% addtoblock "js" %}<script>alert("Hello!");</script>{% endaddtoblock %}

This example doesn't work and doesn't throw an error.

Error when writing functional tests with Django using: StaticLiveServerTestCase

 "You must enable the 'sekizai.context_processors.sekizai' template "
TemplateSyntaxError: You must enable the 'sekizai.context_processors.sekizai' template context processor or use 'sekizai.context.SekizaiContext' to render your templates.

Meanwhile sekizai.context_processors.sekizai is in the template context processors and the site works when running using manage.py runserver.

However when running using manage.py test with a simple test like the following I get the above error:

def test_home_page_title(self):
        title = 'Learn Languages Online'
        self.browser.get(self.server_url)
        self.assertIn(title, self.browser.title, self.browser.title)

Located in a different base file inheriting from StaticLiveServerTestCase.

from selenium import web driver

self.server_url = self.live_server_url
self.browser = webdriver.PhantomJS()
self.browser.set_window_size(800,600)
self.browser.implicitly_wait(DEFAULT_WAIT)

Is there some special configuration that is required in order to get django-sekizai working with Django's default testing framework? Doing a google search I see others have been running into this same issue, however the solutions required django-cms which we are not using.

disable render_block in extended template

I have template that extends from base. Base has a render_block js in it. In the template that extends from base I want to disable that render_block. I can't see a way how to do it, not with the restrictions.

You can't put it in a block which you empty out in the extended template.

You can't wrap it with an if statement since nothing can wrap it.

This is what I've resorted to disable it.

base.html:

{# hack to get around sekizai #}
{% block pre_js_block %}{% endblock %}
{% render_block "js" %}
{% block post_js_block %}{% endblock %}

extends.html:

{% extends 'base.html' %}

{% block pre_js_block %}
  <!--
{% endblock %}

{% block post_js_block %}
  -->
{% endblock %}

As you can see I've resorted to putting a html start and end comment around it. So technically it's not disabled, but the output is ignored by the browser.

include templates for tests

Templates are not found if i run the testsuite of a project that has sekizei in it.
Rename the test_templates folder to templates and move all the templates there in a sekizei_test folder so we don't have collisions.

How to get Sekizai working in an InclusionTag

Hi Ojii,

I have an issue with Sekizai on which I've spend already a lot of time. I've been trying to create a templatetag based on a template containing Sekizai addtoblock. However, all my attemps end with the error:

You must enable the 'sekizai.context_processors.sekizai' template context processor or use 'sekizai.context.SekizaiContext' to render your templates.

Could you help me in the right direction?

I created the templatetag polls_extras.py:

from django import template
from django.template.loader import render_to_string
from classytags.arguments import Argument
from classytags.core import Options
from classytags.helpers import InclusionTag

class show_results(InclusionTag):
    template = 'result_tag.html'

    options = Options(
        Argument('poll')
    )

    def get_context(self, context, poll):
        choices = poll.choice_set.all()
        return {'choices': choices}

    def render_tag(self, context, poll):
        print context
        return super(render_tag, self, context, poll)

    def render_tag(self, context, poll):
        data = self.get_context(context, poll)
        output = render_to_string(self.template, data)
        return output

register.tag(show_results)

and this is my result_tag.html:

{% load sekizai_tags %}
{% addtoblock "test" %}<br/>Some more Sekizai{% endaddtoblock %}
<ul>
{% for choice in choices %}
    <li> {{ choice }} </li>
{% endfor %}
</ul>

this is part of my base template:

{% load poll_extras sekizai_tags %}
<h1>{% render_block "test" %}</h1>
x
x
x
{% show_results poll %}

As you see I have created the render_tag function but I have no idea how to alter that to make it work. I guess there need to be two passes, one to put poll in the InclusionTag and then the whole base template needs to be rendered with the Sekizai directive. I've looked at django-cms where the toolbar is rendered as an Inclusion Tag without a problem. Could you indicate how this issue can be solved?

Thanks,

Guido

Compatability with Django 1.10

Hi!

I have a Django App that users Django 1.10. I tried to use django-sekizai (in version 0.9.0 but it did not work. This happens when trying {% load sekizai_tags %}:

TemplateSyntaxError at /
'sekizai_tags' is not a registered tag library. Must be one of:
cache
future
i18n
l10n
static
staticfiles
tz

The relevant section in my configuration looks like this:

# TEMPLATE CONFIGURATION
TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [
            str(PROJECT_ROOT.path('templates')),
        ],
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
                'sekizai.context_processors.sekizai',
            ],
        },
    },
]

Somehow the context processor is not registered?

sekizai.context_processors.sekizai seems not working

I've added sekizai context processor:

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [],
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
                'sekizai.context_processors.sekizai',
                'my_cms.context_processors.site_configuration'
            ],
        },
    },
]

I have this custom tag:

@register.simple_tag(takes_context=True)
def render_page_contents(context):
    page = context['page']

    html = ''
    for pc in page.page_contents.all():
        if pc.template:
            html += render_to_string(pc.template, RequestContext({'page_content': pc}))
    return mark_safe(html)

A template rendered above:

{% load sekizai_tags %}

{% addtoblock "jsa" %}
<script type="text/javascript">alert('a');</script>
{% endaddtoblock %}

<div id="{{ page_content.css_id }}" class="{{ page_content.css_classes }}" style="border: 1px dashed forestgreen">
    <h2>{{ page_content.title }}</h2>
    <h3>{{ page_content.subtitle }}</h3>
</div>

The base.html contains:

{% load static i18n sekizai_tags %}
{% render_block "jsa" %}

I obtain this error:

You must enable the 'sekizai.context_processors.sekizai' template context processor or use 'sekizai.context.SekizaiContext' to render your templates.

The context processor is added and I'm using RequestContext, like docs says:

For Django versions after 1.10, add sekizai.context_processors.sekizai to your TEMPLATES['OPTIONS']['context_processors'] setting and use django.template.RequestContext when rendering your templates.

I'm using Django 1.10.8 and django-sekizai 0.10.0

sekizai places extending template's block above extended's template block.

I am trying to implement django-sekizai tags. This is my base.html:

{% addtoblock "js" %}
    <script src="{{ STATIC_URL }}js/jquery.min.js"></script>
    <script src="{{ STATIC_URL }}js/jquery-ui-1.10.3.custom.min.js"></script>
{% endaddtoblock %}

{% render_block "js" %}

Then there is index.html which extends base.html like this:

{% extends "base.html" %}
{% load sekizai_tags %}

{% block main %}
<div>
</div><!-- End page-content -->
    {% addtoblock "js" %}
        <script>
            $(".tab-questions").removeClass("current");
        </script>
    {% endaddtoblock %}
{% endblock %}

However, I get this error: $ is not defined

I checked the page source and found this:

<script>
    $(".tab-questions").removeClass("current");
</script>

script src="/static/js/jquery.min.js"></script>
script src="/static/js/jquery-ui-1.10.3.custom.min.js"></script>
script src="/static/js/jquery.easing.1.3.min.js"></script>

Django sekizai adds the extending template's javascript block above the extended template's javascript imports.

What am I doing wrong?

How to render CMS page without render_block output

Suppose you are pulling a page with via Xhr, and since render_block cannot be within an {% if request.is_ajax %}, and Django CMS cannot render the page using another template if ajax, and the render_block css and render_block js screw up the output and make it unnecessarily large:

How would you return the page without those parts if is_ajax?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.