I am having trouble uploading transparent PNGs since after the upload, they are internally converted to the JPGs. This is really annoying since it is not possible to upload transparent images whatsoever.

Is that because of the Flash image editor?

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)

it's fast becoming a de-facto standard for python and django apps, it supports sphinx, let's go with it

galleries/gallery/$n/ =>
Gallery items (prvky galerií) =>
magnifier =>
mass upload (hromadné nahrávání) =>
fill out & select photos =>
upload =>
I'm not redirected to galleries/gallery/$n/ but to /photos/photo/

I am proposing exchange of tagging application for ella 2.0. There are several important reasons to do this.

django-tagging is not maintained anymore

Last commits were introduced in the begging 2010 which most likely means it's not maintained anymore.

One one hand, it's partially true for django-taggit as well. The last commit goes to spring of 2011. However, there is a big amount of living forks which looks like it will not die out any soon.

The bad news is that it looks like it's still not working properly in django 1.3 so some small praticipation might be needed.

Current implementation makes it hard or almost impossible to sort tag list by date

Sorting tagged items by date is quite a must-have feature and without it, it just makes tags a little unusable overally. The main reason for this is following piece of code:

def get_tagged_publishables(tag):
    now = datetime.now()
    queryset = Publishable.objects.filter(
        Q(placement__publish_to__isnull=True) | Q(placement__publish_to__gt=now),
        placement__publish_from__lt=now).distinct()
    return TaggedItem.objects.get_by_model(queryset, tag)

This effectively prevents us from sorting by anything in DB. Only solution would be to sort in Python (not a good one though).

django-tagging allows for bad characters in URL

One can enter something with "/" character in it which then breaks in tag listing. Ella might be solving this, but that's not a good way to go.

There is known way to migrate from tagging to taggit that could be automated in migrations

Simply adhere to following blog post, only automate it a little: http://birdhouse.org/blog/2011/04/17/migrate-django-tagging-taggit/.

When modyfiyng article, I'm able to add only three tags.

I'd like to add more, i.e. have more field for tags available.

When I change category filter on newman's home page (I have two sites, un-click one and select another), any click on menu (I tested articles, photos and contests) takes me back to the Home and I must click one more time to go where I want.

Sane testing is no longer needed and breaks things

Tags can have dashes in them while it's not possible to reverse such a URL, e.g:

NoReverseMatch: Reverse for 'tag_list' with arguments '()' and keyword arguments '{'tag': u'g-20'}' not found.

The reason is following URL declaration:

urlpatterns = patterns('',
    url(r'^(?P<tag>[\w\s]+)/', TaggedPublishablesView.as_view(), name="tag_list"),
)

In the branche "future/django-1.3" and with PostgreSQL backend appears Database error. Especially in the case of creating an article in the newman interface and with PostgreSQL (version 9.0). This bug doesn't appear with sqlite3 backend.

Traceback (most recent call last):
File "/home/budeb/.virtualenvs/sensa2/lib/python2.6/site-packages/django/contrib/staticfiles/handlers.py", line 68, in call
return self.application(environ, start_response)
File "/home/budeb/.virtualenvs/sensa2/lib/python2.6/site-packages/django/core/handlers/wsgi.py", line 272, in call
response = self.get_response(request)
File "/home/budeb/.virtualenvs/sensa2/lib/python2.6/site-packages/django/core/handlers/base.py", line 169, in get_response
response = self.handle_uncaught_exception(request, resolver, sys.exc_info())
File "/home/budeb/.virtualenvs/sensa2/lib/python2.6/site-packages/django/core/handlers/base.py", line 203, in handle_uncaught_exception
return debug.technical_500_response(request, _exc_info)
File "/home/budeb/.virtualenvs/sensa2/lib/python2.6/site-packages/django/core/handlers/base.py", line 111, in get_response
response = callback(request, *callback_args, *_callback_kwargs)
File "/home/budeb/work/ella/ella/newman/options.py", line 187, in wrapper
return self.admin_site.admin_view(view)(_args, *_kwargs)
File "/home/budeb/.virtualenvs/sensa2/lib/python2.6/site-packages/django/utils/decorators.py", line 93, in _wrapped_view
response = view_func(request, _args, *_kwargs)
File "/home/budeb/.virtualenvs/sensa2/lib/python2.6/site-packages/django/views/decorators/cache.py", line 79, in _wrapped_view_func
response = view_func(request, _args, *_kwargs)
File "/home/budeb/.virtualenvs/sensa2/lib/python2.6/site-packages/django/contrib/admin/sites.py", line 197, in inner
return view(request, _args, *_kwargs)
File "/home/budeb/.virtualenvs/sensa2/lib/python2.6/site-packages/django/db/transaction.py", line 217, in inner
res = func(_args, *_kwargs)
File "/home/budeb/work/ella/ella/newman/options.py", line 852, in add_json_view
context = self.get_add_view_context(request, form_url)
File "/home/budeb/work/ella/ella/newman/options.py", line 819, in get_add_view_context
context = super(NewmanModelAdmin, self).get_add_view_context(request, form_url)
File "/home/budeb/work/ella/ella/newman/xoptions.py", line 361, in get_add_view_context
self.save_formset(request, form, formset, change=False)
File "/home/budeb/.virtualenvs/sensa2/lib/python2.6/site-packages/django/contrib/admin/options.py", line 677, in save_formset
formset.save()
File "/home/budeb/.virtualenvs/sensa2/lib/python2.6/site-packages/django/forms/models.py", line 482, in save
return self.save_existing_objects(commit) + self.save_new_objects(commit)
File "/home/budeb/.virtualenvs/sensa2/lib/python2.6/site-packages/django/forms/models.py", line 613, in save_new_objects
self.new_objects.append(self.save_new(form, commit=commit))
File "/home/budeb/.virtualenvs/sensa2/lib/python2.6/site-packages/django/forms/models.py", line 717, in save_new
obj.save()
File "/home/budeb/.virtualenvs/sensa2/lib/python2.6/site-packages/django/db/models/base.py", line 460, in save
self.save_base(using=using, force_insert=force_insert, force_update=force_update)
File "/home/budeb/.virtualenvs/sensa2/lib/python2.6/site-packages/django/db/models/base.py", line 553, in save_base
result = manager._insert(values, return_id=update_pk, using=using)
File "/home/budeb/.virtualenvs/sensa2/lib/python2.6/site-packages/django/db/models/manager.py", line 195, in _insert
return insert_query(self.model, values, **kwargs)
File "/home/budeb/.virtualenvs/sensa2/lib/python2.6/site-packages/django/db/models/query.py", line 1436, in insert_query
return query.get_compiler(using=using).execute_sql(return_id)
File "/home/budeb/.virtualenvs/sensa2/lib/python2.6/site-packages/django/db/models/sql/compiler.py", line 791, in execute_sql
cursor = super(SQLInsertCompiler, self).execute_sql(None)
File "/home/budeb/.virtualenvs/sensa2/lib/python2.6/site-packages/django/db/models/sql/compiler.py", line 735, in execute_sql
cursor.execute(sql, params)
File "/home/budeb/.virtualenvs/sensa2/lib/python2.6/site-packages/django/db/backends/util.py", line 34, in execute
return self.cursor.execute(sql, params)
File "/home/budeb/.virtualenvs/sensa2/lib/python2.6/site-packages/django/db/backends/postgresql_psycopg2/base.py", line 44, in execute
return self.cursor.execute(query, args)
DatabaseError: can't adapt type 'UnicodeWrapper'

Gallery should be automatically created when adding photos by mass upload.

Curretly it says First X objects from category Y. This doesn't sound very cool. Better would be bare name of category.

It would be nice to create some dependency wrapper between plugins. Nice example can be imports app. This one needs articles, but one can imagine articles can very nicely live without imports so it doesn't make sense to merge the apps.

Instead, we should create some dependency-checking mechanism for each module. Putting the dependency into setup.py is not sufficent, because the fact that it's installed doesn't necessarily mean that it's included in INSTALLED_APPS too.

The wrapper can be fairly simple, just simple checking and in case that dependencies are not met, warning should be raised.

What do you think?

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.

redirect_to expets url argument to be a str whereas custom resolver passes context in there, i guess

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?).

Or at least clean it up - cleanup tests, convert to unit tests, remove templates form app...

again this is something that can live as a tiny plug-in app for ella.

Couldn't syncdb until I ran the following:

pip install anyjson

The interviews app has some CH - specific features and is not suited to be in a generic purpose CMS.

There is an issue. I've got web with 4 main categories (A, B, C, D). Every main category has another subcategories. Because category D is special (looks completely different), I need separate template. Separate template is in page/category/D/category.html. But I have also subcategories (D1, D2, D3,..) which I want to look exactly as parent - category D. So I need to create separate templates for each subcategory. Subcategory template only content something like this

{% extends "page/category/D/category.html" %}

It's really mess in file system and you need to create separate subcategory template every time you add new subcategory. So the editor is depend on developer and deploying process. It's not good.

Ella should search even in tree_path of category. Something very similar is working in positions. If it works, there would be only one separate template for category D and subcategories D1, D2, D3,.. would use template of parent category D.

Is someone using this? I'm asking if it's needed to add migrations for db table names.

/galleries/gallery/$n/ =>
Gallery Items =>
magnifier =>
Mass upload =>
select and upload photos =>
I'm returned to gallery edit page but the new photos are not automatically added to the gallery

Should be rendered as select or with magnifier tool to select from list instead.

This seems obsolete since even newman doesn't show more contents to fill up. Let's save some performance and move the articles_articlecontents to articles_article table.

To allow for multiple_contents, simple solution like in ella_toolkit can be used instead.

I know you can un-publish something by changing the publish_from, but that can be fragile. I propose we add a pubslihed boolean to Publishable and use that as an additional filter in listings.

The idea is to un-publish something easily as well as enable elementary workflow - anybody can create a Publishable, schedule it's publication (set publish_from), but only once somebody (editor) sets the published boolean it will be visible.

For sites that don't need or want this workflow it's just a column in the database and you can set your admin to always flip that to "yes" position.

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']}
}

When saving competition/quiz, created answers along with responses are not saved (not even one of them).

Prefered solution is major simplification/refactoring of JS widgets that are used since current ones are highly confusing to the users.

/photos/photo/add/ doesn't work. Apparently a flash issue.

When deleting object, the page hangs saying something about too much recursion. The object is deleted on background though.

Comment IDs in newman are rendered as textarea fields.

They should be no special than any other format - just have the admin create them if it needs it.

it would be nice if we could get the polls app into a separate repo and maybe split the Poll/Contest/Quiz models into several different apps. Maybe cleanup and denormalize the models in the process.

When creating galleries photos are not saved properly. Only the first image is saved, the rest is forgotten after form save.

When editing, it seems that it works correctly.

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.

Let's go through the tutorial and shorten it a bit - just enough so that any djangista can get ella up and running in 10 minutes with basic understanding of basic concepts (Publishable, Listing and Box).

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 0b5f605). 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.

Take one of the apps we want to rip out of ella, clean it up and use it as an example on how a re-usable ella plug in should look like. The basic idea is that such an app shoudl have:

models (inheriting from Publishable where applicable)
custom box class
templatetags
custom_urls

Better default behavior will be SET_NULL when Publishable.photo is nullable.

There is some csrf related issue. When csrf check is turned off for upload function, it upload files as expected.

Article -> add -> tagged items -> magnifier -> add tag -> fill a tag name and hit enter.

Tag is saved, but I'm now stuck on editation page.

Normalization is for sissies, especially when not at all needed and when it creates additional complications.

Also consider modifying galleries to be Photo-only.

Create an ella/newman repo and move newman there.

We can keep all the newman_admin.py files in ella for the time being although I would love for them to move into newman as well in the future.

This would simplify deployment and development greatly - it would reduce the number of requirements for ella, stabilize it's development process (no reason why newman's dev cycle should be bound to that of ella).

If done right (the app within newman would still be called newman), we can avoid having to create migrations as the table names will remain the same.

I would be more than happy if we still had the opton to use newman for ella, we could point to it in the docs etc. We can alway move the newman-specific part of the docs with newman and I would be happy to help with integrating those.

It would be nice to have ella's pagination (/?p=2) the same way as django's pagination (/?page=2).

Now ella prioritize objects in category listing by date & time of placement. Problem is that placement also control when the object is visible in category.

Common case is that editor wants to everyday publish new objects but he also want to keep old object on top of listing, because the object really work and users click on it. Here is the example:

0 day order of articles: A, B, C, D
1 day order of articles: A, E, F, G, B, C, D

There is no easy way for editors how to do that. In Newman there should be one page, where editors easily see (and of course simply change) order of objects for specific time and specific category.

If I enter some form (like tagging -> add), I'd expect first field to have focus (so I can type tag name, hit 'enter' and continue).

On today's meeting with @martinbilek and @whit we agreed that it will be nice to get rid of photo format altogether and switch to Django settings-based formats. There nothing really useful about the way photo formats are defined as it's usually done only once during the site lifecycle - at the time the site is built.

By using settings-based formats, we will save some DB queries and it will be much simpler to manage the list of formats.

We should use something like sorl instead of custom solution.

I propose we use /category/sub/articles/123-article-slug/ as a URL for an Article with static=True

if nobody has serious complains I will go ahead and implement it tomorrow.

When click to "Articles -> New article" I see modal window "Loading media..." and nothing happening. Main window where I can enter title, metadata, etc. is locked by this modal window.

Can I give you some debug logs to figure out the problem?

Thanks.