date:20160128

Re: [mezzanine-users] South Migration Issue

2016-01-28 Thread Eduardo Rivas

I don't think that's a valid Django migration. You can't simply edit 
South migrations to make them Django compatible. Please follow the steps 
outlined in the link I provided in my previous message.


--
You received this message because you are subscribed to the Google Groups "Mezzanine 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [mezzanine-users] South Migration Issue

2016-01-28 Thread George M

Oops, sorry.
Its my first mezzanine app and django migration.
I'll keep at it.
Thanks.


On Thursday, January 28, 2016 at 7:15:50 PM UTC+3, Eduardo Rivas wrote:
>
> I don't think that's a valid Django migration. You can't simply edit 
> South migrations to make them Django compatible. Please follow the steps 
> outlined in the link I provided in my previous message. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [mezzanine-users] South Migration Issue

2016-01-28 Thread George M

Thanks Eduardo,
I've customised the migration that had south as below:-

# -*- coding: utf-8 -*-
#from south.utils import datetime_utils as datetime
#from south.db import db
#from south.v2 import SchemaMigration
from django.db import models
from django.db import migrations

class Migration(migrations.Migration):

def forwards(apps, schema_editor):
# Adding field 'Page.in_opd'
migrations.AddField(
model_name=u'pages_page',
name=u'in_opd',
field='django.db.models.fields.BooleanField',
preserve_default=False
)

def backwards(apps, schema_editor):
# Deleting field 'Page.in_opd'
migrations.RemoveField(
model_name=u'pages_page',
name=u'in_opd'
)
models = {
u'pages.link': {
'Meta': {'ordering': "(u'_order',)", 'object_name': 'Link', 
'_ormbases': [u'pages.Page']},
u'page_ptr': ('django.db.models.fields.related.OneToOneField', 
[], {'to': u"apps.get_model('pages.Page')", 'unique': 'True', 
'primary_key': 'True'})
},
...

Is there anything am not doing right coz its not showing up for migration 
with python manage.py migrate onepage..

On Thursday, January 28, 2016 at 6:08:35 PM UTC+3, Eduardo Rivas wrote:
>
> Django implemented built-in migrations with the release of 1.7, and South 
> became obsolete. You will need to create standard migrations for the 
> application to be compatible with Django 1.7+. The Django docs explain this 
> with detail. 
>
>
> https://docs.djangoproject.com/en/1.8/topics/migrations/#upgrading-from-south
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mezzanine-users] Re: 404 page with USE_I18N = True

2016-01-28 Thread dborisov86

I've replaced 
urlpatterns = i18n_patterns("",
# Change the admin prefix here to use an alternate URL for the
# admin interface, which would be marginally more secure.
("^admin/", include(admin.site.urls)),
)
with
urlpatterns = patterns("",
# Change the admin prefix here to use an alternate URL for the
# admin interface, which would be marginally more secure.
("^admin/", include(admin.site.urls)),
)
in urls.py and it solved the problem.

Is it correct solution? Can I have any problems with this solution in the 
future?
I'm sorry, may be it is easy question, but I'm not Django pro. Please help 
to understand)
Thnx.

понедельник, 25 января 2016 г., 21:56:49 UTC+3 пользователь 
dbori...@gmail.com написал:
>
> Hi guys,
>
> I have a site with USE_I18N = True and only one language - russian.
> There is no language code in any url created by CMS and it is OK.
> But when I try to get nonexistent page it redirects me to 404 page with 
> language code. Why?
> Here is a log:
> [Mon Jan 25 18:38:11 2016] GET /sdasdasasdasda => generated 0 bytes in 66 
> msecs (HTTP/1.1 301) 5 headers in 202 bytes (1 switches on core 0)
> [Mon Jan 25 18:38:11 2016] GET /sdasdasasdasda/ => generated 0 bytes in 
> 205 msecs (HTTP/1.1 302) 3 headers in 125 bytes (1 switches on core 0)
> [Mon Jan 25 18:38:11 2016] GET /ru/sdasdasasdasda/ => generated 7028 bytes 
> in 137 msecs (HTTP/1.1 404) 4 headers in 131 bytes (1 switches on core 0)
>
> Is there any way to avoid this behavior? I want to render 404 page without 
> /ru component
>
> Thnx.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mezzanine-users] Re: drum template tag error

2016-01-28 Thread Minwoo Park

I met same error and solved by adding below line
"mezzanine.pages",
on INSTALLED_APPS (settings.py)

2015년 8월 30일 일요일 오전 3시 3분 45초 UTC+9, Micah Yoder 님의 말:
>
> Hi,
>
> So Drum works when I first started it (well, after 
> https://github.com/stephenmcd/drum/pull/22 was merged, thanks). But, 
> after simply doing a collecttemplates, the home page errors with
>
> Error during template rendering 
>
> In template /home/micah/testsites/mydrum/templates/base.html, error at 
> line *3*
> 'pages_tags' is not a valid tag library: Template library pages_tags not 
> found, tried 
> django.templatetags.pages_tags,drum.links.templatetags.pages_tags,mezzanine.core.templatetags.pages_tags,mezzanine.generic.templatetags.pages_tags,mezzanine.accounts.templatetags.pages_tags,filebrowser_safe.templatetags.pages_tags,django.contrib.admin.templatetags.pages_tags,django.contrib.staticfiles.templatetags.pages_tags,django_comments.templatetags.pages_tags
>  
>
>
>
> Not sure if this is a bug or if I'm doing something wrong.  Thanks!
>
> Mezzanine itself and Cartridge do not seem to have this problem.
>
> I'm using Python 3.4
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [mezzanine-users] Problem deploying Mezzanine on DigitalOcean

2016-01-28 Thread George M

I've upgraded Mezzanine. 
New errors. Trying to fix them first.
Thanks.

On Thursday, January 28, 2016 at 12:01:36 PM UTC+3, George M wrote:
>
> Hi Eduardo,
> Methinks you're right. 
> The problem seems to be that pages_page has an unapplied migration which 
> also isnt working. I've been using mysql locally. 
> I've switched to postgresql and this is my new error.
> Creating tables...
> Creating table pages_page
> Creating table pages_richtextpage
> Creating table pages_link
> Running deferred SQL...
> Traceback (most recent call last):
>   File "manage.py", line 14, in 
> execute_from_command_line(sys.argv)
>   File 
> "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", 
> line 338, in execute_from_command_line
> utility.execute()
>   File 
> "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", 
> line 330, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File 
> "/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", 
> line 390, in run_from_argv
> self.execute(*args, **cmd_options)
>   File 
> "/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", 
> line 441, in execute
> output = self.handle(*args, **options)
>   File 
> "/usr/local/lib/python2.7/dist-packages/mezzanine/core/management/commands/createdb.py",
>  
> line 60, in handle
> interactive=self.interactive)
>   File 
> "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", 
> line 120, in call_command
> return command.execute(*args, **defaults)
>   File 
> "/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", 
> line 441, in execute
> output = self.handle(*args, **options)
>   File 
> "/usr/local/lib/python2.7/dist-packages/django/core/management/commands/migrate.py",
>  
> line 179, in handle
> created_models = self.sync_apps(connection, 
> executor.loader.unmigrated_apps)
>   File 
> "/usr/local/lib/python2.7/dist-packages/django/core/management/commands/migrate.py",
>  
> line 317, in sync_apps
> cursor.execute(statement)
>   File 
> "/usr/local/lib/python2.7/dist-packages/django/db/backends/utils.py", line 
> 79, in execute
> return super(CursorDebugWrapper, self).execute(sql, params)
>   File 
> "/usr/local/lib/python2.7/dist-packages/django/db/backends/utils.py", line 
> 64, in execute
> return self.cursor.execute(sql, params)
>   File "/usr/local/lib/python2.7/dist-packages/django/db/utils.py", line 
> 97, in __exit__
> six.reraise(dj_exc_type, dj_exc_value, traceback)
>   File 
> "/usr/local/lib/python2.7/dist-packages/django/db/backends/utils.py", line 
> 62, in execute
> return self.cursor.execute(sql)
> django.db.utils.ProgrammingError: relation "django_site" does not exist
>
> Is it a problem with my mezzanine installation? From here 
> https://github.com/django/django-contrib-comments/issues/30
>
> On Wednesday, January 27, 2016 at 7:12:21 PM UTC+3, Eduardo Rivas wrote:
>>
>> Never mind, I think the problem is that you're not using migrations with 
>> your onepage app. I believe that any app that depends on another app 
>> that uses migrations (like mezzanine.pages) must also use migrations 
>> itself. 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [mezzanine-users] Problem deploying Mezzanine on DigitalOcean

2016-01-28 Thread George M

Hi Eduardo,
Methinks you're right. 
The problem seems to be that pages_page has an unapplied migration which 
also isnt working. I've been using mysql locally. 
I've switched to postgresql and this is my new error.
Creating tables...
Creating table pages_page
Creating table pages_richtextpage
Creating table pages_link
Running deferred SQL...
Traceback (most recent call last):
  File "manage.py", line 14, in 
execute_from_command_line(sys.argv)
  File 
"/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", 
line 338, in execute_from_command_line
utility.execute()
  File 
"/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", 
line 330, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
  File 
"/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", 
line 390, in run_from_argv
self.execute(*args, **cmd_options)
  File 
"/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", 
line 441, in execute
output = self.handle(*args, **options)
  File 
"/usr/local/lib/python2.7/dist-packages/mezzanine/core/management/commands/createdb.py",

line 60, in handle
interactive=self.interactive)
  File 
"/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", 
line 120, in call_command
return command.execute(*args, **defaults)
  File 
"/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", 
line 441, in execute
output = self.handle(*args, **options)
  File 
"/usr/local/lib/python2.7/dist-packages/django/core/management/commands/migrate.py",

line 179, in handle
created_models = self.sync_apps(connection, 
executor.loader.unmigrated_apps)
  File 
"/usr/local/lib/python2.7/dist-packages/django/core/management/commands/migrate.py",

line 317, in sync_apps
cursor.execute(statement)
  File 
"/usr/local/lib/python2.7/dist-packages/django/db/backends/utils.py", line 
79, in execute
return super(CursorDebugWrapper, self).execute(sql, params)
  File 
"/usr/local/lib/python2.7/dist-packages/django/db/backends/utils.py", line 
64, in execute
return self.cursor.execute(sql, params)
  File "/usr/local/lib/python2.7/dist-packages/django/db/utils.py", line 
97, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
  File 
"/usr/local/lib/python2.7/dist-packages/django/db/backends/utils.py", line 
62, in execute
return self.cursor.execute(sql)
django.db.utils.ProgrammingError: relation "django_site" does not exist

Is it a problem with my mezzanine installation? From here 
https://github.com/django/django-contrib-comments/issues/30

On Wednesday, January 27, 2016 at 7:12:21 PM UTC+3, Eduardo Rivas wrote:
>
> Never mind, I think the problem is that you're not using migrations with 
> your onepage app. I believe that any app that depends on another app 
> that uses migrations (like mezzanine.pages) must also use migrations 
> itself. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mezzanine-users] Re: Blog post pagination broken

2016-01-28 Thread michela

Hi Danny

I hit the same issue, with 2.7.3, so thanks for above. 

>My workaround for now will be to change MAX_PAGING_LINKS in my site 
settings to something larger. 

This worked for me. 

MIchela

On Sunday, 24 January 2016 10:06:34 UTC+11, Danny S wrote:
>
> Hi all, 
>
> I updated my site to Mezzanine 4.1.0/Django 1.9 yesterday and mostly it 
> went fairly smoothly. 
>
> This morning, however, I was getting errors from the blog app, 
> specifically: 
>
> ~ 
> Internal Server Error: /blog/ 
> Traceback (most recent call last): 
>File 
> "/home/danny/.virtualenvs/ausdwcon-navi/local/lib/python2.7/site-packages/django/core/handlers/base.py",
>  
>
> line 140, in get_response 
>  response = middleware_method(request, callback, callback_args, 
> callback_kwargs) 
>File 
> "/home/danny/.virtualenvs/ausdwcon-navi/local/lib/python2.7/site-packages/mezzanine/pages/middleware.py",
>  
>
> line 95, in process_view 
>  return view_func(request, *view_args, **view_kwargs) 
>File 
> "/home/danny/.virtualenvs/ausdwcon-navi/local/lib/python2.7/site-packages/mezzanine/blog/views.py",
>  
>
> line 58, in blog_post_list 
>  settings.MAX_PAGING_LINKS) 
>File 
> "/home/danny/.virtualenvs/ausdwcon-navi/local/lib/python2.7/site-packages/mezzanine/utils/views.py",
>  
>
> line 158, in paginate 
>  page_range = page_range[start:start + max_paging_links] 
> TypeError: sequence index must be integer, not 'slice' 
> ~~~ 
>
> I've determined this is happening because I have more than 50 blog posts 
> in the database, and we display 5 per page with max_paging_links set to 
> 10. 
> When there's 50 or fewer blog posts to display, the error doesn't occur   
> - this is because the code doesn't enter the "if len(page_range) > 
> max_paging_links:" part of the paginate() function. (You can probably 
> check this by changing BLOG_POSTS_PER_PAGE or MAX_PAGING_LINKS in the 
> admin settings/miscellaneous - both are editable) 
>
> In any case, I did some tracking down - page_range should be a Django 
> Paginator Page object, which can take a slice as its index parameter 
> (See e.g. https://code.djangoproject.com/ticket/23140, 
> https://code.djangoproject.com/ticket/23190, 
> https://code.djangoproject.com/ticket/23088) 
> However, it appears that when I'm getting this exception, the page_range 
> object is of type xrange() - which can't take a slice. 
>
> So is there a problem somewhere in mezzanine/utils/views.py that should 
> be fixed? Or have I made a mistake myself somewhere else? 
> I'm using Python 2.7.6, so if it's a Python 2 vs 3 thing, we should 
> probably make sure the code works on both. 
>
> My workaround for now will be to change MAX_PAGING_LINKS in my site 
> settings to something larger. 
>
> Thanks for any help, 
>
> Seeya. Danny. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mezzanine-users] South Migration Issue

2016-01-28 Thread George M

Hi all,
I am using Python 2.7.6, Django 1.8.7, Mezzanine 4.1.0
I've used an app called onepage to help me with the site. As of the last 
update, the app uses south on this part:-

from south.utils import datetime_utils as datetime from south.db import db 
from south.v2 import SchemaMigration from django.db import models 

Any attempts to deploy are met with errors below

There is no South database module 'south.db.postgresql_psycopg2' for your 
database. Please either choose a supported database, check for 
SOUTH_DATABASE_ADAPTER[S] settings, or remove South from INSTALLED_APPS.
  or
django.db.migrations.loader.BadMigrationError: Migrated app u'onepage' 
contains South migrations. Make sure all numbered South migrations are 
deleted prior to creating Django migrations.

I have tried installing and uninstalling south to no avail. It seems I have 
to use south regardless.
Is there a known work around to this?
Any help is appreciated..

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [mezzanine-users] Different Forms for Signup and Profile Update

2016-01-28 Thread christian . kuper1

That was indeed the way to go, thanks Steve for pointing me into the right 
direction. I discovered that the AccountForm class already has got an 
attribute _signup which does what you suggest. 

I subclassed the AccountForm. If I am not mistaken I had to hide the 
profile form fields during signup (not take them out all together during 
signup) in order to avoid a validation error.

The only small drawback left is that I haven't figured our how to make the 
optional fields "first_name" and "last_name" optional in the AccountForm.

Chris

Am Dienstag, 26. Januar 2016 23:53:18 UTC+1 schrieb Stephen McDonald:
>
> I'd suggest using a custom form class, and checking for a bound user 
> object in its __init__ method, which if present indicates it's the update 
> form, and not signup, and you can then modify the attributes of each field 
> programmatically. This would probably turn out to be less code that 
> defining a form class for each.
>
> On Wed, Jan 27, 2016 at 7:04 AM,  > wrote:
>
>> I want to allow new users to register to a mezzanine based site with 
>> minimal information (i.e. email and password) and allow them to update 
>> their profile information once they are registered. Therefore I would like 
>> to display a form with only the two required fields during signup and the 
>> "full" ProfileForm during profile_update. 
>>
>> Looking at the code in mezzanine.accounts I understand that "signup" view 
>> as well as the "profile_update" view use the same form (i.e. 
>> ACCOUNTS_PROFILE_FORM_CLASS). I know I could overcome this by writing my 
>> custom signup view but is there any other way to solve this so I can keep 
>> using the build-in code?
>>
>> If not: Would it make sense to allow the definition of different form 
>> classes for signup and profile_update? Many modern websites try to 
>> encourage registration by asking only for minimal information during 
>> registration but allow users to add addtional profile information later.
>>
>> Regards Chris
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Mezzanine Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to mezzanine-use...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Stephen McDonald
> http://jupo.org
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [mezzanine-users] Different Forms for Signup and Profile Update

2016-01-28 Thread christian . kuper1

That was indeed the way to go, thanks Steve for pointing me into the right 
direction. I discovered that the AccountForm class already has got an 
attribute _signup which does what you suggest. 

I subclassed the AccountForm. If I am not mistaken I had to hide the 
profile form fields during signup (not take them out all together during 
signup) in order to avoid a validation error.

The only small drawback left is that I haven't figured our how to make the 
optional fields "first_name" and "last_name" optional in the AccountForm.

Chris

Am Dienstag, 26. Januar 2016 23:53:18 UTC+1 schrieb Stephen McDonald:
>
> I'd suggest using a custom form class, and checking for a bound user 
> object in its __init__ method, which if present indicates it's the update 
> form, and not signup, and you can then modify the attributes of each field 
> programmatically. This would probably turn out to be less code that 
> defining a form class for each.
>
> On Wed, Jan 27, 2016 at 7:04 AM,  > wrote:
>
>> I want to allow new users to register to a mezzanine based site with 
>> minimal information (i.e. email and password) and allow them to update 
>> their profile information once they are registered. Therefore I would like 
>> to display a form with only the two required fields during signup and the 
>> "full" ProfileForm during profile_update. 
>>
>> Looking at the code in mezzanine.accounts I understand that "signup" view 
>> as well as the "profile_update" view use the same form (i.e. 
>> ACCOUNTS_PROFILE_FORM_CLASS). I know I could overcome this by writing my 
>> custom signup view but is there any other way to solve this so I can keep 
>> using the build-in code?
>>
>> If not: Would it make sense to allow the definition of different form 
>> classes for signup and profile_update? Many modern websites try to 
>> encourage registration by asking only for minimal information during 
>> registration but allow users to add addtional profile information later.
>>
>> Regards Chris
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Mezzanine Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to mezzanine-use...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Stephen McDonald
> http://jupo.org
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [mezzanine-users] Re: Blog post pagination broken

2016-01-28 Thread Stephen McDonald

Thanks for the info, that's fixed here:

https://github.com/stephenmcd/mezzanine/commit/7dfbf1c5f7a2299a861ca694ce370b815ae0ec13

On Fri, Jan 29, 2016 at 12:27 AM, michela  wrote:

> Hi Danny
>
> I hit the same issue, with 2.7.3, so thanks for above.
>
> >My workaround for now will be to change MAX_PAGING_LINKS in my site
> settings to something larger.
>
> This worked for me.
>
> MIchela
>
>
> On Sunday, 24 January 2016 10:06:34 UTC+11, Danny S wrote:
>>
>> Hi all,
>>
>> I updated my site to Mezzanine 4.1.0/Django 1.9 yesterday and mostly it
>> went fairly smoothly.
>>
>> This morning, however, I was getting errors from the blog app,
>> specifically:
>>
>> ~
>> Internal Server Error: /blog/
>> Traceback (most recent call last):
>>File
>> "/home/danny/.virtualenvs/ausdwcon-navi/local/lib/python2.7/site-packages/django/core/handlers/base.py",
>>
>> line 140, in get_response
>>  response = middleware_method(request, callback, callback_args,
>> callback_kwargs)
>>File
>> "/home/danny/.virtualenvs/ausdwcon-navi/local/lib/python2.7/site-packages/mezzanine/pages/middleware.py",
>>
>> line 95, in process_view
>>  return view_func(request, *view_args, **view_kwargs)
>>File
>> "/home/danny/.virtualenvs/ausdwcon-navi/local/lib/python2.7/site-packages/mezzanine/blog/views.py",
>>
>> line 58, in blog_post_list
>>  settings.MAX_PAGING_LINKS)
>>File
>> "/home/danny/.virtualenvs/ausdwcon-navi/local/lib/python2.7/site-packages/mezzanine/utils/views.py",
>>
>> line 158, in paginate
>>  page_range = page_range[start:start + max_paging_links]
>> TypeError: sequence index must be integer, not 'slice'
>> ~~~
>>
>> I've determined this is happening because I have more than 50 blog posts
>> in the database, and we display 5 per page with max_paging_links set to
>> 10.
>> When there's 50 or fewer blog posts to display, the error doesn't occur
>> - this is because the code doesn't enter the "if len(page_range) >
>> max_paging_links:" part of the paginate() function. (You can probably
>> check this by changing BLOG_POSTS_PER_PAGE or MAX_PAGING_LINKS in the
>> admin settings/miscellaneous - both are editable)
>>
>> In any case, I did some tracking down - page_range should be a Django
>> Paginator Page object, which can take a slice as its index parameter
>> (See e.g. https://code.djangoproject.com/ticket/23140,
>> https://code.djangoproject.com/ticket/23190,
>> https://code.djangoproject.com/ticket/23088)
>> However, it appears that when I'm getting this exception, the page_range
>> object is of type xrange() - which can't take a slice.
>>
>> So is there a problem somewhere in mezzanine/utils/views.py that should
>> be fixed? Or have I made a mistake myself somewhere else?
>> I'm using Python 2.7.6, so if it's a Python 2 vs 3 thing, we should
>> probably make sure the code works on both.
>>
>> My workaround for now will be to change MAX_PAGING_LINKS in my site
>> settings to something larger.
>>
>> Thanks for any help,
>>
>> Seeya. Danny.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Mezzanine Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mezzanine-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Stephen McDonald
http://jupo.org

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [mezzanine-users] Problem deploying Mezzanine on DigitalOcean

2016-01-28 Thread Eduardo Rivas

Glad you could move forward. Have you created the migrations for the
onepage app? I don't think you'll be able to do much without that.

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [mezzanine-users] South Migration Issue

2016-01-28 Thread Eduardo Rivas

Django implemented built-in migrations with the release of 1.7, and South
became obsolete. You will need to create standard migrations for the
application to be compatible with Django 1.7+. The Django docs explain this
with detail.

https://docs.djangoproject.com/en/1.8/topics/migrations/#upgrading-from-south

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [mezzanine-users] South Migration Issue

Re: [mezzanine-users] South Migration Issue

Re: [mezzanine-users] South Migration Issue

[mezzanine-users] Re: 404 page with USE_I18N = True

[mezzanine-users] Re: drum template tag error

Re: [mezzanine-users] Problem deploying Mezzanine on DigitalOcean

Re: [mezzanine-users] Problem deploying Mezzanine on DigitalOcean

[mezzanine-users] Re: Blog post pagination broken

[mezzanine-users] South Migration Issue

Re: [mezzanine-users] Different Forms for Signup and Profile Update

Re: [mezzanine-users] Different Forms for Signup and Profile Update

Re: [mezzanine-users] Re: Blog post pagination broken

Re: [mezzanine-users] Problem deploying Mezzanine on DigitalOcean

Re: [mezzanine-users] South Migration Issue

14 matches

Site Navigation

Mail list logo

Footer information