artshumrc / giza

JSON API (for TMS Database) and Django 2 application for Digital Giza
http://giza.fas.harvard.edu/
7 stars 5 forks source link

Allow Admin users to edit text content which will change frequently #93

Open ColeDCrawford opened 3 years ago

ColeDCrawford commented 3 years ago

Using flatpages or something similar. Example pages:

npicardo commented 3 years ago

In order of importance (in case all make for too large a lift):

  1. "About the Giza Project"
  2. Giza@School landing page > "More Resources" panel.
  3. "Glossary and FAQ"
  4. "People and Places of Giza"
lukehollis commented 3 years ago

Hi @ColeDCrawford and @rsinghal, I'd prefer to integrate an existing CMS package such as Wagtail to give @npicardo stable editing capabilities. What solution for editing these pages would you like implemented?

ColeDCrawford commented 3 years ago

Out of the above items - I think 1, 3, and 4 could be handled fine with Django's flatpages app. That's going to be faster to integrate, though Nick or an editor would need to write HTML rather than using a WYSIWYG editor (unless you add tinymce as middleware eg https://github.com/mjr27/django-flatpages-tinymce).

For (2), I think any side panels would then need to be moved to a separate field which would capture an array of items - not sure if Wagtail could handle that, but at the least it is more complex than the rest.

We're using Wagtail for other apps, but as you said in your email, adding Wagtail would be a large shift (and a fairly time consuming one). It seems a little finicky to set up sometimes, and then you also add the complexity of deploying, configuring, maintaining, and using a second admin interface. I think @rsinghal added Wagtail to this a long time ago and removed it for those and other reasons. I do not think it is plausible to both add Wagtail and complete the other priority items within a week.

ColeDCrawford commented 3 years ago

Talked over this with Rashmi a bit, and she agrees that adding Wagtail without a decent amount of time for setup and testing would be a fast way to break things. I'm more optimistic about flatpages: one admin interface, better integration. Would need to install that app and then lift and shift templates over. It looks like all of the static pages are using the tms_views.about and tms_views.explore views: https://github.com/rsinghal/giza/blob/c6537f77f69acfb62b9b3273db025f8b15da3642/giza/urls.py#L26-L30

These are using static_pages(): https://github.com/rsinghal/giza/blob/c6537f77f69acfb62b9b3273db025f8b15da3642/tms/views.py#L42-L56

Which serves up content from here: https://github.com/rsinghal/giza/tree/software-update-pixel-iiif/templates/pages

So all of those pages would need to be shifted into the flatpages app as templates. There could be some template consolidation, but I'm not sure how much; the main body content and sidebar look like they're just static HTML but some variables are being injected at the top of the templates. Could hook into the flatpages model so these can be set in the admin interface, or have more templates.

If you think Wagtail is still the way to go I would recommend waiting on implementing this until other features are complete, since I think it will end up taking quite a while and not deliver any visible results for NEH, and doing all of the Wagtail dev in a separate branch (smaller PRs in general would be good).