Разработка после тестирования

No module name '_ctypes' while creating new virtualenv

2019-12-31T07:19:00.001+02:00

When I tried to create virtualenv with python3.7 (

virtualenv -p /usr/local/bin/python3.7

on one of my fresh VPS I faced

no module name '_ctypes'

You should perform these steps to fix it:

sudo apt-get update
sudo apt-get install libffi-dev

If you still have same error then you probably installed python3.7 by yourself from source codes. If so just repeat this installation:

cd /usr/src
wget https://www.python.org/ftp/python/3.7.4/Python-3.7.4.tgz
sudo tar xzf Python-3.7.4.tgz
cd Python-3.7.4
sudo ./configure --enable-optimizations
sudo make altinstall

:hint if you have more than one cpu core, then you can speed up make stage by:

sudo make altinstall -j <number_of_cores>

:hint

cat /proc/cpuinfo

- shows you the information about your CPUs

postgresql - permission denied for sequence

2019-12-18T10:20:00.000+02:00

Если ты столкнулся с %%permission denied for sequence %%, то значит, что ты используешь в табличке автоинкремент ( тип %%SERIAL%% или %%BIGSERIAL%% ) и тебе нужны соответствующие гранты соответствуюшему пользователю: %%grant all privileges on sequence to %%

postgresql - permission denied for relation

2019-12-18T10:17:00.003+02:00

Если ты столкнулся с %%permission denied for relation%% , то попробуй дать соответствующему юзеру: %%grant all privileges on table to ;%%

python3 f-string 'invalid syntax'

2019-12-04T09:29:00.001+02:00

If you faced 'invalid syntax' while using f-strings in python3 then you probably have ancient python version installed. f-strings feature appeared in 3.6 So you have to install a new python to be able to use f-strings in your code: For example, you are in Ubuntu ( or some other deb-based distrib ):

sudo wget https://www.python.org/ftp/python/3.7.4/Python-3.7.4.tgz sudo tar xzf Python-3.7.4.tgz cd Python-3.7.4 sudo ./configure --enable-optimizations sudo make altinstall # not to replace default python

Raw query must include the primary key

2019-10-30T08:34:00.000+02:00

Как и любое достижение прогресса ORM-ы в каких-то кейсах хороши и удобны, а в некоторые моменты - раздражают. Например, когда речь о Django и случае, когда ты хочеш выполнить raw-запрос с группировкой ( чтобы не париться с нечевидными annotate и импортом нужных агрегатных функций ) . Пример:

r = CourseStudent.objects.raw("select course_id, count(*) as c from coursestudent group by course_id order by c")

В ответ мы видим:

Raw query must include the primary key

WTF? Как я вам воткну pk в запрос с группировкой по произвольному ключу ? К счастью, обойти просто - вот такой запрос спокойно отработает:

r = CourseStudent.objects.raw("select course_id as id, count(*) as c from coursestudent group by course_id order by c")

- мы немного схимичили, и навесили на произвольный ключ alias, такой же как pk таблицы, к которой мы делаем наш произвольный запрос

Migration is applied before its dependency on database

2019-10-29T08:55:00.000+02:00

Разбираемся с ошибкой

Migration B is applied before its dependency A on database

Django version 1.11 Поселектив табличку %%django_migrations%% можно выяснить точную хронологию применения миграций и дальше выправить ее руками. Автоматически такое разрулить, по-видимому, не выйдет.

Еще раз про юникод в perl и злосчастный Wide character in subroutine entry

2016-01-16T14:51:00.001+02:00

Многие perl скриптеры порой впадают в ступор от Wide character in subroutine entry. Хорошо, если знают хотя бы примерно о том, что такое Wide character, хуже , если нет. Хорошо, если начинают копать матчасть и разбираются с в общем-то нехитрой работой с юникодом в perl, хуже, если начинают наобум тыкать в use utf8, encode/decode... На выходе порой может получиться забавная инструкция с кучей вызовов на всякий случай.. она может даже будет работать, но подобный модуль будет доставлять всем вокруг головную боль. Итак, все просто: 1. если имеешь дело с данными из внешнего источника - проверяй их перед употреблением на is_utf8 и дальше действуй по обстоятельствам: либо кодируй, либо декодируй - но осознанно. 2. если имеешь дело со строковыми константами , то достаточно сказать use utf8 , чтобы для интерпретатора все константы скрипта были помечены не как последовательность байт, а именно как юникод-строка. 3. чтобы перевести в последовательность байт из юникода - decode 4. чтобы перевести из последовательности байт в юникод - encode помните о том, кто будет вас дергать и описывайте свои входы и выходы а также свою политику относительно внутренней работы со строками ( работаете как с последовательностю байт или как со юникод-строками ) и все будет хорошо.

Классическая проблема верстки - выравнивание блоков

2013-07-18T19:20:00.000+03:00

Часто встречается ситуация, когда некий контейнер "набивается" float-ом дочерними элементами . На макете все красиво и ровно. На практике, после того как начинается работа с реальным контентом (например содержимое категории товаров в магазине), то однотипные блоки получаются разными по высоте. Проблему можно решить принудительным транкейтом содержимого, подбором "максимальной" фиксированной высоты или javascript-ом. Пример кода, решающего подобную проблему (используется jQuery):


//делаем высоту всех .thumbnail одинаковой
   var  max_height = 0;
 $('.thumbnail').each(function(){
    h = $(this).height();
   if(h > max_height){
     max_height = h;
    };
   });
 $('.thumbnail').css('height',max_height);

Этот код хорошо отработает , например , в IE, а вот Chrome могут быть проблемы, если в .thumnail внутри есть изображение. На момент вычисления height оно еще может быть не загруженным и поэтому полученные величины height и width могут очень удивить верстальщика :) Поэтому код надо модифицировать , например, вот так:


$(document).ready(function(){
//делаем высоту всех .thumbnail одинаковой только после полной загрузки всей страницы
   var  max_height = 0;
 $('.thumbnail').each(function(){
    h = $(this).height();
   if(h > max_height){
     max_height = h;
    };
   });
 $('.thumbnail').css('height',max_height);
});

Unable to find vcvarsall.bat

2013-07-09T18:59:00.001+03:00

Часто при установке некоторых python-библиотек (PIL, django-imagestore .. ) под windows возникает ошибка:

Unable to find vcvarsall.bat

Причина отсутствии или невозможности при установке найти нужный Сишный компилятор, который как правило есть в поставке MS VS.

Для решения проблемы совсем необязательно ставить "студию". Можно обойтись компилятором mingw:

качаем отсюда и ставим
скачиваем нужную python - библиотеку и выполняем для ее setup.py :


setup.py install build --compiler=mingw32

Перед этим не забудьте прописать путь к mingw32.exe в PATH (например C:\mingw\bin)

django-rest-framework - некоторые особенности

2013-07-04T16:02:00.001+03:00

Как и обещал ранее дамплю все грабли и особенности , которые возникают в ходе освоения этого фреймфорка.

Сразу отмечу, что авторы этого приложения большие молодцы - документация на фреймворк сделана в виде пошагового туториала - фактически онлайн учебника. На первых шагах все делается стандартными механизмами. И дальше, по мере продвижения, авторы упрощают код с помощью многочисленных "плюшек" , которые предоставляет их приложение. Советую для лучшего понимания и во избежание последующего недопонимания :) именно так и поступать, а не копипастить конечные синтаксические конструкции.
Хотя при этом могут и проблемы возникнуть . Например, на одном из шагов авторы предлагают реализовать rest-вьюхи как обычные function-based django views, сопровождая их декоратором api_view. Этот шаг - исключение и его лучше пропустить, сразу перейдя к class based views , иначе возникнет ошибка:

Cannot apply DjangoModelPermissions on a view that does not have `.model` or `.queryset` property.

Но и после перехода в class-based views не забываем указывать model или queryset в полях вьюшного класса.

Unicode

Для того, чтобы в отдаваемом REST-ом контенте корректно отображался Unicode необходимо в settings явно прописать UnicodeJSONRenderer.

Например:


REST_FRAMEWORK = {
 
    'DEFAULT_RENDERER_CLASSES': (
        'rest_framework.renderers.UnicodeJSONRenderer',
    )
}

Выбор решения для организации API на django-сайте

2013-07-04T09:11:00.000+03:00

Возникла задача в одном из моих django-проектов предоставить API для взаимодействия с некоей внешней системой.
Первоначальный выбор пал на django-piston. Реализовать операции read-доступа к объектам БД удалось довольно быстро, но вот с операцией создания объекта начались проблемы, частично решив которые и получив новые , решил выбрать другое решение.. Уж больно надоело патчить чужую библиотеку.
Другое решение - это Django Rest Framework. Знакомство с отзывами и документацией обещает менее нервную разработку. К непосредственной попытке использования приступлю на днях.
Постараюсь не забыть задокументировать здесь все особенности и подводные камни, если таковые найдутся :)

django: форма обратной связи с аттачами и проверкой на вирусы

2013-05-29T08:45:00.003+03:00

Предыстория

Недавно получил от одного своего постоянного клиента заказ на следующую доработку: "нужно доработать форму обратной связи для возможности отправки файлов клиентами".

В процессе обсуждений выяснилось, что файлов надо аттачить "сколько хочешь".

А чтобы заказчик не "словил вирусняк" через эти самые аттачи , я решил реализовать сканирование.

Было 2 варианта:

настроить на серваке (linux) какой-нибудь , желательно бесплатный , антивирусный демон
использовать API какого-нибудь авторитетного онлайн сервиса

Я остановился на втором варианте, тем более что был немного знаком с Virustotal.

Бегло ознакомился с доками на его API .

Проверил работоспособность его тестовых примеров - все ок.

И приступил к "допиливанию" имеющейся формы обратной связи.

Как только причешу код , чтобы было не стыдно опубликовать на bitbucket, то детально опишу реализацию.

Кому не терпится - пишите, торопИте :)

django-lfs: особенности работы со скидками

2013-04-29T21:18:00.001+03:00

Текущая стабильная версия 0.7.7

В django-lfs есть два механизма работы со скидками:

назначать скидку каждому товару отдельно в карточке товара
создавать глобальные скидки, которые действуют в зависимости от критериев (например общая сумма покупки в корзине) - данные скидки применяются не к отдельным товарам , а к всему содержимому корзины.

Особенность в том, что при наличии обоих скидок они суммируются.

При использовании данной и более младших версий django-lfs вместе с django >= 1.4 есть проблема с интерфейсом управления - а именно бага при работе с критериями. Суть ошибки и как ее решить я уже описывал здесь.

Кроме того, глобальным ссылкам не хватает развернутого описания . Например, для того, чтобы вывести страницу со скидками, где было бы содержательно описана суть каждой из них.

Доработать не трудно.

добавляем нужное поле в Discount
добавляем колонку в таблицу discount_discount (если база уже существует) или пересоздаем базу (если старого контента не жалко :)
добавляем нужный html-шаблон для страницы со списком скидок
добавляем view, которая будет рендерить этот шаблон
добавляем url, по которому это view будет "дергаться"

кому нужен патч - пишите.

django-lfs: установка на Windows 7

2013-04-12T20:28:00.002+03:00

Установка django-lfs подробно описана здесь

Но у установки под windows есть несколько особенностей, которые не описаны на официальном сайте

Исходные данные:

windows7 64 bin
python 2.7 , установленный , например в c:\Python27

Требуется установить django-lfs (на текущий момент версия 0.7.7)

качаем инсталлятор http://pypi.python.org/pypi/django-lfs
распаковываем куда нам нужно
cd lfs-installer
качаем правильный bootstrap.py
python bootstrap.py
качаем win-инсталлятор для библиотеки PIL (так как установщик ругнется на отсутствие батника vcvarsall.bat)
создаем ключ в реестре HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\InstallPath со значением, которое копируем из ключа HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\InstallPath - без этой манипуляции инсталлятор PIL "ругнется" Python27 not found
удаляем Pillow из списка зависимостей djanfo-lfs (файл: lfs-installer\eggs\django_lfs-0.7.7-py2.7.egg\EGG-INFO\requires)
устанавливаем PIL
bin/buildout.exe -v
указываем параметры доступа к базе данных (предполагается, что она уже создана) в settings to lfs_project/settings.py
$ bin/django syncdb
$ bin/django lfs_init
$ bin/django collectstatic
$ bin/django runserver
Открываем дефолтный магазин http://localhost:8000 и торгуем :)

django-lfs: wysiwyg и копипаст контента с других сайтов

2013-03-29T08:54:00.003+03:00

В каждом новом веб-проекте встает дилемма - использовать ли wysiwyg в административной части сайта. С одной стороны хочется избавить себя от будущего утомительного контент-менеджмента, который не очень дорого оплачивается (если вообще оплачивается), а с другой - дашь пользователю полноценный wysiwyg - он вмиг сломает всю верстку и в итоге тебя же и обвинит: "ты мол программист, ты должен был все учесть"...

Каждый раз приходится анализировать, что за пользователи будут рулить сайтом, обучать даже иногда.

В общем это проблема не новая. Есть еще одна - смежная с ней. Часто начинающие "контент-менеджеры" сайтов (они же и их владельцы по-совместительству :) не брезгуют простым копипастом контента с сайтов конкурентов, сайтов с понравившимся контентом.. Им невдомек, что есть понятие "копирайт", что редактор "не умеет" превращать чужие картинки в свои, что он копирует буквально все, в том числе и внешние ссылки.

Один такой мой клиент, пользующийся интернет-магазином на django-lfs, ну никак не хотел бросать такую вредную привычку , пришлось запилить ему логику дайнлоада картинок из скопированного куска, вычистку непредусмотренных внешних ссылок .

Везде , где можно был переопредлен обработчик save моделей и в этом обработчике вызывался метод, который скачивает картинки в media, меняет пути на свои локальные, чистит внешние ссылки.

Планирую еще и PIL прикрутить к этому делу, чтобы вотермарки накладывать. Любой каприз, как говорится, за ваши деньги.

p.s. но тырить контент с чужих сайтов, не оставляя ссылок - нехорошо , о чем все мои клиенты честно предупреждаются.

p.p.s если кого интересует, то могу код причесать и выложить на какой-нибудь bitbucket - пишите.

Хостинг jino и bitbucket

2013-03-23T20:05:00.002+03:00

Не хочу давать ни рекламы , ни антирекламы , но у меня возникает следующая проблема с хостингом jino.
Клонирование репозитория с bitbucket в данный момент невозможно, так как hg clone отваливается по tcp-таймауту. Проблема перманентная, то есть не связана с какими-то временными трудностями на любой из сторон.
Вариант с клонированием через ssh не проходит, так как на jino нет ssh-клиента.
Вот и приходится обновлять исходники через третий сервер (

Саппорт пока не ответил на просьбу устранить эту проблему или вообще объясить как-то причину .
Ждем.

lightbox vs elastislide

2013-03-04T18:39:00.002+03:00

В одном из веб-проектов потребовалось реализовать галерею изображений.

Ранее уже успешно использовал плагин jquery.elastislide.js.

Применил и на этот раз.

Кроме того, надо было сделать так, чтобы по клику на фотку она открывалась в "полный рост" - наиболее популярным решением сейчас является для этого lightbox , его я и попытался применить.

Все сделал по манам, верстка правильная, ошибок в консоли js нет, но изображение по клику не открывается - lightbox не фурычит.

Сразу заподозрил конфликт обработчиков событий. Так и оказалось.

Чтобы его преодолеть в опциях создания слайдера необходимо обнулить обработчик onClick изображений:

$('#carousel').elastislide({imageW :300,margin: 30,minItems: 2, onClick: null});

Небольшая ремарка по django-imagestore

2013-02-24T19:38:00.000+03:00

Тому, кто хочет организовать фотогалерею на django, могу посоветовать в качестве основного приложения django-imagestore .
Приличный функционал, возможность расширения засчет переопределения моделей альбомов и фотографий, более-менее удобная админка.
Но как всегда не без греха. Как минимум одна проблема в этом модуле есть - а именно проблема каскадного удаления..
Допустим, у вас есть альбом, в нем много фотографий.

Вы из админки удаляете фотографию (не выключаете из альбома, а просто удаляете).
Мелким шрифтом , конечно, показывается предупреждение о том, что будут удалены все сущности. Но кто их читает ?)

Вот и получается - хотели удалить фотку, а удалили весь альбом.

А если на альбом ссылалась еще какая-нибудь сущность, то и она успешно удалится.
На подобное я напарывался в django-lfs.
Чтобы решить эту проблему , необходимо либо пропатчить поле Image.album, добавив в него on_delete=models.SET_NULL.

Либо переопределить Image , как это позволяет делать imagestore и уже аналогично решить эту проблему на уровне своей модели.

Слайды: кастомизация интерфейса django-admin

2013-02-17T10:50:00.001+03:00

На просторах интернета попалась следующая презентация, которая может задать вектор начинающему джанговоду в направлении того, как можно изменить стандартный интерфейс админки django.

Не могу не поделиться

Customizing the Django Admin from Lincoln Loop

How to improve Test::Class to conrol test ttl

2013-02-12T08:57:00.000+03:00

To make Test::Class control test-suites time-to-live you could inherit Test::Class and redefine runtests method..

For example:

package TTL::Test::Class;
use base qw(Test::Class);
use Test::More;
use POSIX ":sys_wait_h";
use constant DEFAULT_TIMEOUT => 60;
# переопределяем метод запуска тестов 
sub runtests{
    my $t = DEFAULT_TIMEOUT;                                           
    my $pid = fork;                         
    my $child_ret_code;                           
    if( $pid > 0 ){ # parent process                                         
       #child waiting loop
       my $ok_flag = 0;                                                  
       for(my $i=0; $i < $t; $i++){                                       
          if(waitpid($pid, WNOHANG)){                                           
               $child_ret_code = $?/256;                                       
               ok($child_ret_code);                                             
               $ok_flag = 1;                                                  
               last;                                                            
          };                                                                              
          sleep(1);
       };
       if( not $ok_flag ){
         diag "Killing test by its timetolive...";
         kill TERM =&gt; 
         $pid;
         return $ok_flag;
       };
       return $child_ret_code;                                                  
    } elsif( $pid == 0 ) { #child                                               
        exit $self->SUPER::runtests;                                         
    } elsif ( not defined($pid) ) { #unsuccessfull fork                         
        die "Cannot fork child process: $!";                                    
   }                                                                            
} 
1;

I think, we don't need SIGCHILD here..

source

django-sitetree: key error 'request'

2013-02-05T09:26:00.001+03:00

Сообщение об ошибке при работе с django-sitetree в админке django :

говорит о том , что необходимо добавить

KeyError at /admin/sitetree/tree/1/

'request'

Request Method:	GET
Request URL:	http://localhost:8080/admin/sitetree/tree/1/
Django Version:	1.4.3
Exception Type:	KeyError
Exception Value:	'request'

"django.core.context_processors.request", в TEMPLATE_CONTEXT_PROCESSORS

только и всего

django-lfs: EOFError при работе в режиме кеширования

2013-01-31T18:15:00.000+03:00

На одном моем сервере "крутится" магазинчик под управлением Django-lfs

django 1.4
nginx 1.1.9
uwsgi 1.2.3

Время от времени на тревожный email приходят сообщения об ошибке вида:

EOFError

TRACEBACK:
File "..../pydocs/env/lib/python2.7/site-
packages/Django-1.4.1-py2.7.egg/django/core/handlers/base.py", line 111, in get_response
response = callback(request, *callback_args, **callback_kwargs)

File "..../pydocs/deploy/../lfs/catalog/views.py", line 267, in category_view
inline = category_products(request, slug, start)

File "...../pydocs/deploy/../lfs/catalog/views.py", line 358, in category_products
temp = cache.get(cache_key)

File "....../pydocs/env/lib/python2.7/site-packages/Django-1.4.1-py2.7.egg/django/core/cache/backends/db.py", line 75, in get
return pickle.loads(base64.decodestring(value))

Ошибка "мигающая".

Пока лишь понятно, что копать в сторону python модуля pickle .

Поверхностный анализ кода этого pickle пока не помог в поиске причины.

Ждет меня дебаг продолжительный, судя по всему :)

django-lfs: грабли с каскадным удалением

2012-12-27T21:59:00.000+03:00

Текущая известная мне версия django-lfs писалась для django версий еще младших, чем 1.3. До этой версии включительно ORM этого фреймворка содержал досадную "особенность" - ненастраиваемое каскадное удаление сущностей , ссылающихся на удаляемый объект.

Кто не знал этой особенности, получал граблями по лбу либо при тестировании, либо уже, что тоже бывало , при эксплуатации.

Классический фейл с django-lfs: оператор интернет магазина решает удалить производителя, ставшего ненужным. На этот момент к производителю были привязаны пара сотен товаров.

Manage-интерфейс lfs настолько дружелюбен, что не предупреждает юзера об удалении этих пары сотен товаров, заодно с удалением производителя. Но ведь так можно и до инфаркта людей довести! ) В общем эдакое ~~"кто не спрятался я не виноват"~~ кто не делает бекап, вбивает все заново))

Более опытные django-воды обходили подобные проблемы либо на уровне БД либо в хуке для delete-операции, явно обнуляя соответствующие поля в ссылающихся таблицах.

Начиная с версии 1.3 появилась возможность настраивать ORM при удалении объекта. Для этого в описании поля модели надо указывать: on_delete=models.SET_NULL

Круто, только вот разрабы lfs об этом не позаботились, так что патчить модели надо самим.

Ну и в завершение.. чтобы избегать подобных граблей:

1. не надейтесь на протестированность сторонних решений, особенно , если они бесплатные

2. постоянно углубляйте знания инструментария, которым пользуетесь .. в данном случае курить djangoproject.com

3. ежедневный бекап БД спасет от большинства подобных фейлов ( а лучше бекапиться несколько раз в день )

django-lfs: улучшение механизма работы с картинками

2012-12-16T18:56:00.000+03:00

В предыдущем посте я упоминал об ошибке, которая возникнет , если пользователь сайта на django-lfs будет загружать картинки с именем файла , длиной более 99 символов.

Пользователей не выбирают, а костыли в виде явного указания немеряного max_length , меня не устраивают.

Я решил сделать так:

1. принимаем картинку
2. запоминаем расширение файла
3. получаем хеш (например md5) от имени + текущее время (чтобы не получать одинаковых хешей для разных картинок с одинаковыми именами)
4. получаем новое имя конкатенацией хеша и расширения
5. сохраняем

Наилучшим местом в коде, куда вклинить этот алгоритм является lfs/core/fields/thumbs.py

Подключаем вспомогательные библиотеки:




+++ b/pydocs/lfs/core/fields/thumbs.py  Sun Dec 16 19:17:04 2012 +0400
@@ -7,6 +7,13 @@

 except ImportError:

     from PIL import Image



+try:

+    from hashlib import md5

+except ImportError:

+    from md5 import md5

+from time import time

Генерируем новое имя файла перед сохранением:


     def save(self, name, content, save=True):

+       parts = name.split('.')

+       ext = '.%s' % parts[-1] if len(parts) > 1 else ''

+       name = md5("%s-%s"%(name.encode('utf-8'), time())).hexdigest()

+       name = "%s%s"%(name,ext)

        super(ImageWithThumbsFieldFile, self).save(name, content, save)

После этого все имена картинок будут одинаковой длины и о том , зачем юзеру такие длинные файлы, можно не думать. p.s. дальнейшее улучшение механизма работы с картинками будет - проверка файла на то, в допустимом графическом ли он формате или нет. Сейчас django-lfs принимает на вход все подряд. Судя по всему, безопасности это практически не угрожает , но 404 по запросам картинок - это тоже нехорошо.

django-lfs: пара тройка неприятных багов

2012-12-16T13:34:00.003+03:00

Хочу рассказать о нескольких неприятных моментах (читай "ошибках"), с которыми совсем недавно столкнулся при использовании django-lfs:

Ошибки при сохранении картинок с длинными именами

Для хранения картинок в django-lfs используется специальный тип поля, пронаследованный от стандартного ImageFile. В этом стандартном типе дефолтная длина файла картинки 100 символов.
В модели , которая используется для хранения картинок товаров , например, max_length явно не указывается. В итоге при попытке отобразить превьюхи (thumbs) оригинальной картинки с длинным именем ( >= 100 символов), случается поначалу непонятный IndexOutOfRange..Казалось бы причем тут массивы...

Вот такой замечательный код есть..




class ImageWithThumbsFieldFile(ImageFieldFile):
    """
    See ImageWithThumbsField for usage example
    """
    def __init__(self, *args, **kwargs):
        super(ImageWithThumbsFieldFile, self).__init__(*args, **kwargs)
        self.sizes = self.field.sizes

        if self.sizes:
            def get_size(self, size):
                if not self:
                    return ''
                else:
                    split = self.url.rsplit('.', 1)
                    thumb_url = '%s.%sx%s.%s' % (split[0], w, h, split[1])
                    return thumb_url

падает, как нетрудно догадаться, в строчке


                    thumb_url = '%s.%sx%s.%s' % (split[0], w, h, split[1])

Причина в том, чтo в rsplit передается усеченное имя файла.. Как видим, никакими дополнительными проверками авторы себя не обременили, поэтому дело и доходит до "пятисоток"..

Запретить пользователям не аплоадить такие картинки - нельзя.

Планирую следующий фикс: все картинки, поступающие в django-lfs сохранять под сгенерированными уникальными именами заранее фиксированной длины.

А пока для своих проектов на django-lfs сделал небольшой костыль в виде max_length = 2048 в описании модели картинки.

Глюки с редактированием товаров в manage-интерфейсе

django-lfs позиционируется как шустрый фреймворк для ешопов. Шустрость его в частности основана на активном использовании кеширования бд.

Баг , который я сейчас опишу, как раз и проявляется при использовании кеширования.

Допустим , вы используете кеширование в таблице БД. Выставляете время жизни объектов в кеше , например , в 60 секунд.

Пользователь магазина наконец-то решает заняться наполнением. Создает товар, редактирует "данные" и сохраняет их . Затем переходит на "категории" и вносит товар в нужные категории. "Сохранить категории". Лезет на сайт, а товара там нет... Лезет в интерфейс управления и видит, что "активно" , не выставлен, цены нет и вообще вкладка "данные" такая, как будто он к ней не прикасался.
Причина в том, что между сохранением "данных" и сохранением "категорий" не прошло минуты и при сохранении категорий, товар взялся из кеша.

Вопрос, почему не был обновлен кеш при сохранении "данных" , пока открыт. Выясню и исправлю, ведь без кеширования как-то несолидно :)

Да и есть такие django-модули, которые без
кеширования вообще не работают. Например, используемый многими supercaptcha.

UPD:
Глюк с редактированием товаров исправляется отправкой сигнала product_changed в products.py (после сохранения формы данных), а также с отправкой аналогичного сигнала при изменении категорий товара.