HTMLPurifier defaults

peterjanssens

Currently the HTMLPurifiers stick to the package defaults, and there does not seem to be a configurable for this yet (other than enable/disable purification).
Do you have other ways (including plain hacks) of specific purification in place ?
Would a separate config file be an option to configure some ? (I can imagine you can have many use-cases for purification up to the field level - there is only room for <marquee> to certain fields).
On the other hand: the extend of configuration can be huge (as listed here https://workstead.com/assets/repos/moxycart/vendor/ezyang/htmlpurifier/configdoc/plain.html), so that can feel like opening a wasp's nest :/

monica

peterjanssens Is there anything in particular you were hoping to set in HTMLPurifier?
I have a pending pull request waiting that adds support for HTML5 elements https://github.com/collectiveaccess/providence/pull/1869

peterjanssens

monica #s
We currently have a use-case where the author maintains a snippet of transcription with internal links (href="#some-id"), and the target ids are purified by ezyang's default effectively destroying the target elements,
<span id="some-id">.. becomes <span>.. and cannot be targetted.

Also removes some other tags like <section>..

monica

peterjanssens The HTML5 should help with <section> tag. But for the ID you need to turn on $config->set('Attr.EnableID', true); in UtilityHelpers.php.
I've been working on and off on improving the CKEditor within my own repository and needed to turn this on to enable the use of bookmark/anchors in the editor. I've not touched it for a couple of months and cant remember if I left it in a functioning state or not: https://github.com/medeopolis/providence/tree/ckeditor_enhancements
A word of warning! This is editing the core code and there is no guarantee this sort of change will even be accepted upstream. If you make these changes, you may need to maintain this yourself.

peterjanssens

monica

That's indeed the issue(s): there are a few places where the HTMLPurifier creates an instance, there are many many options to the purifier config, and any or all of these can be suitable to certain specific fields only. Clean implementation would open the rabbit hole.

$config = HTMLPurifier_Config::createDefault();
$config->set('Attr.EnableID', true);
$config->set('HTML.Allowed', 'p,sup[id],a[href|id],section[class],ol,li');
$purifier = new HTMLPurifier($config);

could handle this case, but other fields could use other configs.

We try indeed to do minimal changes to core. Main question at this moment was that we might overlook configuration options, and we got that question answered thanks! Complete (clean) implementation might be quit the task for edge-case scenarios.

peterjanssens

because even with purify_all_text_input=0, purification is still done on this field (probably since that purification config can be overriden by the 'purify' option or the 'PURIFY' fieldinfo on BaseModel https://github.com/collectiveaccess/providence/blob/1bcaca9ea5ad2e1016e4a6b9c694592b49aca280/app/lib/BaseModel.php#L1746, can't immediately find that fieldinfo)

monica

peterjanssens If that is set, then it shouldn't be running the content through purifier. If you are using a rich text editor, then whatever markup is put into that has to be supported by the editor (ckeditor or quilljs), otherwise the editor just ignores it. If it's a plain text field with html in it, then it should just be as is entered.

peterjanssens

that was indeed our first (and easiest) goto (plain text + purify_all_text_input=0) but even there purification went true.

I threw a few dumps at the above (option config fieldinfo) and apparently the problem starts much earlier

$this->_CONFIG->get("purify_all_text_input") is NULL so whatever the config says ends in the fallback true.

$this->opb_purify_input = strlen($this->CONFIG->get("purify_all_text_input")) ? (bool)$this->CONFIG->get("purify_all_text_input") : true;

peterjanssens

when dumping the entire $this->_CONFIG purify_all_text_input is one of the available scalars effectively set to 0
so the get doesn't seem to be getting

peterjanssens

$this->_CONFIG->getScalar("purify_all_text_input") does return 0, get() return NULL

peterjanssens

I think the problem lies here
https://github.com/collectiveaccess/providence/blob/e9dd1460dc274b16277390b5e717631cf624f024/app/lib/Configuration.php#L838

in the get(key) the 0 of purify_all_text kicks it out (!0) instead of returning, no ?