Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent issues with importing Page subclasses #127

Open
ethanaward opened this issue Aug 24, 2022 · 0 comments
Open

Inconsistent issues with importing Page subclasses #127

ethanaward opened this issue Aug 24, 2022 · 0 comments

Comments

@ethanaward
Copy link

I've been testing using this for the first time using two development servers with the same configuration, but with dumps from my staging and production servers. I've been running into a couple of different issues. The first is that often, an import process will redirect to the desired parent page as if it was complete, but with no data transferred. I haven't seen any logs or errors related to this, so my assumption is that it's related to the next error.

On some types of pages, I'm running into the following error when importing (truncated to the important part):

  File "/Users/eward/.virtualenvs/kcai/lib/python3.10/site-packages/wagtail_transfer/views.py", line 60, in pages_for_export
    uid = get_locator_for_model(model).get_uid_for_local_id(pk)
  File "/Users/eward/.virtualenvs/kcai/lib/python3.10/site-packages/wagtail_transfer/locators.py", line 147, in get_locator_for_model
    return IDMappingLocator(base_model)
  File "/Users/eward/.virtualenvs/kcai/lib/python3.10/site-packages/wagtail_transfer/locators.py", line 33, in __init__
    raise ImproperlyConfigured(
django.core.exceptions.ImproperlyConfigured: IDMappingLocator cannot be used on MTI subclasses (got <class 'common.models.EditorialPage'>)

Looking into the relevant lines, it looks like this is expected by the code to pass in the base Wagtail Page class, which is eventually determined by the following function (from here)

def get_base_model(model):
    """
    For the given model, return the highest concrete model in the inheritance tree -
    e.g. for BlogPage, return Page
    """
    if model._meta.parents:
        model = model._meta.get_parent_list()[0]
    return model

This is expected to return the base model of the class, but looking at the Django documentation, the get_parent_list function is expected to return in MRO, i.e., the highest concrete model last. This is supported by experimenting in the django shell and looking at the meta values for the Page model in question:

>>> ArticlePage._meta.get_parent_list()
[<class 'common.models.EditorialPage'>, <class 'common.models.BasePage'>, <class 'wagtail.core.models.Page'>]
>>> ArticlePage._meta.get_parent_list()[0]
<class 'common.models.EditorialPage'>

I'm not sure whether this is an error or something that's incorrect with how I'm trying to use this tool. I haven't done any preseeding since these two databases should be distinct, but I wouldn't think that would have an impact on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant