Our resident tech expert is here to answer your questions! Here’s Penny:
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.
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 affect 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 as possible. 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 <tag> that opens, one needs to </close> (exception being images). Right now it reads
<span style="font-weight:700; color:purple;text-transform:uppercase;"> 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.
<h1>i am a heading!<img src="imagename.jpg"></h1>. Moving the whole tag with the image outside so it reads instead
<h1>i am a heading!</h1><img src="imagename.jpg"> will fix that specific problem.
Note: We discovered when formatting this post for publication that a plugin overwrites the image formatting! The code in the editor looked fine. So how did I figure it out? I looked at the source code of the page and found the extra code in there that I didn’t expect. As we didn’t want to turn off that plugin, I changed the example into an image instead of a text example. Working with different tools to figure out what’s going on will be a future Ask Penny article!
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.
Penny Shima Glanz spends her days spinning yarn and code into memorable projects. Small businesses rely on her for practical technology solutions. Designers rely on her to sample, test, and edit their handknit and crochet patterns. She loves muddy trail runs, fosters kittens, and lives in Westchester, NY with her husband and two resident cats. www.pennyshima.com