Category: Code

Problems I’ve encountered, solutions I’ve (hopefully) found, and weird itches that needed scratching

How to get Jetpack’s “Writing Prompts” in WordPress

The WordPress Jetpack plugin recently (and experimentally) added “Writing Prompts” like those seen on WordPress.com-hosted sites since…I wanna say 2020?

I’ve been thinking about getting more into “Personal Blogging” elsewhere, and I figured these would be useful in getting words out.

In order to get these prompts on a self-hosted WordPress site, you need to do three things:

  1. Upgrade to JetPack 11.7 or higher
  2. Add the following line of code to your wp-config.php file:
    define( 'JETPACK_EXPERIMENTAL_BLOCKS', true );
  3. Go to “Settings > Writing” in WordPress admin, and check the box labeled “Show a writing prompt when starting a new post.”

I don’t know when this is supposed to become available without Step (2), but at that point it might be a good idea to turn off Experimental Blocks by removing that line.

Leave a Comment

Generating editor snippets from SassDoc

I’ve always loved SassDoc, and I’ve always loved editor snippets, but as a Vim and Neosnippets user, (a) other people’s (VSCode) snippets weren’t useful to me, and (b) my (Neosnippet) snippets weren’t useful to anybody else.

At some point it would be great to build a tool that can convert snippets of one format to any other format (IntelliJ? Atom?), but in the meantime I thought, “Where do we get snippets from to begin with?” Authoring them in the first place is a pain.

So after encountering a massive (massive) Sass library last week, one that was thoroughly marked up with comprehensive SassDoc comments, I realized the machine-readability of SassDoc makes it perfect for generating Sass snippets from.

So I made sassdoc-to-snippets, a command-line (or Gulp-compatible) tool for taking a directory or file of SassDoc-commented Sass and turning it into snippets files, for either VSCode or Neosnippet (and with other syntaces easily added).

Please try it out! Test it, bang on it, kick it, see what breaks it or how it could be improved and please let me know in a PR or Issue on GitHub.

Leave a Comment

RTFM

Being told to “read the fucking manual” is like being told to read Gray’s Anatomy and then perform a kidney transplant.

Leave a Comment

Using conditionals in .gitconfig

Recently I was creating a Git alias for logs that used --date=human for date formatting, before realizing this option had only been added in Git 2.21. After pulling the alias to some of my other machines and seeing that it failed, I decided I wanted a conditional line in my Git config that tested my current version of Git, used --date=human if possible, and --date=short if not.

Git’s config syntax doesn’t allow for conditionals, but it does allow for the running of arbitrary bits of shell script. For instance, something like this will work:

[alias]
  lg = "!if (( "1 > 2" )); then git log --oneline; else git log; fi"

Because 1 is not greater than 2, git lg will perform a standard git log.

How do we compare our version of Git to a specific value, then? Let’s figure out how to get just our version number of Git first:

$ git --version | sed -E 's/git version ([0-9]+.[0-9]+).*/\1/g'

For me this returns 2.29. We need to check that this is greater than 2.20. Let’s try this:

$ if (( "2.29 > 2.20" )); then echo "Compatible"; else echo "Not compatible"; fi

Why doesn’t this work? I’m getting an invalid arithmetic operator error.

Turns out Bash only handles integer math, so we need to pipe our comparison expression to a basic calculator program:

$ if (( $(echo "2.29 > 2.20" | bc) )); then echo "Compatible"; else echo "Not compatible"; fi

Great! Works for me. Now we just need to get our actual Git version in there instead of the literal 2.29.

After some struggle — the \1 reference in sed needs to be double-escaped here, for some reason — this is the result:

[alias]
  lg = "!if (( \
      $(echo \"$(git --version | sed -E 's/git version ([0-9]+.[0-9]+).*/\\1/') > 2.20\" | bc) \
    )); then \
      DATE="--date=human"; \
    else \
      DATE="--date=short"; \
    fi; \
    git log --pretty=format:\"%h %ad %s\" $DATE"

Now git lg will show a single-line log with “human”-formatted date if possible, or a “short”-formatted date if not.

I’ve created a Gist that puts this all together.

Leave a Comment

How to correctly internationalize WordPress child themes

Internationalization (i18n) and localization (l10n) are important and often overlooked aspects of WordPress development. Themes should give developers and administrators the ability to add translations for users from among the roughly 95% of the world whose first language isn’t English.

There are plenty of articles written about how to provide i18n and l10n for a single theme, but what about child themes? When building a child theme, assuming the parent theme is properly internationalized, developers may want to do any or all of the following:

  1. Provide localizations that aren’t provided by the parent theme, either in different languages or in gaps in existing localizations.
  2. Modify existing localizations in the parent theme, for instance if the developer of the child theme wants to change the wording of some area of the site.
  3. Provide new internationalizations unique to the child theme, using the child theme’s text domain.

Let’s start by looking at a simple example of i18n in a WordPress theme. For the purposes of this article, the parent theme will be called “Parent Theme” with the text domain parenttheme, and the child theme will be called “Child Theme” with the text domain childtheme.

Continue reading

Leave a Comment

On Vim’s being institutionally outdated

I adore Vim, I use it every day, and I wouldn’t dream of switching to anything else, but every once in a while I’m reminded of another thing about it that is just unequivocally bad and indefensible.

I was reading about the “CoC” plugin (“Conqueror of Completion”) this morning when I thought, “Wait, can’t Omni completion do some of that?” So I opened up Vim with a minimal .vimrc and typed:

document.que<C-x><C-o>

<C-x><C-o> opens Vim’s native Omni completion function, which I would expect to be at least somewhat current on JavaScript methods in 2020. Instead, nothing came up.

I had a look at the source of the JavaScript completion function in Vim, and found this: a file that was last updated three years ago, but that hasn’t been meaningfully updated since 2006.

So how have Vim users been getting by?

Continue reading

Leave a Comment

Getting the “Belle & Sebastian effect” with CSS filters

There are a lot of articles out there regarding using SVG’s feColorMatrix with CSS filters to get a “duotone” or “Instagram” effect on photos, but frankly most of the examples looked too weird to me, and the matrix multiplication that’s going on is pretty hard to wrap my brain around.

Usually what I want is a simple monochrome duotone effect; in other words, the Belle & Sebastian effect:

Most of these are a “dark” duotone effect, where the blacks remain black and the whites become the desired color.

Continue reading

Leave a Comment

Chris Coyier on PostCSS

Chris Coyier on PostCSS:

We know that specs change. It happens all the time. Seems weird to base a syntax on a non-final spec. What happens when the spec changes? Do you change the language and let existing code break? How is that future-proof? Or support all past formats? Meaning the language isn’t really based on future CSS, it’s based on any experimental idea that was considered?

These have been exactly my thoughts since hearing about CSS post-processors. How can people honestly believe that the code they’re writing is future-proof? Sass source files certainly are prone to “spec rot”, but the CSS they generate isn’t (at least, insofar as anything can be immune to it).

On writing real CSS (again) | CSS-Tricks

One Response