Inline Add not working about django-seo HOT 12 CLOSED

Thanks for the report!

This isn't in the test suite for some reason, and it doesn't throw an exception when running sqlite. I've cleaned up the tests to get them to run on postgres and will add a new one for this.

I'm not sure how to fix it though: there's a signal to create a metadata object when a new instance on the related model is created, but the admin tries to add the one you just edited inline afterwards.

from django-seo.

The only fix I can think of is to disable the instance adding via post_save signal when an inline is used. The difficulty is then trying to work out which models use the inline.

Another option would be to require an explicit command to switch on automatic metadata creation, with a warning in the docs that it cannot coexist with an inline form in the admin.

from django-seo.

hmmm. can you point me to the code parts that are involved? i am not familiar enough with the application. would it be possible to check if the object was already created? in that case just using the object and editing the fields? kind of like get_or_create?

from django-seo.

Nope, not possible and would be problematic in its own way.

The solution is actually simple: if you use an inline form in the admin, don't put the model in the seo_models setting. That setting will add a new metadata instance automatically, and the inline with do something similar, so there's no need for both.

I've updated the docs to mention it, and fixed some other problems I saw when using inlines in the admin. I hope that this won't be a point of confusion, otherwise I might have to consider removing the seo_models feature.

Thanks for the report! I'm feeling a bit better about the library and maybe even confident enough to push a release to pypi.

Cheers,

Will

from django-seo.

(PS make sure you pull an update, I've fixed something else you might come up against)

from django-seo.

cool. it works to add them as inlines now. I have one more small problem. when I do:

{% get_metadata for profile as metadata %}{{ metadata }} in my templates I never get any data back. This happens when I attached metadata to the object and also when I did not (in that case it should display the default values)

am I doing something wrong?

thanks for the quick responses...it is sunday afterall ;)

from django-seo.

Sorry, I worked on the first part and forgot to come back to the second. I'll look into this now.

from django-seo.

Do you definitely have a get_absolute_url method on your profile object? (will speed up my attempt to reproduce the problem)

from django-seo.

(By the way, you don't have to include the "for profile" bit if you are currently on the profile page, the metadata for the current path is displayed when you don't use the "for obj" syntax)

from django-seo.

i have:

@models.permalink
def get_absolute_url(self):
return ('location_detail', (), {'username': self.user.username })

in my Profile model. The get_absolute_url matches the url on the page.

url(r'^(?P[\w.-]+)/$', 'xxx.views.location',
name='location_detail'),

thats the url pattern.

when I remove "for profile" I get the default values back, but I don't get the values I attached to the model.

a question on the side:
why would you get the metadata over the url if you already have the actual businessobject that the metadata is associated to?

from django-seo.

Not sure about this, can you confirm in the admin that the relevant "XYZ Metadata (model instance)" objects have an (accurate) path? Up until earlier today the admin inline wouldn't have added an accurate path.

(side question: for flexibility. you only need to specify the metdata in the base template, and it will work for all pages, even the one's without associated objects (like when you link metadata to views or raw paths). The value can also be cached against the path, so there doesn't have to be a performance hit)

Thanks for the feedback!

from django-seo.

when I remove "for profile" I get the default values back, but I don't get the values I attached to the model.

I'm guessing that this one has to do with not using RequestContext. I've added a strict check with a friendly message to help people out who fall into this trap.

from django-seo.