plugin injects broken markup

Hiya,

This is likely generated by your theme, or could be in your events page.

Can you share a link to your site so we can take a look please?

Thanks,
Phil

Hi Phil

Iv’e been developing a custom theme locally, but I’ve put it up for you to see. The events page can be seen here:

https://temporaryurl.scripteen.com/bx

If the loose tag is coming from the theme, which file should I be looking at?

More information:

The tag specifically gets injected after </div=”em-wrapper”>,
and before the custom code that I’ve entered in the ‘formatting’ section.

Following is a screenshot showing where the tag gets injected:
https://imgur.com/BHNEuEt

Note: the screenshot shows a closing tag. That closing tag isn’t in the actual source code. However, it’s created by chrome as an error-correction response to the broken markup.

bump

does this happen if you switch to the twentytwelve theme?

Hey Marcus.

No, the open p tag isn’t present if I switch the theme.

This obviously means that the broken code is coming from somewhere in my own theme.

Which template is used? Page.php?

you’re probably using wpautop somewhere

see this, maybe it helps – https://codex.www.ads-software.com/Function_Reference/wpautop#Disabling_the_filter

Hey Marcus.

This does indeed work.

However, it also breaks the rest of my site. Content in posts are no longer wrapped in ‘p’ tags.

Hiya,

You will need to re-edit your content to take this into account. Or, re-enable the autop filter and check your content for extraneous P tags.

Thanks

is this resolved? If not pls unmark it resolved (on the right)

chances are you aren’t trying to disable the wpautop WP uses, because our plugin works fine with that enabled, it’s an extra wpautop filter your theme has added that needs to be disabled.

it’s possible that your theme depends on that for formatting (ideally it shouldn’t)… if so you may need to disable that wpautop just for events.

Hey Marcus.

No, the issue isn’t resolved yet. As far as I can tell, the wpautop function is enabled by default in wordpress, in the absence of an override. In other words, it’s an important part of how wordpress words.

The documentation for the function gives a way to disable the feature across the whole site.

This causes behaviour that is undesirable generally: when ‘p’ tags aren’t generated by the wysiwyg editor, they must be edited by hand. This violates users expecations of how wordpress is supposed to work.

Of course a developer can work around this by manually adding p tags. But this solution isn’t really acceptable for non-developer users of wordpress.

This behaviour would also be unnacceptable for sites with existing content: all of a sudden, the ‘p’ tags would be stripped away, breaking design and possibly readability.

I imagine that the plugin might have been designed for sites without pre-existing content.

My next attack at this problem will be to figure out your suggested approach: disabling wpautop for pages that just have markup output by the plugin.

Of course this isn’t entirely unproblematic either, because some pages on the site that I’m building might have content produced by the wysiwyg editor and output from em. But it’ll be a start.

come to think of it, in this case, as far as we’re concerned it’s resolved, because you did mention it’s not happening with 20 12 so it’s specific-theme related.

EM hooks into the_content after WP executes wpautop. your theme seems to be adding extra formatting later on a second time because EM does work fine with the default wpautop.

The issue might be theme specific. But this is the case, then it’s not because I’m doing anything with the_content.

I’m not making any use of any hooks connected to the_content.

Pasted here is my Page.php: https://pastebin.com/e3bvQqV4

As you can see, there are no extraneous ‘p’ tags wrapping aroung the_content.

If EM is injecting content using the Page template and hooking into the_content, then it appears that EM is injecting broken markup.

that’d be done by a filter in your theme somewhere else in your files most likely. Since each theme can do it in many different ways, it’s hard to say where it’d be, most commonly it’s in functions.php