Clients sometimes contact me concerned because the formatting in their blog post isn’t quite what they expected. They’d spent hours making their post just so and are surprised and distraught to discover it doesn’t look how they planned.
Why?
They formatted their content in another application, most often a word processor, then copy and pasted it into their WordPress post editor.
They were only copying-and-pasting, they say. Why didn’t it work?
The issues lies beneath the visual surface.
In general when you edit a document on a webpage, you are doing so with what’s known as a WYSIWYG interface, what you see, a bold word for instance, is what you get, for that particular application.
While it looks like a bold to you, maybe to another application it’s font weight 700.
There are two main factors at play that can effect why your copy and paste doesn’t look how you expect.
First, your WordPress site is styled with a theme. Depending on the theme, it may overwrite how different design elements such as bold are displayed. That is accomplished in the theme’s style sheet. As an example, let’s pretend it was decided that any bold word wouldn’t just be stronger in font weight, but it might also be stronger, purple, and uppercase! While you can change that style in a specific post, the detailed explanation of how is beyond this scope of this quick post.
The next potential source of the problem is a little more complex. It isn’t only the theme styling that influences how your content looks, but how it is edited.
Most of you probably use the Visual editor to edit WordPress content. That’s great! It’s the most familiar. It’s a WYSIWYG environment, similar to your favourite word processor. In the case of WordPress, it is powered by a tiny bit of software called Tiny MCE. This software is used in many common applications, here’s a list. If the applications you are copying and pasting between are both on the list, then the likelihood of a translation error diminishes. It could still happen if there is a version difference or any customizations were made. Your word processing application (even if it’s online) likely uses different software to provide WYSIWYG. The errors and issues arrive when the two pieces try to say the same thing in their different ways. The issues arise in translation.
That’s all fine and good, but how do you fix it?
I highly suggest working with minimally formatted files until the very end. I understand that can be difficult in the real world, especially if you are drafting and not the one handling the final steps before publication in a different system. My advice is for all involved to reach mutual agreement about your own styling tags to use, for example (((img filename.jpg align-left))) could be used to explain how a certain image would be formatted. If that’s not possible and you find yourself in a post mess, please don’t fret, I have two solutions.
Option one: copy and paste the text into a plain text editor to strip out as much formatting. Then paste into the content editing window and refer to the original document for formatting. Yes, this is a pain and time-consuming but it helps ensure the style is generated from only one place.
Option two is best if you are comfortable looking at a bit of HTML. In the WordPress content editor, switch from visual to the text view to view the source code. Yes, for me this is easy, I acknowledge that I have 17+ years of experience, doing editing HTML! But even if you are new to it sometimes with a bit of searching for the pattern, it is pretty clear what could be causing the formatting problem. For example, to change that Stronger, Purple, and Uppercase text from our example above, look for the part that’s within the style attribute of the HTML tag, and take it out or change it. Remember that for almost every html By switching purple to red and changing the style from a text-style to a font-variant, it now reads Stronger, Red, and Small Caps.
One of the most common errors I’ve seen over the years is an image pasted just before a heading tag closes. It can cause weirdness that is quick to debug if you look at the source code. There it’s clear that the image is before where we really want it.
i am a heading!
. Moving the whole tag with the image outside so it reads instead
i am a heading!
will fix that specific problem.
i am a heading!i am a heading!
In a perfect world there would be seamless translation of formatting between applications. In the meantime hopefully this helps you understand why it happens and provides a few tools to help you fix it.
A prior version of this post appeared on the Patterned Blog.