I want to make a website about illustrated books. There are two different kind of authors for a book: writers and illustrators
For each writer I want to make a page that lists the books for that writer. The path would be:
http://mysite.com/writers/EdgarAllanPoe
http://mysite.com/writers/OscarWilde
etc
The same for each illustrator: a page for each illustrator listing the books illustrated by her or him.
Paths in this case would be:
http://mysite.com/illustrators/DiegoRivera
http://mysite.com/illustrators/FridaKahlo
etc
and then, each book will have a single page (like a post):
http://mysite.com/books/OneHundredYearsOfSolitude
http://mysite.com/books/WinnieThePooh
etc
Is it possible to do this in Wordpress? Thanks.
Absolutely, there are definitely ways to do this. The way I'd recommend it is using one custom post type for books and two custom taxonomies for illustrators and authors.
That would give you the url structures you want right out of the box, and would make it easy to associate any book with an author and illustrator (or multiple authors and illustrators, if it's a collaborative book) and would involve only about 30 - 40 lines of code to set it up. There'd be more involved in getting the templating to act the way you wanted, but not much.
Related
Django 1.11.6
Could you tell me what is the Django way of implementing structured data.
I have an information site. And I may need any type of structured data: either present or appearing in future.
I mean this: https://developers.google.com/search/docs/guides/intro-structured-data
I append articles through admin only. In other words users don't generate articles, they just comment.
Structured data may be a big insertion to a page. Even in the above linked page an example is trimmed for brevity. And there may be more content types in future. So, maybe it is not reasonable to burden models with such information.
I can only think of a safe template tag.
In the middle of articles structured data will be inserted, say, as a JSON-LD structured data.
Could you tell me what are best practices here.
What I am trying to create is a site for resources. Basically, you add resources such as books and videos via links. Now, with any resource site that caters to a variety of resources, you need to tag them in order to understand what kind of resource you are using.
For example, if you make notes on something like Chemistry or key points from a talk on lets say "Django", then these are text documents. Thus you would want them inside a TEXT TAG.
So, when you are making a form for this kind of thing, what form field would you use? For example, by knee-jerk approach is to simple make a text area field, and then separate the different tags via comma. Now, this can be prone to many problems, I'd just like to know what is the best approach to take to solving this problem? Basically, an easy way to validate the data input? Would forms.ChoiceField be the best approach to the problem or is there something else that is superior?
https://www.djangopackages.com/grids/g/tagging/ is your best bet, most specifically https://github.com/alex/django-taggit. If you want to run your own tagging system, take a look at the source code for some ideas.
EDIT: The easiest way to display this in a form would be to use a ModelMultipleChoiceField. This allows you to select multiple tags for a single resource, and handles server-side validation and conversion to the actual Tag instances. However, I think most people would agree this option looks hideous, and it is certainly not user-friendly if there is a large amount of possible tags.
If you're using jQUery, another option is to use Django_select2. This is what I have personally used in a similar situation, and it handles a large amount of possible tags very well. Django_select2 is a thin wrapper around jQuery's Select2 plugin, with a bit of added functionality (most notably the AutoView and AutoModelSelect2Field). This provides a hybrid between a text field and a select list, allowing you to search all tags and easily select multiple tags. See http://ivaynberg.github.io/select2/ for examples of what you can achieve.
Maybe this isn't the correct place to ask, but I asked this question on Joomla forums and did not get any answers. If someone can help me or at least point me in the right direction, I would really appreciate.
My question is: In a Joomla 2.5 website, I want to create two different kinds of forms for registering users. Maybe "registering" isn't the correct term. I want to create something like a very simple database which will hold records for two kinds of users:
- one which will be interested in working in projects, so in this case the form will have more fields and specific details to fill
- one which will be interested only in receiving newsletters from the site, and in this case only basic contact information will be required.
I did some research and found an extension named AcyMailing which can handle the newsletters for example, but I need to have all my potential users registered as Joomla users. I would like to avoid that if possible. If not, how can I differentiate the two kinds of users on registration, so the visitor can choose which option he wants and in this case, add more information to the registering process, if possible.
I'm not very experienced with Joomla, but since the site in question is already implemented using it, I don't have much choice.
Thanks in advance!
Chronoforms. Most definitely here would be a great use for their AWESOME free component. Your forms can work as registration forms (should you desire that); or can also just be free standing forms that log the information filled out on them to your database which you can later use however you would like (i.e. compiling a mailing list or something of that sort).
The form wizard makes it almost bullet proof, then you can have a form for 1 type of user to fill out, and a form for a different user build different ways.
That will get you the data - in order to mass mail those people you'll need a way to extract their emails out of the database (or find an email component that will let you email based on certain fields in the database or what have you); but it's totally possible and would be easily done I think with 1 simple mySQL query on your database table created by chronoforms.
In terms of something that will solve your issue quickly and get you the info you're looking for in two separate ways - chronoforms will do that exactly.
Is there a simple way I can add a "WikiField" to a model I have in my application?
I think the most important requirements are:
A text field that can be added to any model.
simple wiki markup or editor widget that enables text formatting and easy insertion of links and images.
saves revision history with author information, and easily allows reverting back to any previous version.
Just to explain what I'm trying to do: Imagine you have a bookstore app. Most of the Book model's data come from the store's catalog. Now we would like to add a block of text that is a community wiki, so that users can write the plot summary for example.
How about a combination of django-reversion and django-tinymce, or Markdown if you prefer writing markdown?
I've not come across any field types specifically for Wikis, but with those components writing one really shouldn't take too long.
I have a project with an FAQ app. The app has models for FAQ (written by the site authors) and UserFAQ (written by users-- not just a clever name). I want to return all entries, FAQ or UserFAQ that match certain conditions, but I also want to exclude any UserFAQs that don't match a certain criteria. Ideally, it would looks something like:
faqs = FAQ.objects.filter(question__icontains=search).exclude(show_on_site=False)
Where "show_on_site" is a property that only UserFAQ objects have. That doesn't work because the filter craps out on the parent class as it doesn't posses the property. What's the best way of doing this? I came across this snippet, but it seems like overkill for what I want to do.
In your position, absent a need to have two tables, I'd be tempted to have one FAQ model/table with is_user_faq and show_on_site fields.
Sometimes it helps when modeling data to organize it for simple and fast access. While model inheritance has some appeal, I've found it it's often easier to avoid using it.