Я выполнил инструкции по добавлению трясогузки в существующий проект Django. В конце инструкции было сказано:

Обратите внимание, что есть одно небольшое различие, когда не используется шаблон проекта Wagtail: Wagtail создает начальную домашнюю страницу основного типа Page, которая не включает никаких полей содержимого за пределами заголовка. Вероятно, вы захотите заменить его своим собственным классом HomePage - при этом убедитесь, что вы настроили запись сайта (в разделе «Настройки» / «Сайты» в админке Wagtail), чтобы она указывала на новую домашнюю страницу.

Я хотел бы изменить «страницу базового типа» на мой класс модели BlogIndex. Я знаю, что могу добавить BlogIndex в качестве подстраницы страницы по умолчанию, а затем указать на нее, как описано в инструкциях. Вместо этого я хотел бы изменить существующую страницу. Меня беспокоит наличие неиспользуемой страницы в корне. Было бы более чистым подходом просто его использовать.

После добавления моего нового класса и его переноса таблица django_content_type выглядела так:

1,admin,logentry
2,auth,permission
3,auth,group
4,auth,user
5,contenttypes,contenttype
6,sessions,session
7,wagtailcore,page
8,wagtailadmin,admin
9,wagtaildocs,document
10,wagtailimages,image
11,wagtailforms,formsubmission
12,wagtailredirects,redirect
13,wagtailembeds,embed
14,wagtailusers,userprofile
15,wagtailimages,rendition
16,wagtailimages,uploadedimage
17,wagtailsearch,query
18,wagtailsearch,querydailyhits
19,wagtailcore,grouppagepermission
20,wagtailcore,pagerevision
21,wagtailcore,pageviewrestriction
22,wagtailcore,site
23,wagtailcore,collection
24,wagtailcore,groupcollectionpermission
25,wagtailcore,collectionviewrestriction
26,taggit,tag
27,taggit,taggeditem
28,blog,blogindex

Есть еще одна таблица: wagtailcore_pages, содержащая три строки:

1,0001,1,1,Root,root,true,false,/,"",false,"",,,false,7
3,000100010001,3,0,Blog Index,blog-index,true,false,/blog/blog-index/,"",false,"",,,false,28
2,00010001,2,1,Welcome to your new Wagtail site!,home,true,false,/blog/,"",false,"",,,false,7

Последний столбец - это content_type_id, который соответствует таблице выше. Я попытался изменить значение с 7 на 28. Когда я зашел на страницу в админке Wagtail, то получил ошибку:

DoesNotExist at /cms/pages/2/
BlogIndex matching query does not exist.
Request Method: GET
Request URL:    http://localhost:8006/cms/pages/2/
Django Version: 3.0.7
Exception Type: DoesNotExist
Exception Value:    
BlogIndex matching query does not exist.
Exception Location: /Users/curt/htdocs/zetcho/venv/lib/python3.8/site-packages/django/db/models/query.py in get, line 415
Python Executable:  /Users/curt/htdocs/zetcho/venv/bin/python
Python Version: 3.8.2

Это произошло до и после того, как я добавил страницу BlogIndex, которую вы видите в файле wagtailcore_pages. Оба были после того, как я запустил миграцию, чтобы добавить ее в модель. Когда я меняю его обратно на 7, все возвращается в норму. Я предполагаю, что он ищет модель не в том месте.

Затем я создал отдельное приложение Wagtail, чтобы увидеть, чем оно отличается. Начало таблицы django_content_type выглядело так:

1,wagtailcore,page
2,home,homepage
3,wagtailadmin,admin

App_label 'home' - это имя приложения, созданного процессом трясогузки. В домашнем приложении есть файл модели с классом HomePage.

Wagtailcore_pages для автономного приложения содержит две строки:

1,0001,1,1,Root,root,1,0,/,"",0,"",,,0,1
3,00010001,2,0,Home,home,1,0,/home/,"",0,"",,,0,2

Интересно, что идентификатор второй строки равен 3 (первый столбец - id). Поскольку поле автоматически увеличивается, строка с идентификатором 2 должна быть добавлена, а затем удалена. Единственное, что я сделал после миграции, - это запустить сервер, чтобы убедиться, что он работает.

Ясно, что мне не хватает еще одного или двух шагов, чтобы заставить его работать, если это вообще возможно. Есть идеи, что они могут быть?

На сайте Wagtail есть билет двух-трехлетней давности относительно настройки страницы по умолчанию, но на решение.

Обновить

Я попытался сделать то, что я понял как решение @ gasman. Wagtail_core_page теперь выглядит так:

1,0001,1,1,Root,root,true,false,/,"",false,"",,,false,7
5,000100010001,3,0,Blog Index,blog-index,true,false,/blog/blog-index/,"",false,"",,,false,28
2,00010001,2,1,Welcome to your new Wagtail site!,home,true,false,/blog/,"",false,"",,,false,28

Единственное изменение здесь - установка типа страницы для второй строки на 28. Я также изменил таблицу blog_blogindex на это:

2,<p>Introduction</p>

В первой колонке было пять. Я добавлял и удалял несколько раз, таким образом, пять. Я остановил и перезапустил приложение и получил следующую ошибку, когда добавил / cms к URL-адресу:

KeyError at /cms/
5
Request Method: GET
Request URL:    http://localhost:8006/cms/
Django Version: 3.0.7
Exception Type: KeyError
Exception Value:    
5
Exception Location: /Users/curt/htdocs/zetcho/venv/lib/python3.8/site-packages/wagtail/core/query.py in specific_iterator, line 403
Python Executable:  /Users/curt/htdocs/zetcho/venv/bin/python
Python Version: 3.8.2

Я предполагаю, потому что у меня все еще есть третья строка в таблице wagtail_core выше. У меня была эта строка, чтобы она появилась в таблице blog_blogindex. Затем я попытался удалить строку с пятью в ней и получил ошибку postgre / SQL:

[23503] ОШИБКА: обновление или удаление в таблице "wagtailcore_page" нарушает ограничение внешнего ключа "wagtailcore_pagerevi_page_id_d421cc1d_fk_wagtailco" в таблице "wagtailcore_pagerevision" Подробно: на ключ (id) = (5) по-прежнему ссылаются из таблицы "wagtailcore_pagerevision".

Поняв, что я неправильно прочитал четко сформулированный ответ @ gasman, я добавил в blog_blogindex вторую строку:

5,<p>Introduction</p>
2,<p>unused page</p>

Должна быть только одна запись: вторая. Я изменил семь на 28 в wogtailcore_page для строки, созданной как часть настройки. Трясогузка прошла без ошибок, а на странице по умолчанию используется класс BlogIndex.

У меня возникла дополнительная проблема: удалилась строка сайта. Я почти уверен, что это было результатом того, что я удалил страницу, на которую он указывал. Я изменил домашнюю страницу по умолчанию в настройках. Я просто добавил строку обратно, и все было хорошо. Я должен был сначала изменить строку сайта обратно.

Исправление

  1. Добавьте трясогузку в свой проект, следуя инструкциям по трясогузке.
  2. Добавьте класс модели для домашней / базовой страницы, которую вы хотите использовать. Я установил свой в отдельном приложении.
  3. Запустите makemigrations и выполните миграцию.
  4. На этом этапе вы должны создать резервную копию своей базы данных на случай, если на следующих этапах что-то пойдет не так. Вы будете вручную изменять данные таблицы.
  5. Получите доступ к базе данных и добавьте строку в новую созданную таблицу классов, как описано @gasman.
  6. Измените столбец content_type_id на странице wagtailcore_page второй строки на идентификатор вновь созданного класса. Должно быть только две строки, первая из которых является корневой. Вы можете найти идентификатор в таблице django_content_type.
  7. Зафиксируйте свои изменения и запустите приложение.
0
curt 13 Июн 2020 в 02:58

1 ответ

Лучший ответ

Недостающий шаг - создать запись в таблице blog_blogindex с page_ptr_id = 2, чтобы сопровождать запись wagtailcore_page. Трясогузка использует многотабличное наследование для Объекты страницы, поэтому данные для экземпляра BlogIndex разделяются между wagtailcore_page (который содержит поля, общие для всех моделей страниц) и blog_blogindex (который содержит поля, определенные специально для BlogIndex).

Однако я не знаю ни одного способа создать запись blog_blogindex с помощью Django ORM в качестве отдельной операции - если вы попробуете, она попытается создать новую запись wagtailcore_page одновременно . «Домашнее» приложение в автономном проекте работает над этим (при миграции 0002_create_homepage), удаляя старый экземпляр Page и создавая HomePage для его замены (создавая записи как в wagtailcore_page, так и в {{X4}) }) - это приводит к отсутствию идентификатора 2. Если вы действительно хотите избежать этого шага удаления / воссоздания в своем собственном приложении, вам, вероятно, придется создать запись blog_blogindex с необработанным запросом SQL INSERT.

1
gasman 13 Июн 2020 в 08:52