Skip to content

Latest commit

 

History

History
205 lines (129 loc) · 9.5 KB

FINDINGS.adoc

File metadata and controls

205 lines (129 loc) · 9.5 KB
Raw

Findings

Table of Contents

Editor

  • Bootstrapped with sample data/model

  • Renamed article to Drievoor12update

  • Added and removed some fields

  • The id field will contain the original id (in magnolia, in elasticsearch and in the api)

Prepr API

Just put the key in .env, it can be picked up by astro and the python scripts.

This repo is a for of the astro-demo from prepr. We will just play a bit with it.

Astro example

  • install yarn and pnpm using brew, then follow the steps in README.md

npm run dev

At first, I find astro it a bit hard to understand, and mainly I don’t know how to debug it. In my efforts I broke it and seemingly can’t fixt it. So that may be just me.

(deployed via https://git.vpro.nl/vrije-ruimte/michiel/prepr-poc/ (accessible @vpro only))

Flask example

Also tried a flask frontend, since I’m a bit more familiar with that, and more readily knew how to debug it.

Uses the virtualenvironment described in [_data_migration]

cd flask
flask$ flask --debug run
 * Debug mode: on
2023-06-20 21:14:41,473 INFO WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
 * Running on http://127.0.0.1:5000
2023-06-20 21:14:41,473 INFO Press CTRL+C to quit
2023-06-20 21:14:41,474 INFO  * Restarting with stat
2023-06-20 21:14:41,597 WARNING  * Debugger is active!
2023-06-20 21:14:41,603 INFO  * Debugger PIN: 711-940-217

Model

No idea of the model allows for enough features. E.g. I tried to add a UUID field, to store the original UUID in magnolia. I think I could only try to validate it with regex pattern?

In this case it would perhaps make sense to just reused the id, UUID are unique, aren’t they? I haven’t figured out how to do that yet. - Simple posting to content_images/<my uuid> gives 404. → Isn’t possible right now (though Tim suggest that it might be possible to improve that)

I have no idea if we could supply custom field types, e.g. integration for the POMS CMSSelector, for the Thesaurus, for Proof of Provenance fields.

security

For 3voor12 we also have users which may only edit a subset of the content.

The contained link to the documentation is broken, but I found https://docs.prepr.io/account/roles-and-permissions/ (btw, if they used prepr to make their own website, we might conclude that cross links are fragile!)

According to documentation we should be able to manage roles: 'User roles can be managed by all users who have the Organization permission of Roles. To manage user roles, click the environment dropdown at the top right, choose your organization and click to open the environments overview, then go to User management > Roles. Here you can see a list of all roles in your organization. '

I might be overlooking it or lacking permissions, but I can’t find it.

→ Yes, it had to do with that.

I’ve seen it now, it seems to offer rights per content model/locale. I think that for 3voor12 updates this would e.g. mean that different lokaal-temas would have their own copy of the content model?

We like to have integration with keycloak, which may not be possible, but I think there is an integration with azure: https://docs.prepr.io/account/sso , which also might fit our needs.

tree structure

In magnolia the updates are actually stored in a tree, also because of the mentioned authorization issue. I think in prepr content is not in any tree, but just a flat list. This might be preferable by the way. I suppose we could use collections to have a similar division structure. (3 voor 12 Utrecht, 3voor 12 Amsterdam, etc)

Images

I haven’t tried images yet. I think we feel that it would be nice if images could be stored outside the CMS itself. But see the previous point, in that case some GUI plugin must be possible to arrange the integration.

Model in code

It should be possible to maintain the model in code. It is at least possible to export it. According to Tim I should be possible to import it too. I didn’t succeed in making a change and updating it, but I didn’t try very hard.

Also model (and problably everything alse) are referred to by UUID, which may be needed here and there. E.g. when using the backend api. UUID’s are hard to remember and to read, and there is the risc that they change when rebuilding the model somewhere else, making it necessary to maintain mappings from uuids to names. Perhaps this can be remedied, or perhaps it is not a problem in practice.

Custom gui

This https://docs.prepr.io/create-schema/remote-content-source may facilate a few of the things we may need.

'Upgrade om meer remote sources toe te voegen 1 remote sources zijn toegestaan in het community plan. Upgrade naar Entry, Scale or Enterprise om er meer toe te voegen.'

→ Ze bedoelen: 'er is maar 1 remote source toegestaan'. Ik was in war door de onduidelijke grammatica. Heb de example webshop verwijderd, en toen kon ik er inderdaad eentje maken. Ging nog van alles aan fout. Api raakt kapot door inconsistent data die daardoor onstond. Ze moesten handmatig caches clearen, anders kon ik het helemaal niet verwijderen. (ik had de componenten die het gebruikte verwijderd, maar hij bleef zeggen dat ik de remote source niet mocht verwijderen om dat er nog componenten waren die het gebruikten)

  • Is het ook mogelijk om een externe DAM te gebruiken? -→ Ze schrijven van wel.

field types

Wordt gesproken of een 'comprehensive list', dus ik vermoed dat het niet voor de hand ligt om er iets aan te customizen. → Ze hebben gezegd dat het inderdaad niet kan. Maar dat ze natuurlijk eventueel wel kunnen overwegen om het toe te voegen.

remote source

Dat zijn blijkbaar de opties. Je moet een api aanbieden die precies doet hoe het daar is gespecificeerd. Aangezien de EO prepr gebruikt dacht ik dat misschien https://pomslookup.eo.nl/ zou kunnen volstaan, maar dat is niet zo, dat is domweg een bakje javascript dat rechstreeks met de NPO frontend api praat.

Issues & Remarks

  • Het was mogelijk om een artikel te maken zonder content, artikel pagina gaf foutmelding. Validatie-issue/frontend-issue?

  • De titel zag er eerst raar uit:

    raar karakter Kon domweg gefixt worden in de redactieomgeving, want daar had ik blijkbaar een onzichbare whitespace gemaakt. Maar raar dat dat zo makkelijk gebeurt.

  • Ik weet niet wat ik er van vind dat alles is geprefixt met locales.

  • Debuggen kan ook via de gui bij de access token. Daar kun je zien wat je recent fout deed.

  • Ik had mgnl_uuid veld per ongeluk een maximale lengte gegeven. Dat later niet nodig gevonden, en weer verwijderd, maar hij blijft fouten geven over body.length.max. Caching? Defaults?

  • LInk https://docs.prepr.io/reference/rest/v1/fetching-working-with-fields naar graphql is broken

  • Queries lijkt niet per se goed te werken. Je kunt queryen op slug: https://docs.prepr.io/reference/rest/v1/fetching-single-items, maar hoe ik dan op een andere veld zou moeten queryen, is mij niet duidelijk. slug vervangen door mgnl_uuid lijkt domweg te worden genegeerd (geen validatie op query parameters natuurlijk) → zie 3voor12-updates.py voor hoe het wel gaat.

  • Er is een tool om graphql queries samen te stellen, maar die ben ik steeds kwijt.

Data migration

As a test, and to have some data to play with, I migrated the latest 3voor12 updates to prepr.

python

mihxil@baleno:~$ python3 -m venv ~/venvs/vpro-migrate
mihxil@baleno:~$ source ~/venvs/vpro-migrate/bin/activate

pip3 install elasticsearch python-dotenv requests

Tunnel ES:

ssh -L9210:localhost:9200 os2-api-prod-01

Run the script.

  • This will the latest (published) 3voor12 updates to prepr

    • this may not be correct, because we may also want to migrate unpublished updates

  • slugs are not filled, for some reason

    • we don’t use slugs in the current setup (using the api), but just refer to by uuid. For seo we just put the title in the url? -

Interesting extra features

  • kanban board

  • debug-tools

  • a/b testing

  • ..

Conclusion?

  • Prepr seems to be a straighforward headless CMS. With a graphql api. I could quite easily migrate some existing content and make two different frontends with it.

  • It has some interesting features

    • like a log of executed queries per access token

    • like webhook call backs

    • like a / b -testing (not tried)

    • personalization (not tried)

    • workflow and embargos

    • 'kanban’view on workflow

    • ..

  • It may be somewhat fragile, I encountered several issues, which may be partially caused by my unwieldy behaviour (as I was trying things out), so I can’t say for sure that this would be common in practice.

  • There is also a backend api which can be used to post json to create or modify content. E.g. for migration purposes.

  • We would have little influence on details of the gui, but otherwise complete freedom on how to structure the data. It has a bunch of field types, which can be grouped into components, and we could have 'remote sources', wich may be useful for some use cases.

  • I think there is integration with azure (I even encountered bnnvara and eo links in radio prepr)