Beware of the WordPress Appearance Editor!

Update 8/22/2017: Looks like the appearance editor is in the process of getting a makeover – finally! My post below still has some accuracy, but I’m glad to see some of the issues being resolved to make code editing easier.

---

Avast me hearties! There be dangers lurking in the WordPress Appearance Editor!

Okay, okay, before you roll your eyes and abandon this post, I just wanted to share something. It occurred to me on my morning commute as I was handwriting new content aimed for beginners. I had to get myself in a mindset of what it was like diving into WordPress files for the first time again. Re-calling a greener Rachel lost in a labyrinth of files, desperate to complete the small task of changing a font color and not knowing where anything was – I realized that during this learning process, there was one adversary I encountered time and time again.

Said adversary stalled my progress in learning. In fact, it scared the heck out of me a few times whenever it caused the white screen of death before I even knew it was called that.

This adversary is the appearance editor on the dashboard. Thinking back on what I knew back then ( and didn’t know ), having this tool in my hands at the time only served to confuse me, discourage me, or give me impressions of WordPress that weren’t correct.

Here’s why I feel that way and why this tool should be approached with caution.

 

The appearance editor is easily accessible on the dashboard. By being so accessible, it gives the impression that it’s there to be used, right? It gives the impression that it’s okay for anyone to jump right in and have at it. However, for greener Rachel, or for those still learning about how WordPress files are built and relate to one another, using this editor may not be a good idea.

The problem is that the appearance editor is mistake prone. It’s set up in a way that it’s easy to make mistakes or possibly break something.

No Color Differentiation.

Unlike text-editors like Notepad, Sublime Text, Text Wrangler etc., the content in the appearance editor is black on white. There is no color differentiation between what is code and what is content. This might vary person to person, but for me, I learned to code by first learning how to edit existing code. Having those colors there made it easier for me to see where things opened and closed, what areas I should steer clear from and so on. By having everything essentially color-less, it was overwhelming to me as a beginner. It was a strain on the eyes to pay more attention so I’m not accidentally removing or changing something I shouldn’t.

<p class="look-ma">There's colors here!</p>

Oh yeah, and unlike other text-editors, there aren’t any line numbers either, but I digress. Of course the argument can be that the appearance editor isn’t meant to be some heavy do-all editor like the ones I mentioned already. Maybe it shouldn’t be for drastic or large amounts of changes. It doesn’t change the fact though, that because the tool is there, that people will use it this way. Either way, it’s just not very readable.

Changes are Set in Stone.

There’s one button on there – “Update File” . There are no revisions, and it looks like the cntrl/command + z keyboard shortcut works to undo what you’ve written, but once that fateful update button is clicked, there’s no undo. That’s a scary thing, especially if you’re editing multiple files. If you return to a specific file, can’t remember what you changed last, and there’s nothing to keep a history of it – good luck. It’s set in stone. This also makes troubleshooting harder when re-tracing steps in this editor.

No Context.

With this editor being so accessible to the admin user, as I said, it kind of suggests that you have free reign to go in guns blazing. Problem with this, is there’s no context. You only have access to specific files, and you don’t necessarily know how those files relate to each other. If there are files within folders, that’s not obvious by the list of files on the right side. It all appears as if everything is on one level.

Up on top, it tells you what theme you’re in and if you’re in a child theme. However, as someone who didn’t even know what a CMS was at the time, much less what a child theme was, that drop-down for the most part was completely ignored.

So a lot of people will just go in there, myself included back in the day, and edit a theme directly. It solves the problem at hand, especially if said person doesn’t have access to the files or doesn’t know how to access them like when they’re hosted on a server. Problem with this is editing a theme directly goes against best practices of using a child theme instead. The current Codex page on the appearance editor even suggests that it’s perfectly fine to edit themes – whether the wording is intentional or not. The page starts with and I quote:

Among the many user editable files in a standard WordPress installation are a Theme’s Template and Stylesheet files. The Appearance Editor Screen allows you to edit those Theme files.

It then goes on to talk about writing permissions, how to switch themes, but not a single mention that any changes made are possibly unsafe due to not working in a child theme. It assumes you must know, right? In all honesty, greener Rachel didn’t even know what the Codex was back then, let alone a child theme. At the very least, it does caution you on making PHP changes, which brings me to my next point…

The White Screen of Death

With WordPress built on PHP, and having a theme’s functions.php file accessible with this editor, any PHP error or syntax mistake that happens here can feel catastrophic to the beginner. I remember the first time I experienced the white screen of death. I was harmlessly making changes in the editor, and suddenly the entire site went white. Keep in mind I wasn’t even touching that terrifying functions.php file. Confused and panicking, I used the browser inspector to desperately troubleshoot to no avail. Since I was deep in the zone within multiple files, it was time consuming trying to re-trace my every step with no history or color differentiation to make this easier on me.

 

My senior developer had to help me figure out what the problem was multiple times. Being completely new to the web development professionally, I felt embarrassed and guilty. I’d done something seemingly so bad that I broke the site to a point where everything went blank. Thinking back on it now, it could’ve been something as harmless as a semi-colon or open curly brace. That’s nothing to fret over, but back then, not wanting to lag behind or pull the rest of the developers down with my inexperience – this felt horrible.

I think I was lucky enough that the white screen was only on the front facing part of the site and I still had access to the dashboard. But others are not so lucky. If both the dashboard and the front-end of the site go white, and this person doesn’t have access to files or doesn’t know where to even begin fixing this – it sounds like a crisis! Even the Codex warns that bad things can happen when editing PHP, and as I said earlier, when it’s “set in stone” by that doomsday button, “Update file”:

Be very careful editing PHP files of your current theme. The editor does not make backup copies. If you introduce an error that crashes your site, you cannot use the editor to fix the problem.

Just one missing semi-colon is all it takes to launch WordPress into death mode.

When learning in the beginning, the more victories that happen, the more encouraged I am to learn more. The scarier and more difficult something becomes, the opposite happens.

That’s probably true for most people so why hand over a tool that can potentially discourage learning WordPress or how to code?

What I’m Really Saying…

 

Okay, I’m not saying that no one should touch this editor. That if you’re not a PHP prince, Html hulk, Css chupacabra, or whatever odd monickers they come up with for developers these days, that you have no business messing with the appearance editor. I won’t lie, I kind of want to be a hulk instead of a ninja or a rock star. I’m saying that either the editor can be improved to make it less “mistake-prone”, or perhaps we need a resource to provide more guidance for people using this tool.

The Codex is an intimidating place for some. It definitely was for me back then. So we can’t always expect that users are going to research all the possible ways they can break WordPress before diving in. If they’re anything like me, they learn by getting their hands dirty. Yes, that includes breaking things, but not if it means breaking beyond repair or in a way that makes learning from mistakes difficult.

I admit, I’m not a WordPress core developer or core contributor. I still have a lot to learn before I go tearing apart files in the wp-includes/admin folder, but it’s just a thought. Maybe what I’m suggesting and the way the editor is currently built – it’s just not possible. Maybe it is possible, and some day, the appearance editor can be improved.

For now, I just hope someone finds this and it helps them. You’re welcome to take the appearance editor for a spin – just with caution. When used correctly, it can be a great time-saving tool for minor changes. 🙂

Did this help you? If not, how could I have written it to help you better? I’d love to hear about it in the comments.

If this worked for you, and you’d like more tutorials and thoughts about WordPress, I’d love it if you subscribed ( top sidebar ). Your inbox will occasionally alert you of posts full of WordPress awesomeness.