CentreForDigitalHumanities / CentreForDigitalHumanities/Textcavator
Embedding Textcavator without a separate server
- Dominant language
- Python
- Stars
- 12
- Forks
- 3
- Avg merge
- 3d 3m
- Merged PRs (30d)
- 9
Description
PEACE portal uses an iframe to display the Textcavator search interface for a corpus in a wordpress site. To do this, we run a separate server just for PEACE portal, which is configured differently for the sake of embedding.
The setup works, but running a separate server increases the maintenance cost. We're currently looking into using a similar setup for another project, and I would like to avoid making yet another Textcavator server. (See also #1955)
For context, PEACE portal originally used a different server and a forked source repository to enable some more fundamental changes, such as not requiring login. At the moment, the differences between PEACE portal and our main server are largely superficial, so it seems doable to run all this from a single server - either here or in similar cases in the future.
There are two approaches to integrate the servers:
1. Make the PEACE portal corpus a public corpus on our main server, and use that URL for the iframe on the wordpress site. The corpus would also be visible when you visit the Textcavator site, which may be a positive or a negative.
2. Use the Sites framework (#1955) and keep providing a separate domain for PEACE portal. This would allow us to exclude the corpus from our main site. Might also make it easier to use separate settings for this project, but this may not be necessary.
I'm trying to get an overview of what is different between the servers, but I did not work on this project. Here is what I can list:
- Visibility of the PEACE portal corpus. See above.
- Request headers: [X-FRAME-OPTIONS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Frame-Options) / [CSP](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy). Our default setting does not allow iframe embedding. (I don't know the exact configuration on peace portal.)
- The header and footer are hidden based on an environment setting. This could also be controlled with a query parameter or with [window.parent](https://developer.mozilla.org/en-US/docs/Web/API/Window/parent).
- Direct download limits are higher on PEACE portal, to benefit users without an account. Possible solutions:
- With approach 1: [Set download limits per corpus](https://github.com/CentreForDigitalHumanities/Textcavator/discussions/1437)
- With approach 1: add the instruction to go to textcavator (and create an account there) for big downloads.
- With approach 2: set download limits per site.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by comparing the PEACE portal server with the main server, focusing on the differences listed in the issue: corpus visibility, iframe-related headers, header and footer visibility, and download limits. Review #1955 and the two proposed integration approaches. Done means one server can support the PEACE portal setup without requiring another separately maintained Textcavator server.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend, web-dev
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100