convert_image_model.rst 3.2 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182
  1. Convert Existing Site to Use a Custom Image Model
  2. =================================================
  3. .. versionadded:: 0.19
  4. Added support for custom image models. You must be on version
  5. 0.19 or higher in order to follow this guide.
  6. Using a custom image model is a very similar process to using a custom user
  7. model in Django --- it is easy to do when starting a new project but extremely
  8. difficult to do mid-project. This process requires deep understanding of the
  9. Django ORM, SQL, and relational database design. It is therefore recommended to
  10. truly evaluate if and why you really need to switch to a custom image model. If
  11. you're simply looking to store metadata about an image, the same effect could be
  12. much more easily achieved with a separate "metadata" model with a `OneToOne
  13. <https://docs.djangoproject.com/en/stable/topics/db/examples/one_to_one/>`_
  14. relationship to the Image model, and do a reverse lookup (e.g.
  15. ``image.metadata``).
  16. Before starting this guide, ensure you have updated to the latest Wagtail CRX,
  17. have run all migrations, and do not have any pending migrations.
  18. .. code-block:: console
  19. $ python manage.py migrate
  20. $ python manage.py makemigrations
  21. No changes detected
  22. .. include:: _custom_image1.rst
  23. .. include:: _custom_image2.rst
  24. Now, apply the migration:
  25. .. code-block:: console
  26. $ python manage.py migrate mediamodels
  27. .. include:: _custom_image3.rst
  28. Step 4: Migrate your models and database schema by hand
  29. -------------------------------------------------------
  30. At this point the database tables of existing wagtailcrx models have FK pointing
  31. to ``wagtailimages.Image``, however Django thinks they are pointing to the new
  32. custom image table, hence creating FOREIGN KEY constraint problems.
  33. For this same reason, running ``makemigrations`` will yield "No changes
  34. detected" as the Django ORM has no knowledge that the foreign keys are pointing
  35. to the wrong tables. Hence the database schema must be changed by hand.
  36. The end result is your existing image database tables should be moved to the new
  37. custom image table, and every current table with a foreign key to the old image
  38. table needs to be updated as a foreign key to the new image table.
  39. This process will differ from project to project, so you will need to find your
  40. own way to update the database schema that fits your project. Many related
  41. discussions about switching the Django User model (replace "user" with "image"
  42. in this context) can be found online and are highly relevant and helpful. Start
  43. by reading `Django ticket #25313 <https://code.djangoproject.com/ticket/25313>`_
  44. on the subject.
  45. To help with your database update, below is a list of each concrete CodeRed
  46. model which references the Image. A `search query of the source code
  47. <https://github.com/coderedcorp/wagtailcrx/search?l=Python&q=get_image_model_string>`_
  48. can also yield specific results.
  49. * ``wagtailcrx.models.CoderedPage.cover_image``
  50. * ``wagtailcrx.models.CoderedPage.og_image``
  51. * ``wagtailcrx.models.CoderedPage.struct_org_logo``
  52. * ``wagtailcrx.models.CoderedPage.struct_org_image``
  53. * ``wagtailcrx.models.CarouselSlide.image``
  54. * ``wagtailcrx.models.LayoutSettings.logo``
  55. * ``wagtailcrx.models.LayoutSettings.favicon``