I know that it is possible to customize the autoroute to generate the slug in a way customer likes.
Now I have customized my BlogPost content type to meet my client needs and all works fine.
After a while he wants to add another Blog to site with some different settings (eg: Autoroute needs different slug settings, a field I have added should not be there but he wants another one... etc)
So to make a long story short: I would need to use a different BlogPost content type for the second blog.
The site must be the same, I cannot split in two other sites.
Now the question:
"Is it possible in Orchard to define more than one blog and customize the BlogPost content type for each Blog in a different way?"
Thanks
Related
I'm totally new to Mezzanine CMS. I got handed a site to work with and so far I've been able to do all the changes without problem. I've run across a problem in which they want a new section in the home page. I go to the admin section to edit the home page, but there is no extra content field.
On the home page, I see 4 sections "content" "priorities" "testimonials" and "clients". I would like to have another "content" area as a 5th section. How do I go on and add this section? I'm totally new to Django but would be appreciative if someone could explain or point in the right direction.
Here is a link to an image for reference.
https://imgur.com/a/sUKOtvS
Thanks in advance
The homepage content would be backed by a Django model with attributes for the partners and testimonial fields. You'll need to find the Python class for this model in your code base (you could search for those field names), and you'll need to add a new attribute for the new section you need.
Django and Mezzanine have lots of different field types you can use for these attributes, so consult their respective documentation for how those work (Django's are a lot more comprehensive, so start there).
Once you've done that, you'll need to create a database migration for the new attribute - that adds the field to the database table that will store the actual content, again consult the Django documentation for how these work.
Finally you may need to add the new field to the Admin class, which is the Python class (similar to the model) that controls which fields appear in the admin interface, and how they appear. I say "may" as these generally appear automatically without any code, but if things have been modified to a certain extent, you may need to do this manually.
My code shop is developing a multi-tenant Wagtail site, and we'd like each Site to have its own set of tags. We want this so that tags defined by users of Site A don't appear in the autocompleter or the "popular tags" listing for users of Site B.
Would this be possible with a custom Tag model? I'm thinking that we could prefix the tag's slugs with the hostname of the current Site, then filter them based on that prefix when pulling tags for the "popular tags" listing or the autocompleter.
If this is not currently possible, could Wagtail be monkey-patched to support it? If so, what code might need to change?
A custom tag model would be the way to go, yes. One issue you'd currently have to work around (logged here: https://github.com/wagtail/wagtail/issues/3577) is that the autocomplete view is hard-coded to use the default tag model, so to use a custom one you'd need to duplicate that view in your own app, along with the AdminTagWidget that references it.
I can't seem to grasp the difference between HyperlinkedIdentity and HyperlinkedRelated Fields. I have a few questions that I can't seem to find the answers to online.
What is the actual difference? When would I want to use one vs. the other.
My next question is say I have 2 models, Project and Task.
A Task has a ForeignKey to Project. If I wanted the Project to hyperlink to the tasks within it, which Hyperlink field would I put in the ProjectSerializer? And what field would I put in the TaskSerializer to complement the ProjectSerializer assuming I wanted the tasks to be able to hyperlink back to the Project they are related to?
What is the difference between using the hyperlinked fields vs. just using regular nested serializers? When using hyperlinked fields, can I still filter by pk/id?
Last, What if a model had two hyperlinked relations in the serializer? From what I understand it creates a url field for each hyperlink, would it create two url fields in this case?
Thanks for any clarification you can offer, it will be a huge help towards cementing my understanding on the subject and allowing me to complete my API for my project.
What is the actual difference? When would I want to use one vs. the other.
HyperlinkedIdentityField is an hyperlink field for the current object itself while HyperlinkedRelatedField represent an hyperlink to other instances.
A Task has a ForeignKey to Project. If I wanted the Project to hyperlink to the tasks within it, which Hyperlink field would I put in the ProjectSerializer? And what field would I put in the TaskSerializer to complement the ProjectSerializer assuming I wanted the tasks to be able to hyperlink back to the Project they are related to?
HyperlinkedRelatedField is what you're looking for.
What is the difference between using the hyperlinked fields vs. just using regular nested serializers?
Hyperlinks can be browsed independently from the original resource. Handy if one of them belongs to another system. For example, you'll likely want to use hyperlink to tweets rather than let your server fetch them and them return them nested. Hyperlinks also allows the client to deal with its own caching rather than sending back all the data. Could be handy in case of fetching a list of items that nest the same user.
On the other hand, hyperlinks increase the network request count because it needs to fetch more data.
When using hyperlinked fields, can I still filter by pk/id?
Not sure what you mean here.
What if a model had two hyperlinked relations in the serializer? From what I understand it creates a url field for each hyperlink, would it create two url fields in this case?
Correct. hyperlinked relation are just a representation of a relation. It provides an hyperlink (an uri) to fetch the associated object.
This is useful because you won't need to know the pattern to fetch an object from the id: with a PrimaryKeyRelatedField you'll get the id but are missing the url to fetch the associated object.
This also allows the server to manage its own uri space without the need of updating the clients.
Hope this will help.
I am interested in setting up my application so that I can serve location specific content.
Something like craigslist, where miami.craigslist.org only shows posts in miami.
Assuming that I have a model that has a City field, what would be the best way to achieve this?
Banjer suggested the Sites framework, but I feel like it might not be a 100% perfect fit for your situation. The sites framework works well for different sites sharing the same database. But in your case, its all the same site and you are basically just wanting to pass an argument to your views for the city.
You could probably do something even simpler by just pointing wildcard *.domain.com to your django site, and then using request.get_host() in the view to parse out the subdomain:
https://docs.djangoproject.com/en/1.4/ref/request-response/#django.http.HttpRequest.get_host
So if the domain were: "losangeles.domain.com", and you parsed out "losangeles", you could use that as your city "tag" in your query. And when you create new content, you can just tag it with a city.
Post.objects.filter(city_tag="losangeles")
I suppose it depends on how robust of a "location" structure you need in your site. It very well might be a City model with various meta data fields, including the tag field. Then you would associate it with the content as a foreign key. It kind of approaches the same general idea as the Sites framework, but in this case you aren't really creating different sites.
You should check out the "sites" framework. If you've ever used the built-in Django admin, then you've probably seen the sites section where example.com is the only site listed by default.
Real world example, from the link I provided:
Associating content with multiple sites
The Django-powered sites LJWorld.com and Lawrence.com are operated by
the same news organization – the Lawrence Journal-World newspaper in
Lawrence, Kansas. LJWorld.com focuses on news, while Lawrence.com
focuses on local entertainment. But sometimes editors want to publish
an article on both sites.
The brain-dead way of solving the problem would be to require site
producers to publish the same story twice: once for LJWorld.com and
again for Lawrence.com. But that’s inefficient for site producers, and
it’s redundant to store multiple copies of the same story in the
database.
The better solution is simple: Both sites use the same article
database, and an article is associated with one or more sites.
So instead of a City field, you'd add a field to your model for Site, e.g.:
sites = models.ManyToManyField(Site)
You basically have one database that all of your cities use. Convenient, but I'm wondering how it would scale down the road. I'm starting a similar project myself and will use the Django sites framework to get the project off the ground. I'm interested in hearing about a more scalable solution from a database person though.
I just want to do a basic site in Django and the flatpages app is super simple, but it doesn't support a couple of things that I need, namely custom fields and future-dating. That is setting a publish date to some point in the future rather than publishing immediately.
What's the best option for getting future-dated posts in Django?
The answer to this question is the same as your question "Is there anything better than Flatpages?"
django-cms allows you to arrange your flatpages in a hierarchical structure and lets you set a future publish date.
By custom fields I assume you mean fields defined by users? If so then you'll have to implement that yourself on top of django-cms.