Category: WordPress

  • A Book Table of Contents in an eBook World

    If you publish a long-form content piece on the web, you really owe it to your readers to provide navigational help. That seems obvious, but most things online that call themselves books (just one way of singling out long-form material) don’t go very far out of their way. If there’s any plain-old book table of contents, odds are it’s static or offers only chapter heading links. The web could stand to do a little better.

    This article makes a start at thinking it through: what are the options for what, in the physical world, might be called the “table of contents.”

    The final section of this piece also includes an overview of one approach to creating a book-like structure in WordPress and giving it a table of contents (though it’s built manually). With this approach, adding a ToC-specific menu for the book is trivial, if not entirely satisfactory.

    Mind you, a book table of contents—that thing that, in English-language books, comes in the front before the actual content material—is only one navigation tool that can be provided in print books. There’s also, in nonfiction works, the index, which is just a much finer-grained table of contents that’s been sorted into alphabetical order.

    Chapter summaries fall into the navigation category and occur even in fiction, though most often in older works, such as this example from Dickens:

    Chapter 38: Mr. Samuel Weller, Being Entrusted With a Mission of Love, Proceeds to Execute it; With What Success Will Hereinafter Appear

    Charles Dickens

    Even the sidebar, beloved of textbooks, is a sort of navigational aid, in that it clearly signals that the material in the sidebar is incidental to the main flow of the text and could, if one were in a rush, be skipped for now.

    In some instances, footnotes, too, are navigational, pointing to other sections of the book (what you might call “internal links”) or pointing to other works (“external links”).

    But the main option is the table of contents, and that’s where we’ll spend most of our time in this piece. As a side note, never forget that your table of contents is another small element in your ebook marketing plan — people skim ToC’s to get a sense of whether the content suits their needs.

    The Blog List as a Book Table of Contents

    If you think of a blog in its entirety as a long-form work (which I don’t, but it’s a useful place to start), the reverse chronological listing of posts that appears on the top of the blog is as much ToC as you get.

    It’s a terrible ToC and I think the reasons are fairly obvious: it doesn’t generally provide any sense of topical organization or how things fit together. It’s also generally designed so that the individual entries take up a lot of space, such that you have to click through lots of pages to get to things that didn’t appear quite recently.

    Reflecting about what’s missing gives us a couple ideas about what makes a good online ToC. First, a ToC ideally conveys the internal structure of the work. Is there a first part that’s theoretical and a second part that’s about practical application? Great. Then the ToC should convey this. Second, it does this in a way that gives access to at least the top-level hierarchy of the work in one view. Readers should be able to move through the ToC without clicking through multiple places.

    One fantastic additional element to an online ToC, as opposed to a print book, is that it should be available on every page in the work, and easily consulted without unintentionally losing one’s current place.

    The PDF’s lost opportunity

    We won’t linger on this, but it’s worth mentioning in passing that most PDF “eBooks” are a terrific example of how not to do this sort of thing. (And there’s a good argument that you shouldn’t be using PDFs for this stuff anyway…)

    Because of the PDF’s heritage as a format that preserves the look and feel of printed pages, it’s not unusual to see a conventional print-style ToC at the front of one.

    Even though it’s possible to make the text on these ToCs link to the pages they point to, as often as not, PDF designers don’t bother with this extra step.

    Without putting too fine a point on it, this is missing the point of being online.

    We won’t linger on the PDF, but one thing that is interesting is the way some readers will show some documents with thumbnail page images down one margin, so that you can jump to a specific page and have some general idea what that page looks like. In some formats, this means you can easily identify the starting pages of chapters. In works that have substantially different designs on different pages, you may even be able to jump directly to a page. It’s a nice touch and something that simply isn’t possible in print.

    The eBook Table of Contents

    Whereas print books tend to have a page that contains little more than the title and author of the book, this feels a little performative in an online work. In an online work, it seems better to have the title and author combined either with cover art or with the ToC, just depending on the style or nature (fiction or non-fiction, for instance) of the book.

    In longer web pages, one sees a sort of “proto-ToC” that shows, typically, the subheadings on the page and allows for a direct jump to those locations.

    There are starting to be Gutenberg blocks that provide this sort of ToC functionality as well:

    Nothing wrong with it, but nothing to write home about either…

    Way in the back of my head I feel like there used to be natively in WordPress to make sequential book pages instead of chronological posts, but in the past couple of days, I’ve poked around the internet looking for this option in vain. I think it vanished from disuse and, best I can recall, it was pretty clunky. But I do think there might have been a rudimentary ToC capability included with it.

    As far as I know, that was the only plugin-oriented ToC device for handling lots of sections and pages in a sequential order.

    Needless to say, you can of course build a page that looks and acts exactly like a table of contents, just making all the links to the pages by hand.

    Rolling Your Own

    To build a book (and that book’s table of contents) within your website, first create a custom post type that represents the pages of your book. You can do this by creating a plugin that looks like this:

    // call our custom function with the init hook
    add_action( 'init', 'pz_register_cpts' );
    
     // custom function to register a "publication" post type
    function pz_register_cpts() {
    	register_post_type( 'publication',
    	array(
    		'labels' => array(
    			'name' => __( 'Publications' ),
    			'singular_name' => __( 'Publication' ),
    			'add_new_item' => __('Add New Publication'),
    		),
    	'public' => true,
    	'has_archive' => true,
        'show_in_rest' => true,
       'supports' => array('title','editor'),
    
    	)
        );
    
        // and bookpage CPT
        register_post_type( 'bookpage',
            array(
                'labels' => array(
            		'name' => __( 'BookPage' ),
    				'singular_name' => __( 'BookPage' )
    			),
    		'public' => true,
    		'has_archive' => true,
            'show_in_rest' => true,
    		)
    	);
    
        // and book jacket type
        register_post_type( 'jacket',
    	array(
    		'labels' => array(
    			'name' => __( 'Jackets' ),
    			'singular_name' => __( 'Jacket' ),
    			'add_new_item' => __('Add New Jacket'),
    		),
    	'public' => true,
    	'has_archive' => true,
        'show_in_rest' => true,
    
    	)
        );
    }

    Then, use the ‘Post Sort Order’ plugin to give yourself the capability to drag your custom page posts into the correct reading order.

    Note the “correct” order will very probably be the reverse of what WordPress will do, left to its own devices, unless you add the pages of your book to WordPress from back to front (not recommended).

    One thing you’ll very probably want is navigational aids on each page. You want to be able to go from the current page to the next one, or perhaps go in reverse. Ideally, you should also be able to jump forward and back from one chapter start to the next.

    As you know, WordPress themes quite frequently offer navigation from one post to the next. The source of these navigation links is, almost always, the template page for the particular style. If you’re familiar with how themes are built and how they use template pages, this is something you’ve already run across, but perhaps not paid a lot of attention to, because it lends itself to cutting and pasting.

    If this isn’t familiar territory, not to worry. This is the perview of WordPress developers and this article isn’t the place to delve in detail into how this particular bit of functionality is coded. Suffice it to say, though, it’s doable and you can see an example of this over in the marketing guide I’ve published on this site: Found and Followed.

    That same book has a dropdown menu on every page that gives you a basic ToC. It works fine, I guess, but it’s certainly easy to imagine better, and better looking, ToCs.

    It’s be nice, for instance, to have the subheadings within chapters accordion into view when the cursor hovered over a chapter title. Likewise, it’d be nice to offer thumbnail page previews as the cursor hovered over a subsection. This approach would just plain be better than the original book table of contents.

    How hard would it be to make this sort of thing available as, say, a plugin within WordPress, or a library in one of the React-based front-end environments.

    One wouldn’t expect the technical bar to be set too high, because what we’re talking about is just a variant on the basic menu pattern. Consider this option in the Divi page builder ecosystem for a so-called ‘mega menu’ dropdown with featured images.

    It’s not a ToC, but it’s easy to see how, with page thumbnails and a further dropdown from chapters to subheaders within chapters, the same basic paradigm would make an attractive navigation tool.

    But I have to say, I don’t think I’ve ever come across anything quite like a really well-done menu for a long-form work online.

  • Blockchain in WordPress in 2022

    If you land in certain corners of the Twittersphere, you’ll find yourself surrounded by people who are wildly enthusiastic believers in the power of NFTs (non-fungible tokens) to change the relationship between creators and consumers.

    By extension, they are at least a little enthusiastic about cryptocurrency as a means to an end, though they are quick to point out that they aren’t at all like the real crypto enthusiasts, who just want to get stupid rich by purchasing lots of Bitcoin and other blockchain currencies and then “hodling” it forever (that is, holding it).

    There’s also a great deal of interest and activity around the underlying blockchain technology that makes NFTs and hodling possible, though there’s maybe a little less wild fervor. So is it time to bring blockchain to WordPress?

    Probably nothing

    These folks are probably onto something, even if the sheer enthusiasm and the whiff of naivete is a little off-putting. The slang (like saying “probably nothing” as an ironic way of saying that some NFT development is likely to be huge, but whose importance is overlooked by the public at large) can get old. But in any case, on to something. It’s just an open question whether what they are on to is the same thing as whatever it is that will ultimately wind up mattering. Indeed, there are some interesting things that a business (whether a solo creator or something bigger and more traditional) could potentially do with blockchain technology and something like either minted coins or NFTs.

    For some, there’s a real opportunity there, so the pressing question becomes: what’s the shortest distance from whatever I’m doing on the web now and offering some sort of blockchain capability?

    There’s a reasonable likelihood that you are running your website on WordPress, meaning that the question will ideally boil down to installing a blockchain plugin or two. As we know, plugins can be magic.

    But before having a look at the current assortment of “early phase” plugins that handle various blockchain-related tasks, let’s talk about why you’d want to get your WordPress site tangled up in the cryptocurrency world and what you’d actually be trying to get done.

    Blockchain Potential Benefits

    If you’re running a “non-crypto” website or business (and this is most of us), you may be wondering why you should even bother with blockchain and cryptocurrency.

    Crypto Payments

    One answer may be that you have enough cryptocurrency users in your customer base or target demographic that it makes sense to accept payments in Bitcoin and/or Ethereum.

    NFT sales

    A fancier possibility is creating NFTs of some sort and selling them to the NFT collectors out there (of which there are surprisingly many). I don’t know if any of the NFT fervor, especially around JPEG art, makes any sense, but in a way it doesn’t matter. People want these sorts of things and the prices paid for them are occasionally staggering. Plus, depending on what you are doing and how novel it is, this may be a form of getting your name out there (that is, marketing) while the interest level is insanely high.

    To create NFTs, you need to create the data (the picture, the text) that will be the “contents” of the NFT, which is just the normal process of creating such things. But after that, you’ll need to either mint the NFTs yourself or provide a way for buyers to mint them as they buy them.

    Creator Coins

    Elsewhere in the world of tokens, there are interesting experiments underway with what are being called “creator coins” or “community coins.”

    You can mint NFTs, as mentioned above, but you can also mint tokens that are “alt-coins.” They are cryptocurrency that’s built on top of other cryptocurrency, by way over oversimplifying.

    When I was talking about creator coins a couple of weeks ago, I singled out Rally as a startup that was leading in building out this kind of alt-coin production:

    Dogecoin is the alt-coin people talk about, mostly in a sort of disbelief that there’s such a thing as joke-but-real money. But Rally envisions spinning up lots and lots and lots of alt-coins, one per creator/entrepreneur. Because Rally is an Ethereum sidechain, the coins are actually tied back to a currency system that in turn ties back to what most of us still (archaic fiat-currency boomers that we are) think of as real money.

    I think it’s fair to say that we’re still figuring out what it means to launch your own creator coin, but the underlying thinking is that this gives you a way to have a self-contained economy in the community that supports you. People buy your tokens as a way of supporting your work (think, approximately, Patreon, but with crypto). You as the creator at the center of this economy can reward fans for contributing their time or feedback or enthusiasm using the coin of the realm. And holders of the coins will, in most instances, receive whatever it is you’re creating, on a scale commensurate with how many coins they hold.

    If this sounds vague, that’s because the whole thing is still vague, but we’re seeing early experiments in using these sorts of tokens as event tickets, as access to community sites, and a way to buy a book that keeps you “invested” in the community going forward.

    Rally’s raison d’être is making it easy and seamless to create your own coin. But that’s not at all to say you couldn’t roll your own, using an Ethereum sidechain like Solana (this sidechain has the low “gas” costs you’d need if you were minting a lot of coins). If you do that, though, you’ll need an interface for doing the minting, need to connect that minting process to a wallet that supported Solana, then need a mechanism for making a small, private market for the coin.

    There are code libraries out there for doing all these things. There’s even a few sites emerging that are doing these sorts of things on WordPress sites. Web3WP.com, for example, lets you mint a one-off version of the WordPress mascot Wapuu, should you be overtaken by any desire to do that. More broadly, it seems likely that creator coins may be one of the more interesting places to consider blockchain in WordPress environments.

    WordPress blockchain plugins

    There are already over a hundred blockchain-related plugins in the WordPress.org plugin repository, though only a handful have more than one or two hundred active installations out there in the world. There are also a growing number of plugins available outside the official repo.

    As you’d expect, some of these various plugins are fairly arcane. One provides a websocket attachment to the Executium network, for example (40+ installations).

    Others do the sorts of things you might be interested in doing to get your feet wet. The NFT Maker by Tatum (see below) plugin let’s you…yeah. And you get your choice of the Ethereum, Polygon, Binance Smart Chain, Celo, and Harmony chains.

    So here’s a few plugins of note:

    Crypto Price Widgets

    Dip a toe into crypto by providing basic price information on your site. Crypto Price Widgets – CryptoWP displays the current prices of various coins in one of over twenty supported currencies. You can throw this widget into a sidebar or use shortcodes to drop prices into pages anywhere at all.

    LikeCoin

    From the plugin description: “LikeCoin aims to empower content ownership, authenticity, and provenance. Creators can register content metadata to guarantee its integrity by acquiring an International Standard Content Number (ISCN). ISCN is a tool to authenticate and track content, just like a digital footprint.”

    This is one PeakZebra will dig into in more detail in the next few weeks, as there’s a lot of interesting stuff lurking in this approach.

    Tatum – NFT Maker

    If you want to dive into making and selling NFTs, this seems like the most straightforward path. You can mint tokens and sell them on the site, though you can’t let users mint the NFTs themselves, a capability that some sites are using. The reason for this exclusion, I suspect, is the Tatum plugin’s business model. The plugin is free, but you’ve got to buy credits to pay for the gas transaction fees that arise in the process. And heads up: if you’re minting on the Ethereum main chain, the gas fees can be very high.

    Crypto.com Pay Checkout for WooCommerce

    Exactly what it sounds like. It accepts several currencies, including the obvious Bitcoin and Ether options.

    WordProof Timestamp

    WordProof does pretty much exactly what it sounds like it does, creating a hash of your latest post and writing it to the Ethereum blockchain, thus providing proof for the long run that you published exactly that version of the post on exactly that day and at that time. This may not be something you think you need (and you may be right), but one scenario is intriguing. If you’re a smaller website and you publish something wonderful, but a big site steals your piece and throws it up online right behind you, that site might actually get indexed by Google faster than you (sites with more traffic get higher priority), making you look like you stole the piece. This would theoretically let you set the record straight.

    Anyway, you get ten stamps a month for free, after which you pay a few bucks per month. This uses the blockchain in a sensible way, but you won’t feel like your site has joined the web3 era just because you use it, because it hides the whole blockchain business from you.

    WPSmartContracts

    Despite the “smart contracts” moniker, this plugin lets you carry out a number of different, basic cryptocurrency tasks. It focuses on the Ethereum  blockchain, and enables you to create ERC-20 tokens, Initial Coin Offerings, and has basic support for NFT marketplaces. The various things you can do with it are broken up into “flavors” of contract, with the simplest stuff being free and other flavors costing a small fraction of an Ether (though, note: a small fraction of an Ether is still some money, given that Ether is trading at over $4600 as this is written).

    Blockchain in WordPress? Still Early Days

    There’s still a lot of inventing on the fly in the world of smart contracts, NFTs, and alt-coin. But there’s also a lot of momentum behind it and there are likely some opportunities to be rewarded just for getting to the party early. Using plugins, particularly as they become more capable and robust, may very well be a way to get out in front of the pack while they struggle getting their blockchain programming skills up to snuff.

  • Theft Revisited: What Gatsby JS Should Steal from WordPress in 2022

    A long, long year ago, it seemed prudent to bring up a few things that worked well in WordPress that were missing in Gatsbyjs. For instance, one-click exchangeable Gatsby js themes.

    Some, but not many, of those holes have been filled in various ways, but others remain (and probably will remain). But time has pushed each of these web frameworks down the road a piece, meaning more developers have had more, different experiences with them. A knock-on effect of this is that it’s now clearer what it would be most useful to beg, steal or borrow from WordPress.

    WordPress vs Jamstack

    To be clear, Gatsby and WordPress are trying to solve somewhat different problems.

    Nor is anyone saying there’s something terribly wrong with Gatsby (or Next.js or Remix Run, the new kid on the block). WordPress is monolithic, the Jamstack crowd is looking for the Great Decoupling, plus static pages, plus edge functions, plus GraphQL queries to anything you might once have tackled with a REST API.

    Jamstack is aimed squarely at developers, not people who just want to drum up a website with their contact information and a few brochure pages. At the same time, a lot of the world’s websites are running on WordPress, frequently on fairly straight-out-of-the-box WordPress. That is, these are not people (and marketing departments) who are going to fall into the arms of Gatsby, even with a Gatsby template for a blogsite. They’re not going to be pushed into those arms, either, not by the need for blazing-fast speeds and not by their desire to move to a “friendlier” cloud CMS.

    As far as speed goes, last year’s “theft” essay got at something of a fundamental truth:

    A framework like Gatsby claims to have the upper hand by using static pages, but of course that’s not quite comparing apples to apples. If a JAMstack site needs to personalize pages on a per user basis, it may do so by way of API calls to a third-party services, but make no mistake, this is still just referencing a database on the back end. In the customized-page scenario, there’s no inherent JAMstack speed advantage. And, frankly, this is a fairly common scenario.

    Another thing happened in the course of the past year: Google rolled out the Core Web Vitals algorithm update that had us all worried about whether our web pages were as blindingly fast as they needed to be to rank. And it turned out not to make all that much difference. The WordPress sites of the world did not drop off the face of Google Search Engine Results Pages (SERPs).

    So if you’re running a website on WordPress and wondering whether you need to high-tail it to Jamstack, the pressure is off, by and large. It’s still nice to have a screamingly fast site, of course, and it’s nice, most folks seem to agree, to work strictly in JavaScript, rather than PHP, as is used for the core of WordPress.

    The Headless WordPress CMS Approach

    The Jamstack response is to argue that the point of decoupling the front end from the back end is that the back end can still run a WordPress stack. In Gatsbyjs, you’ve got the rather sweet option of using WPGraphQL (with a hat tip to Jason Bahl (@jasonbahl) for putting that great WordPress plugin in motion).

    That’s good stuff if you’re a developer, but on the flip side, all sorts of very useful things drop out of play if you abandon the WordPress monolith you’ve been running. And they’re mostly gone even if you keep running WordPress, but use it as a headless CMS.

    For one thing, the WordPress theme you’ve been using on the monolithic site is gone, with the design coming from the front-end side of the house.

    You can deal with this by getting a theme that behaves and looks more like WordPress—have a look at GatsbyWPThemes for a run at that (and I plan to dig in, try it out, and write about it before long, following on a great conversation the other day with Alexandra Spalato, one of the company’s founders.

    In short, you can’t just point your Gatsby front-end at your WordPress theme.

    It might seem like this should be doable because, after all, a theme is basically a bunch of CSS in a style.css file.

    But it’s not nearly so simple. For one thing, there are also template files that determine what the various repeating sorts of pages (blog entry lists, the blog entries themselves, and so on) should look like. These are written in PHP and HTML, using conventions that are very closely tied to WordPress.

    I’ve wondered in the back of my head whether it would be very hard to just write a simple (but would it be?) cross compiler to translate from the PHP files to more Gatsby-native templates. It wouldn’t shock me to see something like this get cooked up before too long.

    Jamstack Admin

    But even if we get to that point, where WordPress themes are convertible to Jamstack scenarios, you still won’t be able to jump into an admin console, look at a list of themes currently downloaded for use on your site, pick a different one, and hey presto, have a new and different look instantly online at your site.

    You can’t do that because, duh, there is no admin console for that Gatsby site of yours.

    If you build your site with a CMS and some other, separate services for identity management, database interactions, and localized customization, you have many things to manage and no centralized console.

    If you’re a relatively low-code user of WordPress, what you’re going to be missing most of all is that you can’t jump into the WordPress plugin section of the console.

    Gatsbyjs Plugins

    Now, Gatsby does have plugins. These plugins have some of the same uses as WordPress plugins, but they are designed to be consumed more or less as libraries that the developer has access to. Next.js has plugins, pretty much along the lines of Gatsby, along with some interesting third-party twists. For example, Grouparoo has a system for adding plugins that grab non-static content to add to pages.

    All that said, I’m not aware of any way on the Jamstack side of things for a third-party to program some simple little bit of functionality—to take a trivial example, giving you the ability to create pop-up footnotes within your text content[footnote]Why look, here’s just such a plugin in action.[/footnote]—that you can download and just start using at runtime and without having to work it into the fabric of your own custom application.

    During the static site generation process, extensions that acted on the source code or the generator would be called.

    Anybody who’s worked in WordPress knows that plugins can be an incredibly powerful way to get a lot done without having to do any real work. Books are always mentioning how many tens of thousands of plugins are out there. The huge number thing is nonsense, because there are all sorts of duds and orphans in the pool. But the decent plugins (and there are certainly a few thousand of these) out there make it possible for you to add nice bits of extra functionality because it’s already coded and it’s available with no fuss.

    WordPress plugins are a different animal, and Jamstack needs to steal this version of the plugin thing wholesale.

    Gatsby JS Extensions

    To keep things straight, I’m going to dub the Jamstack version of plugins “extensions.”

    Extensions should snap into a Jamstack framework along the same lines as their WordPress forebears. In other words, they should register callbacks to their functions with named events in the Jamstack process.

    As the user browses the site, other, runtime extensions would be called.

    So, if we imagine that there’s an event in a Jamstack site where a user logs in, that event might be called “user_login”. In the plugin, we’d include a function called greet_user() that did whatever we’d want to do now that the user was authenticated and we knew who it was. In addition to declaring and defining the function, a separate line of code would “hook” the “user_login” event, along these lines:

    register_action( 'user_login', 'greet_user' );

    Thus the user lands on the site, which because this is Jamstack is a bunch of basically static pages, there’s a login routine that does whatever it does, calling back to some remote service for authentication. When the user successfully logs in, the Jamstack page currently loaded “fires” the “user-login” event and calls back any functions that were registered for this event.

    Since we registered for this event, our greet_user() function will be called, we’ll do whatever we need to do, then the function will return to the overall process of showing pages and interacting with the user.

    Jamstack Architecture: Complicating Issues

    A bunch of things add some measure of complication to this, compared to the WordPress version of it.

    1. No admin interface. We don’t have the admin interface for adding and activating (and deactivating, and configuring) these extensions. For now, let’s pretend that this is no big deal. (It’s probably actually a big deal, because you probably want to build it so that non-developer admins can use and tweak extensions. That’s kind of the whole point of them, at the end of the day. But where does this thing live? Static pages on the client? But most clients aren’t admins…)
    2. Adding events to static pages. WordPress goes through its whole process for each and every page it serves, meaning there’s a centralized point (the code on the server) from which to execute events. It doesn’t matter where the user first lands—every page does this. With Jamstack, on the other hand, the user could request any page, so every page will need to know whether and how to fire events (or report back to some process that fires them).
    3. Generation time and runtime. WordPress is a simple process, dynamically building the page from header to footer, calling things along the way. Jamstack, on the other hand, has generation time in addition to client runtime, which of course is running on the edge in a browser. So there needs to be mechanisms for extensions that allow functions that do their work as pages are being generated (changing the text content of certain kinds of pages, for instance, with these changed pages thereafter being static) and functions that are shipped out to the client side, to be invoked at the appropriate moment, for instance, changing the content of a page as a React component switches in new content.
    4. Common variables and functions. This is probably the least of the issues, but it will enable extensions to do more work if there is a common environment in which extensions run (particularly on the client side). A WordPress developer has a huge list of functions and globally retrievable variables that describe the current state of the platform, who the current user is, what the URL of the current page is, what the URL of the folder that holds the templates is, what day it is, and so on. If all this sort of stuff is predefined, everybody knows what’s going on. Otherwise, everyone gets to reinvent the wheel for each outing.

    Getting back to my example of adding support for pop-up footnotes, the extension version of this would perhaps use a simple character sequence to denote footnotes in normal running content text, maybe something like [fn]comment that makes up the footnote[/fn].

    When the content is being rendered at the client, assuming we’re in a Gatsby-like environment where React is going to load in the content for the component on the fly, the content would be retrieved but, just before it was displayed, an event would fire and a callback would be made to the footnote extension.

    The Callback Process

    In WordPress, the content that goes in the middle of the page is accessible through a function call to, catchily enough, get_the_content(). Let’s assume there’s something similar available to the extension, that the content is scanned for the [fn] marker, and that some spiffy extra stuff is injected.

    Now, when the text is rendered onscreen, it includes a numbered footnote that pops up a note when hovered or clicked.

    Whoever developed this hypothetical site was not involved in making this happen. One of the site’s content developers (with appropriate administrative clearance) decided it would be great to have footnotes, found a footnote extension that had the right look and feel, installed the extension, and then added the markup to the content.

    The Upside of Aggressive Borrowing

    I don’t pretend to have worked out all the answers here, but none of the issues I’ve mentioned seems insurmountable.

    And there could be some real upsides to having a bunch of capabilities ready to plug in and go, just by checking the activate box.

    Menus, for example. WordPress menu configuration is something that could be handled by an interface on the generation side. In WordPress, I can write my own menu code if I want to, but if not, I can configure all sorts of things, beginning with the location on the page where the menu appears (and whether it’s sticky, and so on). All that stuff just happens. Building this as an extension in a Jamstack environment would mean faster deployments and more options for who changes the menus and when.

    Other examples: language localization, widgets that display links to related content, vast functionality additions like WooCommerce (a widely used plugin that provides a full range of ecommerce site capabilities), and so on.

    On the one hand, Jamstack seems to be slowly reabsorbing dynamic capabilities because, whaddya know, those dynamic things were nice to have. On the other hand, the flip toward static first, backend decoupled seems like the best approach now that there’s enough tools to make this more sophisticated architecture readily available. It’s an opportunity to borrow from time-tested approaches such as those that were gradually built into WordPress over the years. We should be able to benefit from the experience and rebuild these things cleaner and faster than ever.

  • The WordPress Developer in 2021

    I suspect that being a WordPress developer isn’t especially fashionable these days. You’re not a rat fink or a fool if you’re a WP developer, but you’re not the it kid. At least not in the developer crowd. WordPress has just been around too long to be the thing.

    That said, developing software in the WordPress ecosystem can be just as interesting as being that on-the-edge dev who codes React components that interact on the fly with distributed network microservices. (In fact, these days you can be that guy coding in React right within WP, though it’s too early to say if that’s a good thing or not).

    Toward the end of this piece, I’m going to provide links to resources that a person would need to have under their belt to enter confidently into WordPress development. How to become a WordPress dev? Learn the things on the far end of the links I’ve put into that list.

    The Age-and-Complexity Factor

    Today’s WordPress is the result of a gazillion revisions, and even the first pass of the code, almost twenty years ago, was a fork of an existing blog-creation utility. Lots of rethinking, lots of code changes. It’s complex as a result. People say it’s easy to use but I’m not really so sure about that.

    You can switch back and forth among thousands of pre-created looks and feels (that is, themes), so it’s powerful in that respect, but it’s also true that this works because the underlying presumption remains that we are dealing with something that is or is very like a blog. We’re just switching the colors around on a page that reliably has a bunch of stock components (the text, the header, the footer, a search bar, etc).

    You can’t pick a random website out there and tell immediately whether it’s running on a WordPress installation. But then again, If you looked at the last thousand new WordPress launches, you’d find a high percentage of sites that had a recognizable “WordPress” look.

    The look is a header with a horizontal menu, a hero image, a title, text paragraphs, and a sidebar down the right rail. Like this:

    What used to be a Drupal site is a WordPress site these days.

    So, big hero image. There’s also a very characteristic WordPress effect that zooms out the photo as the page is loaded. (It’s a CSS effect, really, nothing to do with WordPress from a technical view, but way overused in pre-developed themes and page builders for WP.

    What’s below the image, further down that same page? This:

    It looks pretty good.

    Click on a story link and you get a header, a text section, and, well actually, the text pages on the site are considerably simpler and cleaner than one is used to seeing. So, this:

    Clean.

    Rather than something like this:

    I don’t love the design, but I’d never disrespect the Pergola Garden.

    I should emphasize that I’m not knocking Martha’s basic format (can I be honest, though? I can’t believe Martha’s site isn’t better looking than this). When it’s the right approach, center content and sidebars is the way to go. And you can design horrible versions of this or fantastic ones.

    But while I think a perceived frumpiness may being weighing on WordPress (use of WordPress from increasing every year, notwithstanding), design isn’t really the direct purview of the WP developer, and it’s the developer aspect that I want to turn to.

    The Language Problem

    When the internet decided that browsers should be capable of doing more things than displaying text, the language used for adding some programming to web pages was JavaScript, so PHP found no role in client-side, front-end programming. PHP runs on servers. PHP makes you put a frigging dollar sign in front of all your variable names. (Actually, these days, there are usages where you wind up with dollar signs in JavaScript, too. And what’s wrong with dollar signs, anyway?)

    [et_bloom_inline optin_id=”optin_2″]

    WordPress Developers: Three Different Kinds

    WordPress developers, as opposed to theme designers, fall into what I think of as three categories.

    The first is people writing the code for WordPress itself. Anyone can throw their hat into this ring, because WordPress is an open-source project. But when I talk about WP developers in this article, I’m not really talking about WordPress Core developers.

    The second sort of WordPress developer is someone who knows their way around WordPress, knows how web style sheets work, knows good themes from junk themes, has experience with the most widely used plugins that extend WordPress’s capabilities, and knows how to take all these things and craft a solution. This is someone who probably does some coding, can write a plugin in PHP in order to smooth over a bump in the works, and who can absolutely help you avoid those early mistakes that take a lot of time to correct later.

    There’s a huge ecosystem out there for this sort of WordPress developer, and rightfully so. For all its surface calm and order, the internal workings of WordPress are the result of years of tweaking and extension while trying to maintain backward compatibility. There’s a whole universe of craziness and detail lurking there. People who really understand how the parts fit together and can control things without blowing your site up are people who provide extremely valuable services.

    My heart’s with the third group, though. These are the folks who write more complex plugins. They write shopping cart plugins, newsletter plugins, calendar management plugins, and so on. Historically, they have done their programming in PHP. That’s shifting, but most WP custom coding still happens in PHP.

    I started my coding with the C programming language. As I’ve mentioned elsewhere, many languages out there look a whole hell of a lot like C, or its C++ descendant. PHP, for instance, looks like C, just with annoying dollar signs pasted in front of variable names (and a few dozen other annoying changes that I think were thrown in spitefully). JavaScript is C thrown into browsers, with a bunch of stuff stripped out for simplicity’s sake, then gradually added back in over the years.

    C made it trivially easy to screw up memory management and mistake pointers to variables for the variables themselves. The later languages made it very hard to make these basic mistakes, so I’m not sorry to have moved on from C. But my point is that PHP is like C which is like JavaScript.

    JavaScript is on trend

    Now, JavaScript is undeniably trendy. It would have to be, because it’s what’s built into all the browsers in the world. People who didn’t want to code in PHP on the server anymore made a server-side setup for JavaScript, in the form of Node.js. And it’s pretty sweet, I’m not gonna lie.

    Yeah, JavaScript is sweet. On the client side, all sorts of wildly capable libraries and frameworks have been created, of which the one that really grabs me is React. It grabs everybody who dips a toe into it. I’m restraining myself from taking a big detour to talk about why React is cool.

    You know how you can tell JavaScript is absolutely the height of fashion just now? Because people using it are ready to look past all sorts of “extra step” things you have to put into the mix to really play ball with JavaScript. I’m talking about Babel, Webpack, and the way you can’t code for the front end without running Node.js (a backend piece) and its toolset. Oh, probably include React in that list, though React brings more benefit than extra learning curve.

    React

    I’m not the only person out there who thinks that React is the cat’s meow. WordPress used it to build their new Gutenberg editor system as well, and multiple facets of the future of WordPress are written in React.js.

    Yeah, yeah, the server-side core is still written in PHP, but the move to JavaScript within the fortress walls was the death knell for PHP. Even WordPress has given up on it (sort of).

    And you can take a step back and just maybe worry that WordPress itself looks less than brand new and exciting. I mean, you know that company Culture Trip? OK, it’s entirely possible that you don’t because I at least am not aware of them being a household word. But they did get funded to the tune of $80 million (on top of a $20 million Series A round).

    In a Medium blog post about changing tech stacks, note the implicit world-weary sigh in the first sentence:

    Culture Trip’s website used to be a WordPress site. Now it’s a flexible, universal (isomorphic) JavaScript App powered by Next.jsReactMobX and Styled-Components on the front-end that uses WordPress as a semi-headless CMS.

    I mean, holy freaking cow! You want to waste your life in WordPress after you’ve read about what Culture Trip did?  I mean, 2019 was probably not a great year to invest in a travel-related web business, what with the pandemic arriving and all, but this puppy is universal (isomorphic). You heard anyone describing their WordPress site that way lately?

    Yes, do note that they are still running WP on the back end for this ass-kicking site of theirs. This time around, we’ll skip getting sidestepped on WP as a headless CMS, but it’s a huge, interesting topic.

    But here’s my point (and yes, I do have one, though it’s taken me long enough to get to it): WordPress is a fascinating development environment, PHP is basically the same as JavaScript, so who cares if we’re writing PHP, and a tremendous amount of junk that you’d have to go off and find a library for if you were coding in JavaScript are already turned up and running in WordPress, so you only write the code that does something new and different.

    If you wind up as a WP developer it will not have the adverse effect of stunting your growth, either as a developer or as a human being.

    Coding within the WordPress universe can be pretty interesting. There’s a whole world in there, largely driven by callbacks to functions you’ve written (though, in fact, pretty much everything in WordPress itself is implemented as callback functions, so it’s not just you.

    Each time a page is served up by WordPress, there’s a sequence of events that has roughly the complexity of whatever list NASA put together to launch a Saturn V rocket. At each point in the sequence, WordPress checks to see if a some process has registered a callback function for that point, then calls each function in turn (based on a priority ranking that you can manipulate to increase or lower the priority of your own functions).

    You kind of have to stub your toes as you learn the quirks of this process, but it’s incredible how much nuanced control this enables you to have when creating a plugin.

    To take an important instance of this up for a moment, there’s an action (those points in the sequence I mentioned above are referred to as actions and filters—they are slightly different from each other, but they each call back to a registered function that “hooks” the action or filter) that gives you a chance to create new post types.

    Custom Post Types

    Content posts are the primary elements of WordPress as a content management system. WordPress began life with the assumption that it was going to store blog entries, and that each blog entry would be several things (the title, the publication date, the text itself, and so on) stored together. But lots of other things (non-blogpost pages, to take the next post type that WordPress added, but also stored media, site navigation menus, and any behind-the-scenes prior revisions of posts) can be stored as “several things stored together.”

    What makes WordPress more of an application framework than you might think is that you, as developer, can decide that you want other sorts of things to be stored this way, and thus you can create new Custom Post Types (CPTs). You might decide that your web site will have “sections” that you can treat as grouped into multisection publications, along the lines of an ebook.

    In this example, “sections” will be more or less the same thing as regular old blog posts, but they’ll be grouped differently, can be sorted in some other way than the reverse chronological order that blogs generally use, and can have different layout and styling.

    Or if you built a site for selling event tickets, you might have a CPT with entries for each event (event description, date, time, venue, and so on).

    Layout and styling are in the “theme” category rather than the “plugin” category, but when you’re creating applications that organize themselves by using CPTs, the look and behavior of pages within this CPT becomes an important part of overall development. And, indeed, the template for a given type of page is, in fact, a PHP file. It’s a template, yes, with baseline text and HTML tags and so on, but in some situations a great deal of actual code winds up in those template files.

    If you’re a hip cat and you’re working with Gatsby, you are doing largely the same thing when creating React components that will render portions of the various pages on your site. If you like doing it in Gatsby and React, there’s really no reason not to think you won’t like doing the same basic stuff in PHP files inside WordPress.

    It’s real development, rewards your increasing understanding of WordPress internals in that ‘instant-gratification’ reward system that is such an addictive part of learning new things in programming, and lets you build surprisingly complex applications all by yourself, because you’re able to operate at a high level of abstraction in a system that has a huge range of capabilities.

    A huge amount of the world’s online business is for small things and mid-sized audiences. People using highly tailored applications—things that run low-volume ecommerce sites or that manage architect offices or manage bids for roofing contractors—get more than enough performance from WordPress.

    If you’ve got content that needs to slaughter PageSpeed scores, sure, maybe you need a statically generated site (like something done in Gatsby, as per the above). But in point of fact it’s entirely possible to generate static pages from plugins within WordPress (if you’re curious, here’s more about how I do this).

    You can also get better performance from nothing fancier than a well-tuned cache for your static pages and elements.

    Given the modest traffic and transaction rates that most custom-programmed WP sites get and the ability to make static versions of posts and pages, WP is mature, sure, but also still pretty limber. It’s still the popular choice for most business websites and, it’s going to be dominant for years.

    There’s work to do, the programming tasks can be subtle, demanding, and rewarding.

    What to Learn

    As long as we’re here, we should talk about the skill set. It’s straightforward, but not necessarily easy to get everything into your head that you’ll need to be a successful developer in this environment.

    A stack of boxes showing elements needed for WordPress developers: HTML and CSS, WordPress, PHP, and JavaScript.

    First, you need to know your way around setting up and running a WordPress site. I think the best way to get started is to get a cheap web hosting account at a place that offers users the Cpanel interface for loading software on their account. Get into Cpanel and install WP. Figure out how to make a site that looks like Martha’s. Then figure out how to make one that looks even better.

    You want to know how to create new posts, how to create “pages” that aren’t posts and how to manage access to these pages using menus. How to install and swap out WP themes. Then find some basic tweaks that you can handle with one of the tens of thousands of existing plugins out there.

    Everything about everything in WP is described, sometimes quite cryptically, in the WP Codex. For elucidation in bite-sized pieces, there are sites like WPBeginner.com. There’s a good video tutorial from FreeCodeCamp.

    Beyond baseline WP admin mechanics, you should know a reasonable amount about HTML and CSS. There’s really no way to work on the web without understanding these two fundamental pieces. HTML is no big deal (though make sure you’re clear on what the DOM is within a browser, along with the subtle ways in which it represents but isn’t the same thing as the HTML for a page). CSS can be a complex beast, alas. People tend to give it short shrift and then they live in fear of it for the rest of their coding careers.

    A good resource for both HTML and CSS is W3Schools.com. PHP and JavaScript, too.

    I haven’t taken it myself, but Josh W. Comeau is on the cusp of the general release of an online course that covers CSS soup to nuts. I’ve seen bits and pieces and they are interactive and engaging. He’s not giving it away, by any means, but it’s probably worth the ticket price.

    The Actual Development Part

    After that, you’ve got to know how to program. Server-side pieces like plugins continue to be written primarily in PHP. Client-side stuff is JavaScript. If you are comfortable in one you can get coding with the other in relatively short order (add or remove the dollar sign in front of variable names).

    While PHP is the core of WordPress, if I were starting from scratch, I’d learn JavaScript first. You’ll find more resources, and generally better ones, than you’ll find for PHP. And though I’ll annoy some folks by saying this, you’ll find more of the resources pushing you toward a better grade of programming. PHP is capable of all the elegance and cutting-edge techniques you can throw at it, but it has a history of people writing (and sharing) fairly messy hacks. When you look for “how to do this or that” in WordPress, it will help if you can distinguish clean, well-coded examples from solutions that have edge-case bugs and are insecure.

    As you learn to code, you should start looking at how themes and plugins are built in WordPress. Build minimal versions of each, then try tackling increasingly demanding tasks, especially on the plugin side of the equation.

    Ultimately, you should figure out the workings of Gutenberg “blocks,” which are the emerging new paradigm for building things in WordPress. Since new blocks are coded and the whole block thing is still very much in process, there’s going to be a lot of work on this front over the next couple of years. See here for a quick introduction to the development side of Gutenberg. The tutorial at Delicious Brains is more hands on and has some good insights.

    Are you thinking about jumping into WP development? If so, what are you hoping to do with it?

  • Future URL

    One thing I always wished I’d had in my last “real” job (as an editorial director) was a way to link from web content I was currently writing to content I knew we were creating in the near future. A future URL. Of course, I could have just written in the links, but they’d by definition have been broken, at least until the scheduled pieces actually went live.

    TLDR: I wrote a WordPress plugin to do it, which, if it’s of any use to you, can be found on GitHub here.

    Back at the old job, we were, in point of fact, required to find places to link to our new content from existing older content and there were people on the staff tasked with editing the older stuff and putting those links into the older posts. And going to this extra trouble absolutely made sense from an SEO standpoint (and still does, and is routinely ignored by content teams far and wide).

    What I wanted was a way to embed the link, but not have it go live until a certain date. Now that I run my own shop, it occurred to me that there was no reason I couldn’t just build this for the current WordPress-based version of PeakZebra.com.

    Now, part of the point of PeakZebra is to migrate from WordPress to a Jamstack site, something I’ve written about here and here, to take a couple of examples. So I didn’t want to create something that would break on a static site. As we’ll see in a moment, I can actually do a somewhat better job of this forward linking in a hybrid site that’s half statically generated and half dynamic WordPress.

    Plugins and Filters

    To handle the job in WordPress one wants a plugin. From my point of view, there was no reason not to write this in PHP, the core WordPress language. Architecturally, WordPress operates by executing a series of “actions” and “filters” as each page is dynamically created and served to requesting web browsers. The execution of each action and filter is hooked to various functions, and a developer writing a plugin gets most of the work done by hooking custom functions to the appropriate actions and filters.

    As an aside, actions and filters are secretly the same thing, so basically all I’m saying here is that I can pick a moment in the page-creation cycle and tell WordPress I want it to call a custom function I’ve written at that particular moment.

    In this “future url link” scenario, all I really want to do is grab the main bunch of content on the page (what we’d typically call the blog post), search for my special kind of date-sensitive link, and enable or disable it before letting WordPress continue to serve up the page.

    The Future URL Format

    I called the primary function for this processing “handle_future_urls” and then hooked what is arguably the most important of the WordPress filter hooks, namely “the_content”. Setting up the callback looks like this:

    add_filter( ‘the_content’, ‘handle_future_urls’ );

    This statement is the first bit of code in my plugin and it executes as WordPress is getting ready to serve a page. Later in the process, when the page’s primary content has been called up from the database, WordPress will call my function handle_future_urls();

    When that function gets called, it’s with one parameter, $content, a string that contains all the words that make up the center of the page. This can be lots and lots of words—it’s all the stuff on the middle of the page that isn’t the header, footer, or sidebar widgets.

    You’re handed the content, you do whatever you want to it, and then you return the modified string of content from your function. In all honesty, it’s easy peasy and I think it makes it clear why WordPress has proven to be so extensible, versatile, and popular.

    In this case, I decided I’d work with a format that put the future link not in the standard HTML a tag, but in a nonstandard tag that took this format:

    [[http://example.com/theurl|September 1, 2021]]then some anchor text[[end]]

    It’s probably pretty obvious how the future URL format works. If you put a link like that while you’ve got the futureURL plugin loaded and activated, you’ll either get a link in your copy or you won’t, depending on the date when it’s being viewed.

    It’d be nice if the page updated to just an ordinary URL once the date had passed, just to save processing time. So… that’s coming along… And in case you were wondering, yes, there is a [[https://peakzebra.com/futurefixedurl|September 15, 2021]]future link[[end]] embedded in this paragraph, linking forward to the post I’ll write when I’ve made that update