Category: Editorial

Early in 2016, I left my job, became self employed, and never actually announced that fact to the world. Here’s why: It’s scary. Terrifying, in fact.

At first, I didn’t share because I was adjusting in the same way anyone with a new job adjusts. I had left my full time job as a senior web developer at an agency to work part-time rebuilding the technical infrastructure of a non-profit I am passionate about. They had been repeatedly targeted by hackers, and so those first few weeks were spent full-time fixing the biggest security holes. At first, it felt like I just had a new job.

I became preoccupied with setting up a business, which, turns out, is confusing to do in the District of Columbia. Then, I started taking on other clients while setting up administrative structures for myself. All of these logistical parts that have nothing to do with my skillset overwhelmed me. I wondered if I could figure out small business administration, if I could make enough money to make this adventure sustainable, if I could really do everything I wanted to do on my own.

I had a lot of self-doubt (imposter syndrome is real!) and the part of me that is really shy encouraged me to keep to myself while I got used to what I was doing. At the same time, I appeared on WP RoundTable, which was the first public indication that I was self-employed.

Meanwhile, I realized something really important: I loved my clients. Big love. Unicorns jumping on rainbows love.

I was happier than I’d been in years.

It was feeding my soul to work on projects that are focused on making the world a better place. Every day, I was delighted to work with my talented, passionate, amazing clients.

I traveled a lot to attend conferences and spoke quite a bit (WordCamps Lancaster, Northeast Ohio, New York City, Pittsburgh, Baltimore, and US). The total quantity was perhaps too much for my homebody self, but I absolutely love teaching through public speaking and enjoyed every second of these trips.

WordCamps have been a constant in my life for years now, as have the WordPress Training Team, the WordPress DC Meetup, and DCFemTech. I can not explain how much I adore the people in these communities. For me, 2016 highlights from these areas of my life include the training team building out their first full workshop, speaking at the DC meetup about one of my favorite topics: color, leading a workshop for the Women’s Information Network on getting into WordPress, helping organize DCFemTech’s very first Inspire event, and helping organize DCFemTech’s second annual Hack for Good. Dear friends in these communities also connected me with opportunities to my very first guest blog post for Design TLC and do an AMA for ManageWP.

The support of these communities, friends, and family buoyed my spirits in the times when my confidence dipped. And it did dip: there is nothing like being totally on your own to cause self-doubt. In spite of this, not once did I feel lonely in 2016, even though I spent most of my time working by myself. When I felt discouraged, tired, or otherwise doubted myself, I’ve been so thankful to have people in my life who help pull me back into a productive place.

I worked more in WordPress and less in Drupal. I ended the year with an 80% WordPress/20% Drupal split in work, which is exactly the opposite of what this distribution looked like in 2015. In doing so, my skills as a WordPress developer grew tremendously, which was a larger goal I’d had for the year.

Consciously leaving the security of full-time employment is easily the biggest professional risk I’ve ever made, but is also perhaps the best thing I’ve ever done. In 2016 I worked with many of my favorite people from all parts of my life and career. I worked with designers who pushed me technically and projects that presented new problems. I am a better developer, project manager, and all around problem solver than I was a year ago.

I got over being afraid of being self-employed and started to revel in the possibilities of it.

So what’s next?

In 2017 I want to focus on expanding past client work. Don’t get me wrong, I am still doe-eyed in love with my clients and intend to keep supporting them and working as a developer. It’s just that I also want to spend more time writing, speaking, and teaching. My clients and others I’ve met this past year have helped crystallize something I already knew: web development and the internet spark a lot of anxiety in people who are trying to learn to code or who are trying to manage their websites. I love working with these people so that they are empowered with the tools and skills they need and I want to do more of that work outside of my one-on-one client engagements.

With that, stay tuned! I’ll be blogging regularly in 2017 and also have a few other projects sitting in the wings. I’d love to have you along for the ride, so please consider being one of the first to join my brand spanking new email list!

What are your plans for 2017? Let me know in the comments!

Last year I failed to write a novel. I had every intent of writing a book and I even had an idea (think the results of apocalyptic consumerism encouraged by a greedy and controlling government). So, I signed up for National Novel Writing Month (NaNoWriMo) and gave it a go: I lasted two days.

I failed because I was trying to write a book that is fundamentally outside of what I read. The only novel of any kind I can think of that I have read in the last five years is Louise Penny’s Still Life, which I read because I was on vacation with my sister, who has read every single one of Penny’s mysteries. It was a great book and the perfect thing for me to read at the beach, but the reality is that when left to my own devices I read massive quantities of non-fiction.

This year, I signed up again, but I am going to defy NaNoWriMo convention and write a non-fiction book. My years of aspiring to write a novel have taught me that the goal of NaNoWriMo is overarchingly to get a first draft (at least 50,000 words) on paper in the month of November, so that is exactly what I am aiming for.

I have an outline of the book I am envisioning, but I have not done any research beyond sharing the outline with a few people to get their feedback. I have lots of questions. Will the amount of research that I’ll need to do be more or less labor intensive than my fiction-writing counterparts? Will the 1600+ words that I need to write per day to reach the goal be doable with my subject matter? Is 50,000 words a reasonable target length for my book or will it be shorter/longer? Will I have time to do this given all of the other personal and professional commitments I have in November?

NaNoWriMo also tells you to publicly commit to writing a book so that you’re holding yourself accountable to those you know. Last year I am pretty sure I told two people and that was it. This year, I am writing this post to force myself to be accountable. Writing this book is something I really want to do and so I’m sharing the goal with the world. I am not aiming for a complete, perfect, publishable book this month, but a first draft of something that I could polish and expand after November. I’ll report back in a month and report on how it went. I am determined to make sure that at that point, something of unknown quality and word count exists.

When most people think of a website dying they think of sites that are temporarily pushed off the face of the internet by denial of service attacks or sites that are maimed and manipulated by hackers. Though these two things certainly do cause websites to “die” temporarily, there are so many other ways websites can go to the other side for a little bit… or for good. And however they go, there are always so many feelings.

There is that “oh shit, I killed it!” moment that happens to developers everywhere. Maybe you forgot a semicolon in your PHP and got a white screen of death in return. Maybe you updated your plugins and were inexplicably gifted the same result. Maybe you just did something ridiculous in a moment of temporary insanity like drag one folder into another folder on your server. In most of these cases revival is pretty quick and the dominant emotion is probably fleeting panic followed by the thought that no one probably noticed anyway. After all, you only killed it for thirty seconds, right?

Then there is the surprise takeover. Have you ever gone to a website that you built and maybe even thought you maintained only to find that your website is gone and an imposter has taken it’s place? Did the powers that be really rebuild and repoint their domain on their own?!

Most takeovers are deliberate and mutually agreed upon transfers of power though. Sometimes downloading your files, exporting your database, and packaging it all up to send into the ether is enough to make you feel ill. What will the new keepers do with your files? Will they even use them or are they going to go into a deep dark archive only to be forgotten forever? If you’re the receiver of the package, then what will you find? Will the code be clean? Is this going to be a nightmare to maintain? Maybe it will be easier to just rebuild it…

Then there is the launch surprise. You are responsible for pointing the domain away from the website you’ve maintained and into the unknown. What will be there? Sometimes what is there is beautiful and makes you feel awful inside. Why didn’t you build something as awesome before? Could you, if you wanted to? Self doubt will win every time. Other times what is there is arguably a step back from what you’d built. Why would anyone want this new monstrosity instead?

Sometimes you are replacing your own work. Most of the time this results in genuine relief – thank goodness this old, horrific code of mine is leaving the internet forever. I know it was cutting edge at the time it was built, but it is positively embarrassing today. And doesn’t it look so much better now anyway?

I can not browse the internet like a normal person because I build websites for a living. I constantly critique the websites I find and open up my code inspector to see how a particular effect was achieved. With surprising frequency I have come across websites (including quite a few for huge companies) that are generally beautifully constructed, but that have a glaring visual error that somehow made it past quality control testing. The following mistakes are the offenders that make me cringe the most.

1. Formatting that Forces a Horizontal Scroll Bar

Horizontal scroll bars are expected on websites that were built with a fixed width. However, when a horizontal scroll bar appears on a responsive website, it is symptomatic of an element on the page overflowing beyond that page’s 100% width container.

In a lot of cases I’ve noticed that this phenomenon is specific to only one page or type of page on a website, which helps explain how this issue could have been missed during testing. Elements introduced by content managers into a blog post, for example, can cause this issue on single pages. Often, this issue is not a problem on all widths, but may impact just some screen widths.

A few things that can cause overflow to happen are:

• fixed width elements that are wider than the current viewport width
• elements where overflow should be, but is not set to “hidden”
• when a percentage width is combined with a fixed width and therefore “outgrows” the available screen real estate
• iframes
• images or videos that are not responsive

Fixing this particular problem can be tricky and typically involves some detective work. The key element of fixing the problem is identifying which element or elements on the page are causing the overflow. From there, one can make a decision about how to approach fixing that particular issue.

When I run across this issue on a website I am building, I typically will look for the source of the problem by hiding entire sections of the DOM one at a time to see if the scroll bar disappears once a particular element is hidden. Usually I add display: none; to elements using my code inspector to remove them one at a time. In particularly persnickety cases I may comment out entire sections of code that I have identified are NOT the problem so that I can more easily continue to inspect other parts of the page.

2. Favicons from Software or Frameworks

Building a website on top of an open source content management system like WordPress or Drupal is an awesome thing, but leaving the WordPress or Drupal logos as the favicon for your website is not. I also frequently see websites that still have the favicon from the Genesis Framework, which is a popular theme framework for WordPress.

The fix for this problem is simple: create your own favicon that utilizes the logo or branding of the client. Though I don’t recommend it, another option is removing the favicon entirely: no favicon is better than someone else’s favicon.

3. Very Wide Blocks of Text

There are a whole host of typographic sins that are committed constantly on the internet, but this particular problem can be very subtle, which is why I think it is often overlooked.

Wide blocks of text are a problem for readability of content. It is difficult for the human eye to focus on a line of text much beyond 100 characters. Historically, this is part of why newspapers have generally been typeset using narrow column widths.

Typically, if a website was designed with typographic best practices in mind, the comps for mobile, tablet, or desktop screen widths would not have included wide blocks of text. When this issue appears, I think wide text blocks have usually been introduced unintentionally in the development phase of the project. A developer may have failed to pay attention to what happens in between established breakpoints or they may have actively introduced wide text blocks when improvising design between or beyond established breakpoints.

Solutions to fix this particular problem are varied and heavily depend on the design of the particular site in question. Often the fix is to continue a design pattern from a different breakpoint, to establish a maximum width for a particular section, or to add a new breakpoint to address this specific issue.

Conclusion

I’m a stickler for visual details and it drives me nuts when I see these mistakes in the wild. Are there other visual mistakes you’ve noticed that consistently appear on websites you visit? Let me know in the comments.

In both the WordPress and Drupal communities you’ll frequently hear the refrain “don’t hack core.” What does that mean though? Often I see this phrase used out of context or without explanation. When I was first learning to code, I certainly didn’t know what it meant, I just knew that one time my mentor pointed to most of the files in WordPress and very seriously told me that touching them or changing them was very very bad.

What is core?

In order to not hack core, we first must be able to identify what core is. In general, “core” refers to the basic set of core files that make up a content management system. When you download WordPress or Drupal, the core files are what you download.

What does “hacking” core mean?

In the context of the phrase “don’t hack core” the word “hack” simply means “to change.” This means that you should not make any changes to core.

It’s that simple: do not change the core files. Changing the core files in any way is hacking the core files. Do not hack the core files.

Where am I allowed to make changes?

Of course, in order to customize WordPress or Drupal you will need to add theme and plugin or module files. There are very specific places where these files belong within the core file structure. In WordPress, custom theme files should be located under wp-content/themes and plugin files should be located under wp-content/plugins. In Drupal, your custom theme files should be located under sites/all/themes and module files should be located under sites/all/modules.

There is also a file that you may need to edit in order to make sure that your database is connected to your website (wp-config.php in WordPress and settings.php in Drupal). You’ll notice though that these files are not included when you initially download either CMS’s software. They are created as part of the installation process. In WordPress, wp-config.php is located at the root level and in Drupal, settings.php is located under sites/default.

Some developers will argue that they need to change core because they discovered a problem with it. If you find a bug in core and have a patch for the problem, then submit a bug report to the core development team for the software you are using. In the meantime, don’t hack core.

Why is hacking core bad?

In the most general sense, hacking core is bad because of the security, maintenance, and compatibility problems that making changes to core files can cause with your site. It can cause unforeseen and bizarre problems with the display of a website and can also be a root cause of issues that can bring down a website entirely.

There are also very specific reasons why hacking core is a bad idea. They are:

1. Inability to Easily Update Core

WordPress and Drupal frequently release updates to their core software. These updates include security updates, bug fixes, and new features. It is recommended that you upgrade your software as new versions become available so that your website is protected from any known security vulnerabilities and that it remains compatible with the most current versions of plugins and themes.

When you update either WordPress or Drupal, you are functionally replacing the old core files with new versions of the files. Therefore, when you “hack” core by making a modification to the core files, you are guaranteeing that you’ll need to redo these hacks with every update released for your software. Since the core software is changing with every update it is certainly possible that the hack you originally implemented will not be exactly replicable with a new version of the software.

2. Security Vulnerabilities

When a security vulnerability impacts WordPress or Drupal core, the core developers and community for each project will release an update that patches the vulnerability. If you create your own independent version of open source software, which is what you are doing when you change core even a little bit, you may create vulnerabilities and not even know it. You run the risk of having your site compromised and then having no one who can help you troubleshoot because your underlying software is unique.

3. Maintenance Problems

Most websites are maintained by multiple people over time. This can be due to staff or agency changes or simply due to the primary site maintainer going on vacation. If another person is trying to fix a problem on the website where you hacked core, you can not assume that this new person will look for changes within the core files because it is best practice to NOT change these files. This hypothetical person will instead look first in all of the places where changes should be made, like in child theme and custom plugin or module files.

4. Compatibility Problems with Plugins/Modules and Themes

In both WordPress and Drupal themes are used to modify the appearance and styling of a website and plugins or modules are used to modify how the software works. Some parts of themes and plugins/modules interact with pieces of code found in the core software. If you hack core, it is possible that you could modify something that interacts with a theme or plugin/module you are using and that this could cause unforeseen incompatibility issues. Again, troubleshooting these issues will be extremely difficult because your configuration will be 100% unique.

When it comes to core, there is no benefit in being your own unique snowflake.

5. That’s What Plugins and Modules Are For

Most of the time when people make changes to core, they are doing so because they want to change or add functionality to the software. This goal of modifying and extending the functionality of your content management system is exactly why plugins exist for WordPress and why modules exist for Drupal. Chances are you may be able to find an existing plugin or module that will add the functionality you’re looking for to your site. If you can’t find exactly what you want in an existing plugin or module, then best practices are to code your own custom plugin or module.

What about themes, plugins, and modules?

As with core, best practice is to not make changes to theme or plugin/module files. The underlying reasons for this are basically the same as the reasons why it is bad to hack core: updates will overwrite your changes and you may unknowingly introduce security vulnerabilities.

There are two generally accepted approaches to theme development: using a starter theme to create your own 100% customized theme or using a base theme and creating a child theme that overrides the base theme.

If you are using a plugin or module and you absolutely need to modify the code in order to get the functionality you need for your site, fork the plugin and create your own custom version. This will prevent future updates to the plugin from overriding your changes.

Conclusion

Hacking core is simply changing the core files for WordPress, Drupal, or any other widely used open source content management system out there. The place to make modifications to the way WordPress or Drupal looks is in your theme files. The way to make modifications to the way WordPress or Drupal works is with plugins and modules.

At the end of the day, never ever hack core. Never.