1152061 - Blog users can no longer post unfiltered HTML after WPEngine migration

Status: RESOLVED WONTFIX

(Infrastructure & Operations Graveyard :: WebOps: Other, task)

Description

[Craig Cook (:craigcook)]

As of WordPress 3.1, unfiltered HTML is explicitly forbidden in multisite installations for all users below superadmin level.

This has only presented itself as a problem after migrating to WPEngine. Previously, on our own hosting, regular admins and some special custom roles were able to post unfiltered HTML. There might have been something in our particular multisite configuration that allowed it but I haven't yet found any clear documentation on how to do this.

This issue became evident because the Hacks blog uses a plugin called WP-Syntax for code syntax highlighting. The plugin parses markup in the post when it's rendered and injects a bunch of extra styling, but the original post only stores a <pre> element with some attributes that the plugin looks for. Without the ability to post unfiltered HTML, those attributes are being stripped and the syntax highlighting is lost.

We could possibly escalate this to WPEngine and see if they can alter permissions for us, but I think the best long term solution is to find another syntax highlighting plugin that doesn't require unfiltered HTML (WP-Syntax is really outdated and not actively maintained so we can't expect any updates).

Comment 1

[havi hoffman [:havi]]

This is currently 100% blocking my ability to publish previously scheduled posts for tomorrow Thursday, and early next week, which all rely on a syntax highlighter. Thanks Craig for investigating. Happy to replace the highlighter. Could we escalate the priority of this? 

(added jweathersby to cc:)

Comment 2

[Craig Cook (:craigcook)]

(In reply to havi hoffman [:havi] from comment #1)
> This is currently 100% blocking my ability to publish previously scheduled
> posts for tomorrow Thursday, and early next week, which all rely on a syntax
> highlighter. Thanks Craig for investigating. Happy to replace the
> highlighter. Could we escalate the priority of this? 

The immediate workaround is for me to publish them on your behalf since I'm a superadmin. You can do all the editing right up to the last minute, then just let me know when it's ready and I'll add the syntax stuff and hit the button. Meanwhile I'll start looking at other plugins.

Comment 3

[Shyam Mani [:fox2mike]]

(In reply to havi hoffman [:havi] from comment #1)
> This is currently 100% blocking my ability to publish previously scheduled
> posts for tomorrow Thursday, and early next week, which all rely on a syntax
> highlighter. Thanks Craig for investigating. Happy to replace the
> highlighter. Could we escalate the priority of this? 

Hi Havi,

Sorry you're running into this issue. Sean has contacted WPEngine and we'll work with them on this to help you out.

Comment 4

[havi hoffman [:havi]]

Hi, Thanks Shyam. Looking for an update on this since Tues.

Right now I am unable to publish or edit recent posts or posts in the queue scheduled for next week because of the disappearing code syntax formatting. 

I would like to have this resolved for publishing next week since this is currently stealing time from my other responsibilities. Can we add an alternate plug in solution as Craig has suggested? What do you propose to resolve? TIA for a timely reply.

Comment 5

[Craig Cook (:craigcook)]

From what looking I've done so far, https://wordpress.org/plugins/syntaxhighlighter/ seems like a potential winner. I want to test it a little more before we commit to it fully.

I still don't know what the new process is for adding/updating plugins on our WPEngine hosted platform. In the past some plugins were defined as SVN externals, or else we pushed code directly from SVN or git, but I don't know if that still applies now. It looks like it might be good old fashioned SFTP?

Comment 6

[Sean Rich [:srich]]

Havi/Craig - are you moving down the "publish as superadmin" (for now) path?  WPEngine doesn't allow unfiltered html for security reasons.  Craig, I can help with the "how to install plugins" question.  I'm currently pulling together training and onboarding information.  In the meantime, their support garage has a bunch of (potentially) useful information: http://wpengine.com/support/.

Clarifying question - does this mean that formatting is lost for any historical posts with html syntax highlights?  Will you point me to a few examples if so? I'm wondering how many we need to go back and correct once the new plug-in is installed.

Final note - syntaxhighlighter is not on the disallowed list, so you should be good there.  http://wpengine.com/support/disallowed-plugins/

Comment 7

[havi hoffman [:havi]]

Formatting in historical published posts is not lost AFAICT. Formatting in a variety of drafts was lost - and I'm currently stymied daily by being unable to edit/re-edit any existing post that has syntax formatting -- also, it puts technical reviewers in a precarious position -- "publish as super-admin" is not a tenable position given my dedicated role as editor and the fact that this is an active multi-author blog. 

Could we move forward with installing a syntax formatting plugin for next week? 

Also, (while I have your attn): what is now the process for adding new local users? I want to wait till we've resolved the syntax issue, but I have new authors on the calendar for next week and after. Thanks!

Comment 8

[Craig Cook (:craigcook)]

(In reply to Sean Rich [:srich] from comment #6)
> Havi/Craig - are you moving down the "publish as superadmin" (for now) path?

Correct, that's the current workaround until we get a new plugin.

> Clarifying question - does this mean that formatting is lost for any
> historical posts with html syntax highlights?  Will you point me to a few
> examples if so? I'm wondering how many we need to go back and correct once
> the new plug-in is installed.

WordPress strips unsafe HTML at the moment a post is saved. Older posts are already saved with their HTML intact so WP-Syntax still works on them as long as nobody edits and re-saves them. So we shouldn't need to update old posts. 

However, it does mean we'll have to keep WP-Syntax installed to continue styling code on those old posts. Removing the plugin means they fall back to a plain <pre> element, which is still readable code just without the fancy highlighting. That might be acceptable for really old content and we could update just the most recent and most popular posts for the new plugin.

Comment 9

[havi hoffman [:havi]]

Checking in on status of the new plugin solution for the Mozilla Hacks blog. 

I am unable to perform my role as Hacks blog editor without a solution in place. Asking someone else to hit publish for me is not viable. I need access to save and resave, publish and republish new and upcoming posts on an ongoing basis. It's the web!  

TIA for a timely solution that restores my ability to publish this blog.

Comment 10

[Craig Cook (:craigcook)]

We've installed a new plugin, WP Code Highlightjs (https://wordpress.org/plugins/wp-code-highlightjs/). This solves the immediate problem of publishing code examples on Hacks, and I've also activated the plugin for /webdev (which also posts code and has used WP-Syntax until now). Any other blogs that want to publish code and previously relied on WP-Syntax should switch to the new plugin as well, but I don't know of any offhand.

We can keep WP-Syntax active on Hacks for the time being so older posts will retain their highlighting, but we should think about removing it soon. I hate to keep a plugin active if we can't actually use it. So it might be a good idea to update some previous posts to use the new highlighter, perhaps just a few recent ones and any older ones that still get lots of traffic. For really old or less-read posts, removing WP-Syntax just degrades to a basic <pre> block so it's still readable code, just without the syntax highlighting.

I'm going to resolve this particular bug as WONTFIX because, well, we're not going to fix the issue that was first described. Blog authors indeed can't publish unfiltered HTML and that's for the best.