Repeated HTMLPurifier warnings during installation profile update

kingjulien

Hello everyone,

I am encountering a recurring issue while running installation profile updates in Providence (Ubuntu 24.04, CA 2.0.x).

During the update process I repeatedly get the following warning:

PHP Warning: Base directory /var/www/ca/providence_new/app/tmp/purifier does not exist,
please create or change using %Cache.SerializerPath

I investigated the configuration and found in app/conf/app.conf:

purify_serializer_path = <ca_temp_dir>/purifier

What seems to happen is that during update-installation-profile, the app/tmp structure is temporarily recreated or cleaned, causing the purifier directory to disappear.

Interesting detail:

if I manually run:

mkdir -p app/tmp/purifier

from another terminal while the update is running, the warnings immediately stop and the update completes successfully.

Permissions are correct (www-data:www-data, 775).

So my question is:

is this expected behaviour?
should purifier be automatically recreated by CA/HTMLPurifier?
would it be preferable to move ca_temp_dir outside app/tmp in production environments?

Thank you very much for any clarification.

monica

kingjulien This is something my team are responsible for, moving the purifier temp files out of the vendor directory and into the CA temp directory. We did this so the vendor directory didn’t need to be writable by the web server (not ideal). We thought we fixed this issue of the purifier being removed when cache is cleared by recreating it inside the clear cache command. It sounds like whatever update install profile is doing, it’s not using the clear cache command. We will look into it for you, but in the meantime you can set that purifier directory to something else.

kingjulien

hanks, Monica, that makes perfect sense. I’ll set the purifier directory elsewhere for now.

And sorry for the slight off-topic question, but is there a specific part of the team responsible for GraphQL development?
As part of a development contract we’ve been working extensively with the GraphQL API (see my other intervention few days ago) and have spent several weeks documenting the bundles returned by different queries and configurations. The resulting guide might be useful to other developers, and I’d be happy to share it with the community if there is interest.

We are still struggling with some Information Services, however, particularly Wikidata. At the moment we haven’t found a clean workaround other than copying the values into “shadow” fields that are supported by GraphQL and querying those instead (not very elegant). I’m wondering whether this is a known limitation or if there are plans to improve support for Information Service values in the GraphQL layer.

Thanks again for looking into the purifier issue.

monica

kingjulien Hi. I have submitted a pull request that should fix this issue: https://github.com/collectiveaccess/providence/pull/1927

As for your questions about the team responsible for 'GraphQL'. What I meant when I said my team was responsible for your issue, is that we are the ones that created it. My team are a different company to Whirl-i-Gig, called Medeopolis IT. Whirl-i-Gig are the maintainers of CollectiveAccess, while my team are contributors, we contribute updates to CollectiveAccess through Pull Requests that are either accepted or not by the Maintainer. We have our own clients who we support with CollectiveAccess 🙂

That all said, I believe that if you have documentation about the GraphQL API that others will find useful, you can help by contributing to the documentation at https://github.com/collectiveaccess/CollectiveAccessManual this is the repository for the content at https://docs.collectiveaccess.org/

Cheers!
Monica