We need to decide on conventions for ella plugins and which modules will be kept in core after the process. Seems like the only module with direct ties to core should be photos (where I would highly appreciate to use some interface to allow for sorl-thumbnail as I stated before).

Moreover, it is needed to decide on who will do the thing. In Fragaria, we would like to handle polls, since we use them quite often. Major refactoring will be most likely included even though we originally proposed to postpone it.

@whit said, he would like to keep following naming convention for all ella plugins: ella_[PLUGIN_NAME].

So there would be ella_articles, ella_polls etc.

This leads to some minor troubles with DB table names and references in the code itself. There will have to be migrations to rename all the tables.

Please, share your opinions here. We would like to start working on this next week.

There should be simple interface for writers/editors. Not newman, but something forged specifically for them. Lightweight, not build on Django admin, customized only for them.

Newman is not sufficent, because it's just way too puffy. Most of writers use only articles + photos/galleries.

We need to discuss the basis of implementation though. In my point of view, it has to be javascript-heavy frontend as user-friendly as possible.

When models in cleanup branch to be a bit stable, create external script to migrate data.

• aricle contents ( and markup source texts update) -> article
• placement -> publishable (with "published" bool)

Looks like we have fixed all the issues that were blocking final django-1.3 compatibility release. We have put the changes into proposals/2.1.0 branch (last changes in commit 0b5f605a46). Please, have a look at this version and report any new errors.

Just to let you know, this has been put into proposals so we are not accepting any new features, only bug fixes related to Django 1.3 compatibility.

Hey! I am pushing this as a pull request, because it is introducing new functionality.

If there is some EXIF rotation information Formatter rotates image prior formatting.

What do you think about it, is it safe to merge?

When generating photos in format, there are times when integrity error is raised.

This is probably related to comment:

use get or create because there is a possible race condition here we don't want to JUST use get_or_create to go through cache 99.9% of the time

on line 299 in ella/photos/models.py. I assume, it's not a big deal but we should more clever and do not report this as exception then.

Very often we struggle with "nice URLs" that categories are blocking. This is mostly the case for static pages like contact page, usage conditions and so on.

In some other CMS product, we have seen nice solution which allowed to select different behaviours for different categories. Most interesting are: article listing and showing detail of specified article. A feature like this would solve our URL issue.

So far, there are several ways how to handle such pages in Ella, but none of them is pleasant.

1. Someone will probably argue that such a function is already available using static articles (or static placements before cleanup started). This is true but static articles' URL just sucks. We don't like having /static/ prefix in URL just because the CMS doesn't know how to do it properly.

2. Using category description to contain HTML to render the page. This smells on the first sight.

3. Put all the HTML in category template. This isn't nice too because you cannot alter the HTML from administration, nor you can change the behaviour of this given category if requested without help of developer.

As you can see, nice solution is missing. This kind of behavior doesn't necessarily need to be in Ella's core, but I would really appreciate if we can find out some nice way how to do this (an app which uses category metadata JSONField and overrides urls file and category detail?).

This is no longer needed, it's not welcome because of SEO and makes the url too long, I believe we should remove it and provide a migration for backwards compatibilty that would create Redirect objects for every instance of this.

There is no problem with adding new quiz(test) via newman. But opening url of the quiz raises this exception. The exception is IndexError: list index out of range.

If you add or edit some object e.g. article or photo via newman. A response for this action is shown on your website. The response is gone after refresh.

See: http://uloz.to/xcycL8b/response-out-newman-png

Almost every application I have seen on ella has some need for added flexibility. I propose we add an optional JSONField to Publishable that individual plug-ins and projects can use to store their specific stuff. Some examples:

• store comment count with publishable
• tag lists
• importance
• source information (commercial, licence)
• template used to render
• ....

I also believe some conventions (a two line note in help_text fo the fields sounds enough) should be in place to provide namespaces (for example store your stuff under "app_name", for example:

{ 'comments': {'count': 12, 'latest': '20120128'}, 'tagging': {'public_tags': ['summer'], 'editorial_tags': ['white bikiny']} }

Issue Type

[x] Bug (Typo)

Steps to Replicate and Expected Behaviour

• Examine doc/reference/models.rst, ella/photos/models.py and observe unformated, however expect to see unformatted.
• Examine doc/common_gotchas.rst, doc/quickstart.rst and observe sufficent, however expect to see sufficient.
• Examine ella/photos/models.py and observe formated, however expect to see formatted.
• Examine ella/photos/formatter.py and observe explicitely, however expect to see explicitly.
• Examine doc/common_gotchas.rst and observe suprisingly, however expect to see surprisingly.
• Examine doc/quickstart.rst and observe succesfull, however expect to see successful.
• Examine doc/quickstart.rst and observe styleseets, however expect to see stylesheets.
• Examine doc/reference/models.rst and observe peformed, however expect to see performed.
• Examine ella/photos/formatter.py and observe horizontaly, however expect to see horizontally.
• Examine doc/features.rst and observe diferrent, however expect to see different.

Notes

Semi-automated issue generated by https://github.com/timgates42/meticulous/blob/master/docs/NOTE.md

To avoid wasting CI processing resources a branch with the fix has been prepared but a pull request has not yet been created. A pull request fixing the issue can be prepared from the link below, feel free to create it or request @timgates42 create the PR. Alternatively if the fix is undesired please close the issue with a small comment about the reasoning.

https://github.com/timgates42/ella/pull/new/bugfix_typos

Thanks.

Hello! I believe this is my first patch for a Django-based project, hopefully I'm doing everything right. I installed the code and ran the tests, but found some failures due to my environment.

Due to CVE-2012-1150, CPython now allows using a random seed for hashes,
so set/dict order is no longer predictable.

Update tests to pass even if the hash seed is randomized.
Add a testing-only argument to ella.core.templatetags.pagination._do_paginator
to sort query params before encoding them.

In test_templatetags.test_params_are_parsed, I didn't find a good way for to sort a dictionary given to a for in a Django template.

There are three commits:

First is only PEP8 fixes.

Second is for category related finder. Example in current version of ella: I have publishble x and x has set category y and is also listed in this category and I want 4 related objects by category and finder gives me only 3 objects although there is many objects (This situation happens only if position of x in listing query set is less than count specification).

Last is for Publishable clean method where is check of uniqueness by category, slug, publish_from for non static objects. There is replaced self.class with Publishable, becouse self.class validate uniqueness for specific content type (for example only in articles query set) and not in Publishable qs and it breaks unique url per publishable.

If I try this test add to ella tests:

def test_params_parsed_with_national_characters(self):
        template_loader.templates['box/box.html'] = '{% for k,v in box.params.items %}{{k}}:{{v}}|{% endfor %}'
        t = template.Template('''{% box name for sites.site with pk 1 %}
                title: účes
                some_other_param: xxx
            {% endbox %}''')
        tools.assert_equals(u'some_other_param:xxx|title:účes|', t.render(template.Context()))

the result is:

UnicodeDecodeError

An error is raised when saving publishable object with date which is out of range for mktime. This is however what Ella presets for publishable by default.

See the stack trace:

OverflowError: mktime argument out of range

Traceback (most recent call last):

  File "django/core/handlers/base.py", line 168, in get_response
    receivers = signals.got_request_exception.send(sender=self.__class__, request=request)

  File "ella_newman/options.py", line 203, in wrapper
    return self.admin_site.admin_view(view)(*args, **kwargs)

  File "django/utils/decorators.py", line 99, in _wrapped_view
    raise

  File "django/views/decorators/cache.py", line 79, in _wrapped_view_func
    response = view_func(request, *args, **kwargs)

  File "django/contrib/admin/sites.py", line 197, in inner
    return view(request, *args, **kwargs)

  File "django/db/transaction.py", line 220, in inner
    raise

  File "ella_newman/options.py", line 798, in change_json_view
    context = self.change_view_prepare_context(request, object_id)

  File "ella_newman/options.py", line 762, in change_view_prepare_context
    out = self.change_view_preprocess(request, object_id)

  File "ella_newman/xoptions.py", line 144, in change_view_preprocess
    formsets, form = self.get_change_view_formsets(request, obj)

  File "ella_newman/xoptions.py", line 91, in get_change_view_formsets
    self.save_formset(request, form, formset, change=True)

  File "django/contrib/admin/options.py", line 677, in save_formset
    formset.save()

  File "django/forms/models.py", line 482, in save
    return self.save_existing_objects(commit) + self.save_new_objects(commit)

  File "django/forms/models.py", line 613, in save_new_objects
    self.new_objects.append(self.save_new(form, commit=commit))

  File "django/forms/models.py", line 717, in save_new
    obj.save()

  File "django/db/models/base.py", line 460, in save
    self.save_base(using=using, force_insert=force_insert, force_update=force_update)

  File "django/db/models/base.py", line 570, in save_base
    created=(not record_exists), raw=raw, using=using)

  File "django/dispatch/dispatcher.py", line 172, in send
    response = receiver(signal=self, sender=sender, **named)

  File "ella/core/cache/redis.py", line 107, in listing_post_save
    commit=True

  File "ella/core/cache/redis.py", line 307, in add_publishable
    score = repr(to_timestamp(publish_from or now()))

  File "ella/utils/timezone.py", line 38, in to_timestamp
    return time.mktime(dtime.timetuple()) + float(dtime.microsecond)/1000000

dtime is set to: 'datetime.datetime(3000, 1, 1, 0, 0)'

simple enough - enable project to register the override view that will be called before listings are retrieved (thus enabling people to not use listings).