SEO And Done? Hmmm…

In the past few weeks I’ve been approached, twice, by people obliquely seeking help promoting their sites on search engines. One of then knew enough to call what they wanted “SEO” and they both approached obliquely, though politely, obviously looking for free advice while pretending to inquire about my services and fees. I couldn’t help either of them. SEO is hard and best left to specialists (more below), but that’s not why I couldn’t help. I couldn’t help because in both cases they LAST thing they should have wanted is for a prospective customer to see their website.

(read more )

Old Sites, NewTools

The tools and techniques available to Web developers have improved immensely in the last few years. Our jobs are easier and the Websites we build better because of editors like Atom.ioSublime Text, and VisualStudio Code, diff tools like Beyond Compare, version control systems like Git (and the de-facto home of open-source development based on it, GitHub), developer-focused browsers like Mozilla’s Developer’s Edition of Firefox and Google’s Canary Edition of Chrome, CSS processors like SASS and PostCSS, build tools like Gulp, Grunt, and Webpack, JavaScript libraries like React.js, AngularJS, and jQuery — I could go on and on.  That’s  a partial list of my daily toolkit. The full kit is larger and good options exist for every tool I use.

These tools can lost their edge, though, if we’re asked to add a feature to a site that was built five years ago (or a site that was built yesterday using methods from five years ago), and we might face the prospect of having to revert to what feels like sharpened rocks to get the job done. Revising legacy CSS files is where I first notice great tools becoming irrelevant and where the problem has loomed largest for me, and that’s what I’m going to talk about here.

(read more )

Gutenberg Block Styles Headstart

I plan to keep banging this drum — WordPress 5.0 is coming this year, a lot will change, and the big change will be the introduction of a new default editor codenamed “Gutenberg.”

Elsewhere I’ve (hastily) sketched out some things WordPress users should do to prepare for 5.0, here I’m addressing WordPress developers.

Blocks of content entered into a post (keep in mind that everything is a post) via Gutenberg get tagged with a block-specific CSS class, like .wp-block-button or .wp-block-cover-image. Default styles for core-blocks are loaded (for now, While we use a plugin) from somedomain.com/wp-content/plugins/gutenberg/build/core-blocks/style.css, and are loaded before the theme stylesheets. The Gutenberg developers have written well-formed CSS so a theme’s stylesheet overrides the default styles without problems like over-specified selectors or !important declarations.

Much of my work is building custom WordPress themes and the custom themes I make almost always start from Automattic’s Underscores starter-theme. Underscores provides modularized CSS using SASS. Anticipating WordPress 5.0, and for the sites (like this one) that currently use the plugin, I’ve created a collection of SASS files copying the default styles for Gutenberg core blocks, organized according to where the block sits in the editor’s selection dropdown. The files are available on Github.

A developer can incorporate this collection to a theme’s SASS folder for quick availability of the necessary selectors for styling blocks, providing a head-start in matching block styles to the theme.

In addition to the theme styles, there is also a collection of editor-styles in the GitHub project. I don’t want to blab about it here, but with careful development of editor-styles, a theme can come very close to displaying the editor contents just as they will appear on the live site, approaching the What You See Is What You Get promise that no one has ever quite delivered.

Getting Ready For WordPress 5.0

WordPress 5.0 is expected to be released in August. It’s a big change that will break some sites that aren’t prepared.

Here’s my take on what ought to be done when a release date is announced:

  • suspend any automatic upgrades;
  • make sure a backup program is in place;
  • install 5.0 and test on a staging/development site before upgrading a live site;
  • install, activate, and test a "Classic Editor" plugin.

The big change in WordPress 5.0 is the vastly improved editor (called “Gutenberg”) and it won’t work on existing themes without revising them. The necessary revisions aren’t predictable so we can’t estimate even a ballpark cost for the necessary revisions.

Kitchen-sink themes like Divi and Avada will probably take it upon themselves to replace Gutenberg with their own page-builder, but they might be sacrificing some medium-term benefits — Automattic has big plans for WordPress and much of it is centered around maximum use of the new editor.

It’s a good time to start planning to re-do older sites, looking at completion in early 2019 when WordPress 5.x has stabilized a little.

Working Around GoDaddy’s Awful Domain Forwarding

I don’t know when it started, but as I write this (June 2018), domain forwarding on the registrar GoDaddy is awful.

At least GoDaddy forwarding is simple to set up. You click “DNS” on the domain you want to forward, scroll down to “Forwarding” and click a couple of boxes. Things would have been great if it was all there was to it.

Recently, a client acquired a company with several websites and asked me to direct all traffic from the acquired website to a single page on an established site — like “redirect anything.old-domain.com/anything to new-domain.com/some-page/“. That would have been trivial with a .htaccess file but the old hosting accounts had expired during the acquisition so the trivial solution wasn’t available. The domains were registered with GoDaddy, and forwarding the domains using GoDaddy’s deceptively simple form seemed the best solution.

After clicking the right boxes, the domains and subdomains, like old-domain.com and old-domain.com/def/ worked fine, redirecting to the base redirect url new-domain.com/some-page/. But URLs for individual pages, like old-domain.com/page.html, were redirected by GoDaddy to what seemed to be the error page of a link-shortening utility. Two long battles with GoDaddy support ended with them telling me that’s just how it is and that I don’t understand how the internet works.

Which is true enough, I suppose, but that didn’t solve my problem and luckily other people do know how the internet works.

To fix the issue (without having to purchase hosting or talk with GoDaddy support again) I set up the old domains in a Cloudflare account, pointed the GoDaddy DNS settings to the assigned Cloudflare name servers, then used a Cloudflare “Page Rule” (see image) with a couple of asterisks as wildcards to forward everything hitting the old domains to the new landing page. A free Cloudflare account provides 3 page rules, if you need more than that they cost $5/month each.

This is a workable but not perfect solution. Perfect would be for the registrar’s domain forwarding to redirect without an error page intervening, but GoDaddy has messed this up.