Previewing unpublished drafts in Wagtail when frontend relies on headless wagtail API - django

Suppose I have the following setup:
A backend CMS in Wagtail which uses the Wagtail API to expose the data
A frontend that takes aforementioned API and using React, generates HTML & JS
This would break Wagtail's preview as it uses the templates by default. Unfortunately, the preview functionality is important to this particular project, so I need to find a mechanism to keep it.
So far I managed to create a template that outputs a custom-serialized JSON which is read by a specially built front-end.
Unfortunately, this solution is far from ideal as maintaining two serializers - rest_framework and Wagtail's endpoints (with api_fields on the models themselves).
I have not been able to generate JSON from Wagtail's BaseEndpoint (using .as_view or otherwise), but that could be a possible solution.
I've also considered generating an endpoint that serves temporary serialized JSONs for specific pages under unique timed GUIDs. This will technically expose unpublished drafts to the public if anyone gets that (temporary) link somehow, but that is a risk we might be able to take if there was a good way to do it.
How do I approach this problem? Have you solved it for your own project somehow?

Related

Do we need to render templates when using ReactJS as a front-end?

So I just created a website's front-end using ReactJS. Now all I need is a backend database that I will fetch data from using requests.
The question is whether I need to render templates using my backend or just use my server to make requests (eg get, post etc)
PS. I will be using Django as my backend.
Thank you everyone who will help me out.
Doing both is recommended. Based on the requirements and use cases we must use both ways to render.
For example, Some products use initial html as a Server side rendered page with all essential data required inserted as scripts and so on. This helps in loading primary content faster. If we are not following this in applications that require data initially. Then it might take more time to fetch React chunks, scripting and after seeing an API makes request, and then getting data and then displaying the primary content. So when a page needs more data (like More API calls) then server side rendering might be a good way.
For other scenarios like getting user details, All these can be done using React.
No, because you will use DRF (Django Rest Framework) to communicate between frontend and backend. Basically you will write your own APIs in the views.py that will respond with JSON data, at least in major of cases this will be enough. So, you don't need templates, since template are really Djangos' frontend, that you will not be using at all.
But, this heavily depends on what you are doing and what is your setup.

Django model React

I'm trying some Django + React stuff and I'm a bit confused with the particular role of Django model in this scheme.
As I can understand Django model provide smooth way to create some typical forms by users of the site (please correct me). And I can't feel the edge of what should be hardcoded and what I need to store in model.
In case of React (I'm trying to connect react with django through api via djangorestframework) should I create a model for Header? And store bg image with it and my slogans. I feel it's should be purely in frontend. But next section with 3 typical screens (they will be listed horizontally and swap each other). They are just copy of each other with different data (title, bg, fg, text, link), for me it seems closer to model usage. But model initially empty and if I want to get this data from model I firstly need to somehow store this data to model.
So in general my question is what the right cases for using Django models and when it's no needed. And if it possible with applying to my example to better understanding for me )
ofc I searched this info widely but so far can't create clear understanding by myself.
Thanks )
You might actually be in search of a headless CMS.
To combine React and Django and still use a CMS to allow administrating text blocks and images, Django Wagtail's StreamField is a good choice.
https://docs.wagtail.io/en/v2.0/topics/streamfield.html
See for example our company's homepage: https://www.blu-beyond.com. It runs on Django Wagtail, having JS animated text blocks that are administered in the CMS (just jQuery and other JS libs, no React, in this case).
Django Wagtail offers a JSON API, as well, that can be used in React:
https://docs.wagtail.io/en/v2.8/advanced_topics/api/v2/usage.html#fetching-content
It also offers a GraphQL API.

Puzzled on best way to add document management to Django project

I'm creating a django app which needs some document management functionality - users will upload documents, they'll be viewing lists of the documents and selecting them in fairly simple ways (Primarily, they'll be shown a set of documents in specific categories shared by others in their organisation).
Because I want to integrate this with my app, I don't need a very feature rich user interface (in fact, the app or library could be entirely unusable without further coding without that being a problem). It does have to be usable with django.
So - what are some good apps or libraries for django that provide appropriate models and UI elements suitable for integration into a larger app.?
I've looked at the django packages page, and none of the items on there are, as far as I can, see especially suitable. In particular, Mayan does not appear to have been created with integration in mind.
I haven't personally used these apps, but Django Packages is always a good starting place. Have you looked at under Document Management?
Mayan (rtd, github, homepage) looks to be actively maintained and pretty mature.
The other two listed are django-treenav and django-file-picker, though they do not seem to be as robust or as actively maintained, but they may be a good fit given your basic needs.
Of course if your needs are simple it may be just as easy to implement it yourself, django model's FileField is straightforward to use and they have great documentation on how to handle file uploads from forms - https://docs.djangoproject.com/en/dev/topics/http/file-uploads/.

How to integrate multiple image uploading with UPLOADIFY in django administration?

I met the django-uploadify (multiple file uploading) application, but the only template-use is described in wiki of the project. I need to integrate it with django admin. Any ideas?
#rebus and #Mordi have good suggestions; one of those is probably your best bet. Still...
The current implementation of file uploads in web browsers is single file only. That's a limitation of the HTML standards and the browsers themselves. When you see multiple file upload capability (all at once / select multiple) in some web app, something like Flash or Java is in play. You could potentially use a Flash or Java applet (check out Uploadify - about the easiest to work with you'll find), if you wanted, but you'd have to do some work tying it into Django: namely mapping the output of the applet to the input the Django Admin expects on POST.
Personally I found this package to be painful when I attempted to do this locally. It is 7 years old and not maintained. django-filer is a more modern implementation that has this exact functionality built into the admin panel, it was quick to set up and it seems to be maintained a lot better. And the UI is excellent!
If your really set on using uploadify my attempt was quite painful. When I went to the website to download the uploadify jQuery plugin it was a paid download. After looking a bit I found a fork, and was able to get it going locally, but because the python package is old it required a lot of changes from python 2.7..
To integrate this with your project in the admin will definitely require you to write your own custom admin template. In your admin.py you would have to override the default template and methods, this faq has some insights. In your new template you would include the uploadify jquery script and put the upload file field inside the form where your model fields would be. When you upload files the signal sender in the package will fire, and you would just have to intercept the signal and handle it with your intended logic
Very easy to implement multiple image upload with this project:
https://github.com/tstone/django-uploadify

CodeIgniter & Datamapper as frontend, Django Admin as backend, database tables inconsistent

I created a database for a site i'm doing using Django as the admin backend. However because the server where the site is hosted on, won't be able to support Python, I find myself needing to do the front end in PHP and as such i've decided to use CodeIgniter along with Datamapper to map the models/relationship.
However DataMapper requires the tables to be in a specific format for it to work, and Django maps its tables differently, using the App name as the prefix in the table. I've tried using the prefix & join_prefix vars in datamapper but still doesn't map them correctly.
Has anyone used a combination of this? and if so how have the fixed the issue of db table names being inconsistent? Is there anything out there that i can use to make them work together?
----edit: clarification on backend---
Let me clarify: i'm going to be running the admin from a subdomain pointing to a python ready server. However i can't move the main domain name from the php only webserver because of certain constraints/binding contracts the company got itself in. and don't want to use cloaking/masking because of seo purposes.
i'm using the django admin because i'm using some packages to make a pretty/functional admin, such as grappelli for the admin template, along with its editor for editing news stories, etc. also using photologue to manage photos/galleries. etc.
If your problem is simply making Django use the same tables as your other software, use the db_column and db_table parameters in the models.
http://www.djangoproject.com/documentation/models/custom_columns/
Two apparent solutions:
Instead of hacking one or both to work well with each other, emulate the Django admin in PHP/CodeIgniter code. **
Get a server that supports Django. Make the frontend in Django.
Time-wise, either one of those solutions will be less involving than trying to make two different frameworks using different programming languages mesh well together. I can't imagine the future maintenance required to ensure everlasting compatibility and interoperability.
Also, I assume by saying:
I created a database for a site i'm doing using Django as the admin backend
You really mean that you modeled your apps using Django, and that you also intend on administrating the database that has resulted from this modeling in the Django admin. (In which case you already have your Models layer complete and should just try building the rest of the site in Django)
If that's the case then in your models you are going to need to define the exact column names (db_column) that DataMapper will expect, as well as manually define the table names (db_table), including M2M tables.
You may also have to define all of your primary keys manually, if DM expects something named differently.
Also:
If the server can't support Python, where are you going to be running your backend? Different server? Locally? This plan just isn't making a lot of sense.
** I would not suggest trying this. I had been attempting to make a CI backend that actually shared much of the same ideas as Django's admin, before I knew about Django's admin. And of course once discovering Django, I dropped the CI work immediately and continued on with what I have found to be a much more amazing framework that is much faster to develop on.
So as I understand you plan on using Django just because of django-admin, and you are trying to use CI for the actual site because the server runs PHP, right?
So why don't you use framework that generates something like Django's admin but that you can run on your server?
The Symfony Framework has a really nice admin generator, in the spirit of Django's and you might be able to run it on your server. This would save you from the maintainance nightmare that might come later as #jonwd7 answered