TinyMCE stripping anchor tags within or around DIVs

Description of issue or problem I’m having:
I am pasting in some HTML content to be displayed on the home page, however the TinyMCE editor is stripping out all anchor tags from my code. The code is valid HTML and should result in a clickable div (once the div is made display:block;)

Steps I took leading up to the issue:
Pasted in the following code to display a grid of clickable divs:

<div class="d-flex flex-wrap justify-content-evenly pt-3 pb-3">
    <a href="/clinical-queries"><div class="clin-query icon-dog"></div></a>
    <a href="/clinical-queries"><div class="clin-query icon-horse"></div></a>
    <a href="/clinical-queries"><div class="clin-query icon-bird"></div></a>
    <a href="/clinical-queries"><div class="clin-query icon-horse"></div></a>
    <a href="/clinical-queries"><div class="clin-query icon-speech"></div></a>

What I tried to resolve the issue:
I have looked on the forums for something specific to this but cannot find anything helpful.

Application Version - e.g., OJS 3.1.2:

Additional information, such as screenshots and error log messages if applicable:
It doesn’t seem to matter whether I put the anchor tags around or within the DIV, they will always be stripped on saving.

Is this a config issue with TinyMCE?

Hi @Ant_Forshaw,

TinyMCE strips out most tags that wouldn’t be used as part of the options that are part of TinyMCE. You can see an explanation of this here: Adding images to announcements in OJS 3.3 - Tiny MCE - #4 by rcgillis

Did you try the config.inc.php option that you used with the announcements: Announcement Images with custom size not being scaled on frontend- TinyMCE - #4 by Ant_Forshaw

PKP Team

Hi Roger,

Thanks for getting back to me. I have amended the line in config.inc.php to read:

allowed_html = "div[id|class|onclick],a[href|target|title],em,strong,cite,code,ul,ol,li[class],dl,dt,dd,b,i,u,img[src|alt|width|height],sup,sub,br,p"

The onclick event is being stripped out by the editor also. (I only put it in there because the anchor tags are being stripped out completely so I was trying a different approach).

All I’m attempting to do is to allow the site admin to paste in some additional content to be shown on the home page. The content basically just includes links to another section of the site.

Is there any way to allow anchor tags to be pasted into the editor without being stripped?

It appears that my alternative approach would be to hard-code this content into the templates, thereby bringing it out of the site admin’s control, but that’s not something I [ever] want to do.

Hi @Ant_Forshaw,

So despite having them in the allowed_html its still stripping them out?


It’s not stripping out all anchor tags, just those with DIV tags within, or around the anchor tags (I wanted to make a grid of clickable divs). Could it be the list of valid children that’s setup in the TinyMCE core javascript ?

Obviously I don’t feel right in modifying the TinyMCE core, but if there is a way to configure the editor via the call from OJS then that would be preferable.

		$this->addOption('clinicalQueries', 'FieldRichTextarea', [
			'tooltip' => __('plugins.themes.rcvsk.option.clinicalQueries.description'),
			'isMultilingual' => false,
			'value' => $context->getData('clinicalQueries'),
			'baseUrl' => $baseUrl,
				'options' => [
					'url' => $temporaryFileApiUrl,
			'toolbar' => 'bold italic superscript subscript | link | blockquote bullist numlist | image | code',
			'plugins' => 'paste,link,lists,image,code,anchor',
			'uploadUrl' => $temporaryFileApiUrl,
			'label' => __('plugins.themes.rcvsk.option.clinicalQueries.label'),
			'default' => '',

Are you aware of any startup options I can add to this addOption definition?

Hi @Ant_Forshaw,

Thanks for clarifying. I’m not familiar enough with the code to be able to answer these questions, but I’ll see if I can get a member of our dev team to weigh in when they’re available. I think it would be inadvisable, as you note, to modify the code, as new changes that are introduced in new versions of OJS as you upgrade, could override them (that’s generally the risk with a lot of customizations) - so it can lead to headaches down the road.


Hi @rcgillis , thanks for your reply.

Just a quick follow-up on this one to see if anyone there has any ideas how to allow certain nested tags within the TinyMCE editor. Our current live site, which is based on OJS 3.1.2, currently uses a text field to incorporate some HTML on the home page. The editor on OJS 3.1.2 doesn’t strip the tags, and this enables our users to periodically update the content of the home page with HTML code.

Now that OJS 3.3 strips out the tags this will cause this operation of the live site to fail and corrupt the display, so unless I can find a way to allow HTML tags in the editor then I won’t be able to upgrade our live site unless I can come up with another [easy] way to allow HTML to be displayed on the home page via the settings form in the backend. There has to be a way right? :slight_smile:

I appreciate any help I can get on this one because I’m kind of stumped here. If I edit the TinyMCE core code then I’ll be version-locking our site which is something I don’t want to do.

Many thanks in advance,


In HTML4, anchor tags could only contain inline tags. In HTML5 anchor tags can contain both inline and block tags. It is likely that HTMLPurifier is enforcing HTML4 rules on the data.

@ctgraham Do you know if there is a way to configure the TinyMCE editor to allow the nested tags? Our site can’t be the only one using the text fields in this manner surely :slight_smile: (perhaps it is!)

I can always just hard-code the content of the home page into the .tpl file but it’s not optimal for our use case. Having the admins be able to make minor changes to the content themselves means a developer doesn’t have to intervene each time.

I’m not aware of a way to configure this without a code change.

The code which is enforcing HTML4 rules appears to be here:

HTMLPurifier does not appear to support HTML5 as a DOCTYPE:
and it doesn’t appear that the project intends to support HTML5:

Another add-in library might provide a solution:

All of the potential solutions and workarounds will require development time, however, either by the PKP team or by a community contributor.

Very useful information, thank you @ctgraham

I don’t have the OJS skills at this time, having just started to use it, however this HTML5 purifier would be of immense usefulness in my case as we commonly paste HTML code into the backend for display on the frontend.

I appreciate the importance of stripping certain HTML tags from fields that public-facing people can create, but I do believe the ability to choose which fields have the HTML stripped from them would be very useful. The alternative is to hard-code the HTML content into the templates themselves which isn’t ideal.

I’ll see if I can think of a way to get this to work for my case but I’m sure it will involve editing the core software so wouldn’t constitute a permanent solution.

Thanks again,


Hi @ctgraham , just looking at the things being stripped out, I don’t think having

tags within should be considered unsafe as nowadays it’s considered valid HTML isn’t it? Is there a way to allow these nested tags? Any onclick, other javascript can be stripped as normal, but the nested tags would allow me to continue.

(Related: I’ve filed to replace HTMLPurifier with a maintained dependency. See Replace HTMLPurifier with a maintained dependency · Issue #7916 · pkp/pkp-lib · GitHub for details. -Alec)

Is there a way to allow these nested tags?

Pending implementation of the issue which Alec just filed, the only trivial workarounds would be to disable htmlpurifier entirely (which introduces XSS risks) or to hardcode the HTML into the templates (which introduces maintenance headaches).

Thank you @ctgraham and @asmecher - this looks like it will be very useful.

I agree it’s a maintenance headache to hardcode the HTML in the templates but as a temporary workaround (until the new purifier is available) I think I can live with that.

Many thanks for your time and help on this one, and I look forward to seeing the new solution :slight_smile: (I subscribed to the GitHub thread - thanks for the link)